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, and SW_CLIENT_SECRET in 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), and LOCATION.

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-vars merged 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}"/healthz
HTTP/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:latest

To 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

Some 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


Did this page help you?