The direction of travel is what makes this work. Both usual deployment routes for Logic Apps Standard depend on the SCM endpoint, and on an internal-load-balancer ASE v3 that endpoint is not published [1]. Run-From-Package inverts the last hop: the pipeline writes a zip to blob storage, then uses ARM to set one app setting and restart, and the app reads the package itself from inside the VNet using its own managed identity [3]. The network requirement moves off the build agent and onto the thing that already lives in the network.
The credential story follows from that. Both hops authenticate as an identity rather than with a shared string, so the package URL carries no SAS token and there is no deployment secret to rotate or leak [3][9].
The bill is three role assignments [5]. Two sit on the pipeline identity: Storage Blob Data Contributor scoped to one storage account, and Website Contributor scoped to the Logic App's resource group [5]. Read the second one twice. It is not scoped to the Logic App, so it reaches every site in that group, while the deployment itself needs one app setting and one restart on one app [10]. If that resource group holds anything else with a hostname, the pipeline can reconfigure and bounce it too.
The failure that costs the most time is not in the YAML. According to the author, an MI-type service connection had existed for months and had never worked, because the agent VM's system-assigned identity was switched off [8]. The diagnostic is a throwaway pipeline that calls the instance metadata service at 169.254.169.254, decodes the token payload, and prints `oid` and `xms_mirid`, which tells you both who the pipeline is and which VM it is running on [7]. An `Identity not found` response is the tell [8].
The pilot workflow is deliberately dull: a stateful hourly recurrence trigger feeding a Compose action, no connectors, nothing that can fail for reasons unrelated to the pipe [11]. That discipline pays for itself immediately, because the first run failed with `Cannot find path ...\apps\` when the pipeline's `sourceFolder` and trigger paths omitted the repo subfolder prefix [6]. That error is legible against an empty `connections.json`. It is much less legible when the zip also contains connection references and per-environment parameters.
One qualifier the framing deserves. The who-am-I sample runs on a pool named `SelfHosted-Windows-Pool` and reads a VM's system-assigned identity [7], so an agent you own is still in the picture. What has been removed is the requirement that it sit inside the ASE VNet with SCM reach, which is the part that usually needs a platform team and a change window. The author is candid that the in-VNet agent remains the right long-term answer [2].
