Deploy to Azure

Nuxt projects with deploy.agent or deploy.automations also build and deploy one separate native Durable Functions app and its private Storage account. See Deploy Agents for dependencies, state storage, and gateway credentials, and Deploy Automations for scheduled jobs, event waits, and integration housekeeping. Both workloads share the Function app; the application database and uploaded files remain separate.

This guide deploys a working standalone, Nuxt, or Next.js application to Azure App Service. You need an active Azure subscription, committed migrations, and data credentials.

The default App Service plan is B1, in westeurope. It is billable and remains in Azure until removed.

1. Select an Active Subscription

Install Azure CLI, then sign in and list your subscriptions:

az login
az account list --output table

Select the subscription you want to use, replacing YOUR_SUBSCRIPTION_ID:

az account set --subscription YOUR_SUBSCRIPTION_ID
az account show --output table

A portal login or an Entra directory without a subscription cannot create App Service resources. If Azure asks you to upgrade an expired free account, complete that step in the portal first. CloudConfig stops a tenant-only login before building.

The subscription also needs permission and regional quota to create a resource group and Linux App Service plan.

2. Select Azure

Set the host in your existing config:

deploy: {
  target: 'azure',
}

To choose a resource group, region, or subscription explicitly, add those values:

deploy: {
  target: 'azure',
  azure: {
    subscription: 'your-subscription-id',
    resourceGroup: 'blog-production',
    location: 'westeurope',
    sku: 'B1',
  },
}

App Service names are globally unique. By default, CloudConfig adds a stable suffix based on the subscription and resource group. Set deploy.name only if you want to supply your own globally unique app name.

3. Preview and Deploy

Run the deployment commands:

pnpm exec cloudconfig deploy --dry-run
pnpm exec cloudconfig deploy

The dry run validates local configuration, migration metadata, and required settings. It makes no provider calls or remote schema checks.

Deployment builds locally and packages the runtime before applying migrations. It creates or reuses the resource group, Linux App Service plan, and app, then migrates the database, applies settings, and uploads the archive.

4. Check the Running App

Open the printed Azure URL and /api/_docs. Test sign-in and a write followed by a read.

If the upload succeeds but the app does not start, open App Service → Log stream and Deployment Center → Logs. Check the first startup error and database credentials before redeploying.

How Your Framework Runs

Standalone and Nuxt applications run as Node.js servers. Next.js uses its official standalone output. CloudConfig adds output: 'standalone' to standard Next config shapes when needed. Conflicting output settings and custom config functions are preserved; the CLI explains the required setup.

In a Next.js monorepo, set outputFileTracingRoot to include workspace dependencies. Dependencies outside the packaged runtime stop deployment before migrations, so broken links are not uploaded.

The archive includes built files and runtime dependencies. Local .env, SQLite databases, and uploads are excluded from traced standalone and Next.js runtimes. Settings go through a temporary private file that is removed after use.

CloudConfig sets the startup command and binds the server to 0.0.0.0 on App Service's PORT. Azure does not reinstall or rebuild the source. The adapter uses the App Service CLI.

Use the Azure hostname for the first deployment. See domain setup before moving traffic.