Deploy to Azure | Compose using Liquid for Azure Logic Apps

What the Logic App needs in Azure

Setting	Value
Plan	Workflow Standard (WS1 or larger), Windows or Linux
`AzureFunctionsJobHost__extensionBundle__*`	Delete them: the project is NuGet-based
`FUNCTIONS_WORKER_RUNTIME`	dotnet
`FUNCTIONS_INPROC_NET8_ENABLED`	1
`LiquidCompose__AllowScripts`	true, when templates use C#
`LiquidCompose__FunctionRegistryPath`	When templates call Functions

A Logic App created in the portal or with az logicapp create starts as an extension-bundle app; change those settings before you deploy. On a Linux plan, use 0.1.1 or later; 0.1.0's worker does not start there.

Publish and deploy

dotnet publish LogicApp.csproj -c Release -o publish
# zip the publish folder, then:
az logicapp deployment source config-zip -n <logic-app> -g <resource-group> --src logic-app.zip

The publish folder must contain:

bin/lambogenius-liquid-worker/Lambogenius.Transforms.Worker.dll with its .runtimeconfig.json and .deps.json;
Artifacts/LiquidTemplates/… and your Function registry file;
a host.json without extensionBundle.

Promote the same package bytes from development to test to production. Endpoints, identities and keys are app settings and the registry, never package content.

Functions and identity

Function keys go in the app setting named by the registry entry's keySetting, as a Key Vault reference.
Managed identity needs App Service Authentication on the Function app, with an app registration whose application ID URI matches the registry scope, allowing the Logic App's identity.
Remove LiquidCompose__Development__AllowLocalhostHttp outside development.

After deployment

The first call after a deployment or restart starts the workers and compiles C# blocks: a few seconds. Later calls take milliseconds.
Roll back by redeploying the previous package version. The action keeps no state outside its worker processes.