Deploy on Azure (Container Apps)
How to run a Sentinel gateway in your Azure subscription on Container Apps, keep its heartbeat alive, and register its URL
To deploy SUPERWISE® Sentinel on Azure, run the Sentinel gateway container on Azure Container Apps with at least one replica, its three identity values as secrets, and its public URL registered as SENTINEL_EXTERNAL_HOST. Container Apps supplies the HTTPS endpoint and certificate and pulls the image directly from the SUPERWISE registry.
Container Apps is one example, not the only option. The gateway is a standard container, so on Azure it runs just as well on AKS (with the Helm chart), an Azure VM, or any container host. This page walks through Container Apps end to end; pick the service that fits your platform. See Deploy a gateway for the full list.
Before you start
- Complete Before you deploy: create the Sentinel, and have
SENTINEL_ID,SW_CLIENT_ID, andSW_CLIENT_SECRETin your shell. - The Azure CLI, signed in, with deploy access to the subscription.
- The commands below also use
TEAM(a name for this gateway's resources),RG(resource group),ENV(Container Apps environment), andLOCATION.
1. Register the provider and create the environment
az provider register --namespace Microsoft.App # takes about a minute
az provider show --namespace Microsoft.App --query registrationState --output tsv
az group create --name "$RG" --location "$LOCATION"
az containerapp env create --name "$ENV" --resource-group "$RG" --location "$LOCATION"A Container Apps environment is a separate resource that must exist before the app can be created. If you give no Log Analytics workspace, Azure generates one and warns rather than failing.
2. Deploy
az containerapp create \
--name "sentinel-gateway-${TEAM}" \
--resource-group "$RG" --environment "$ENV" \
--image us-central1-docker.pkg.dev/admina33d6818/sentinel-public/sentinel:latest \
--target-port 8000 --ingress external \
--min-replicas 1 \
--secrets sentinel-id="$SENTINEL_ID" sw-client-id="$SW_CLIENT_ID" sw-client-secret="$SW_CLIENT_SECRET" \
--env-vars SENTINEL_ID=secretref:sentinel-id \
SW_CLIENT_ID=secretref:sw-client-id \
SW_CLIENT_SECRET=secretref:sw-client-secret--min-replicas 1 keeps one replica running, so the gateway's heartbeat survives idle periods. For production, reference Key Vault secrets through the container app's managed identity rather than passing values with --secrets.
3. Register the URL
FQDN=$(az containerapp show -n "sentinel-gateway-${TEAM}" -g "$RG" \
--query properties.configuration.ingress.fqdn -o tsv)
az containerapp update -n "sentinel-gateway-${TEAM}" -g "$RG" \
--set-env-vars "SENTINEL_EXTERNAL_HOST=https://${FQDN}"Confirm that
--set-env-varsmerged rather than replaced. Some Azure CLI versions replace the whole variable list, which strips the gateway's identity while leaving it running. Verified as merging on Azure CLI 2.89.0.
4. Set the request timeout
Set the ingress request timeout explicitly, so long streaming responses are not cut short. See Raise the request timeout. The health probe defaults to /, which the gateway answers with a 404; on Container Apps this does not block routing.
5. Verify the gateway
The Sentinel turns Active in the SUPERWISE app within about a minute. First check that the container is serving. /healthz answers 200 OK:
curl -i "https://${FQDN}"/healthzHTTP/1.1 200 OK
...
{"status":"ok"}/healthz shows only that the gateway is up. Then confirm a guardrail fires with POST /test, as described in Verify the gateway.
Keep it Active during quiet periods
On the Consumption plan, an idle replica can have its CPU restricted, which stops the heartbeat. If the gateway drops to Pending during quiet periods, move it to a Dedicated workload profile.
Update or remove it
To run a newer image, update the app with the same image reference:
az containerapp update -n "sentinel-gateway-${TEAM}" -g "$RG" \
--image us-central1-docker.pkg.dev/admina33d6818/sentinel-public/sentinel:latestTo remove the gateway, delete the app. The Sentinel's configuration stays in the SUPERWISE app.
az containerapp delete -n "sentinel-gateway-${TEAM}" -g "$RG"Common errors
The gateway runs but stops reporting after --set-env-vars
--set-env-varsSome Azure CLI versions replace the whole variable list rather than merging into it, which strips SENTINEL_ID, SW_CLIENT_ID, and SW_CLIENT_SECRET. Run az containerapp show to check the variables, and set all four again if they are missing. Verified as merging on Azure CLI 2.89.0.
The Sentinel drops to Pending during quiet periods
On the Consumption plan, an idle replica can have its CPU restricted, which stops the heartbeat. Move the app to a Dedicated workload profile. See Keep it Active during quiet periods.
The health probe reports 404
The probe defaults to /, which the gateway answers with a 404. On Container Apps this does not block routing. Point the probe at /healthz to clear it.
Get Sentinel: Create a free SUPERWISE account.
See also
- Deploy a gateway: every way to deploy, and what a team gateway needs on any platform.
- Deploy on AWS (ECS Express Mode) and Deploy on Google Cloud (Cloud Run).
- Deploy with Helm on Kubernetes: AKS and any other cluster.
- Gateway reference: environment variables, routes, and states.
Updated about 5 hours ago