Deploy on Azure

Superinterface ships as a Docker image (supercorp/superinterface-server) so you can drop it into any Azure service that runs containers. This guide covers two common options—Azure Container Apps and Azure App Service for Containers—and shows how to wire up the required environment variables and Prisma migrations.

Prerequisites

An Azure subscription with the Azure CLI logged in (az login).

A Postgres instance that Prisma can reach (Azure Database for PostgreSQL, Neon, Supabase, etc.).

The connection strings you plan to use for DATABASE_URL (pooled) and DIRECT_URL (direct/migration). For Supabase or single-URL providers, set both variables to the same value.

The Docker image tag you want to deploy, for example 1.1.7.

The container listens on port 3000, expects the environment variables listed in Self-hosting overview, and does not run database migrations automatically. Run npx prisma migrate deploy yourself as part of the rollout.

Option 1: Azure Container Apps

Azure Container Apps (ACA) gives you managed autoscaling without managing Kubernetes YAML.

RESOURCE_GROUP="superinterface-rg" LOCATION="eastus" ACA_ENV="superinterface-env" APP_NAME="superinterface" IMAGE="supercorp/superinterface-server:1.1.7" az group create --name "$RESOURCE_GROUP" --location "$LOCATION" # Create a Container Apps environment if you do not have one yet. az containerapp env create \ --name "$ACA_ENV" \ --resource-group "$RESOURCE_GROUP" \ --location "$LOCATION" az containerapp create \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" \ --environment "$ACA_ENV" \ --image "$IMAGE" \ --target-port 3000 \ --ingress external \ --min-replicas 1 \ --max-replicas 3 \ --env-vars \ DATABASE_URL=<pooled-url> \ DIRECT_URL=<direct-url> \ NEXT_PUBLIC_SUPERINTERFACE_BASE_URL=https://api.example.com \ DATABASE_ADAPTER=direct

Store secrets

Swap the inline --env-vars for ACA secrets to keep credentials out of the command line:

az containerapp secret set \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" \ --secrets database-url=<pooled-url> direct-url=<direct-url> qstash-token=<token> az containerapp update \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" \ --set-env-vars \ DATABASE_URL=secretref:database-url \ DIRECT_URL=secretref:direct-url \ QSTASH_TOKEN=secretref:qstash-token

Add any optional secrets (Upstash, Groq, etc.) the same way.

Apply migrations

Run Prisma migrations once per database. ACA exposes an exec command you can use from CI or your workstation:

az containerapp exec \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" \ --command "npx prisma migrate deploy"

The process inherits the environment variables configured on the Container App, so no additional flags are required.

Option 2: Azure App Service for Containers

App Service is handy if you already host web workloads on Azure Web Apps.

RESOURCE_GROUP="superinterface-rg" PLAN_NAME="superinterface-plan" APP_NAME="superinterface-app" IMAGE="supercorp/superinterface-server:1.1.7" az group create --name "$RESOURCE_GROUP" --location eastus # Create a Linux App Service plan (Basic or higher is recommended). az appservice plan create \ --name "$PLAN_NAME" \ --resource-group "$RESOURCE_GROUP" \ --sku B1 \ --is-linux az webapp create \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" \ --plan "$PLAN_NAME" \ --deployment-container-image-name "$IMAGE" # Configure environment variables. az webapp config appsettings set \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" \ --settings \ WEBSITES_PORT=3000 \ DATABASE_URL=<pooled-url> \ DIRECT_URL=<direct-url> \ NEXT_PUBLIC_SUPERINTERFACE_BASE_URL=https://api.example.com \ DATABASE_ADAPTER=direct

App Service handles TLS and exposes the container on the URL reported by az webapp show. For private deployments, wire the web app into your VNet and front it with Application Gateway or Front Door.

Running migrations on App Service

Use the App Service SSH console or the CLI to run migrations:

az webapp ssh \ --name "$APP_NAME" \ --resource-group "$RESOURCE_GROUP" # Once connected: npx prisma migrate deploy

You can also run migrations from your CI pipeline using the same DATABASE_URL/DIRECT_URL values without touching the container.

Common environment variables

Regardless of the Azure host, make sure these variables are defined:

Variable	Purpose
`DATABASE_URL`	Prisma client connection string (pooled).
`DIRECT_URL`	Direct connection string for migrations.
`NEXT_PUBLIC_SUPERINTERFACE_BASE_URL`	Public URL the dashboard uses in generated links.
`DATABASE_ADAPTER`	`neon` (default) or `direct` depending on your provider.
`QSTASH_TOKEN` / `QSTASH_CURRENT_SIGNING_KEY`	Required for scheduled tasks via Upstash.
`COMMUNITY_TEST_GROQ_API_KEY`	Optional fallback key for demos.

You can set additional provider-specific variables (OpenAI, Anthropic, etc.) exactly as you would in any other hosting environment.

Health checks and scaling

Configure the container health probe in ACA/App Service to hit /api/health. The route returns 200 when the server is ready.

Scale replicas in ACA with az containerapp revision set-mode single (for zero-downtime rolling deploys) and autoscaling rules. App Service uses scale-out rules on the plan.

When rolling out a new image tag, update the revision (az containerapp update --image ...) or web app configuration (az webapp config container set ...). Remember to rerun npx prisma migrate deploy after the rollout if the new version ships database changes.

With these pieces in place, customers can wire the Superinterface API into their Azure workloads while keeping migrations and secrets under their control.