Configuration¶

This guide covers operational runtime configuration for Azure Functions. It focuses on app settings, host.json, secret management, and safe rollout patterns.

Platform Guide

For scaling architecture and plan comparison, see Scaling.

Language Guide

For Python deployment specifics, see the Python Tutorial.

Prerequisites¶

Azure CLI 2.56.0 or later with a signed-in context.
Contributor or higher role on the Function App resource group.
Access to Application Insights logs for post-change verification.
Access to Key Vault and managed identity role assignments for secret-backed settings.
A deployment method that keeps host.json versioned with code.

When to Use¶

Choose configuration layers by scope and change frequency: - App settings for environment-specific values, secrets, feature flags, and per-slot overrides. - host.json for host-wide runtime behavior such as logging, retries, extension tuning, and sampling. - Extension-specific configuration when tuning one binding type (for example Service Bus or Event Hubs) without changing business logic. - Function-level attributes or decorators when behavior differs by function (for example retry policy per trigger). - local.settings.json only for local developer execution, never as a production source of truth.

flowchart TB
    A["App Settings<br/>Environment and secrets"] --> B["host.json<br/>Host runtime defaults"]
    B --> C["Extension Config<br/>Binding-specific behavior"]
    C --> D["Function-level Config<br/>Per-function overrides"]

Procedure¶

Configuration layers¶

Use a layered model: 1. App settings for environment values. 2. host.json for runtime host behavior. 3. Local development settings for workstation execution.

App settings¶

Common settings: | Setting | Purpose | |---|---| | AzureWebJobsStorage or identity-based equivalent | Host storage dependency | | FUNCTIONS_WORKER_RUNTIME | Worker runtime selection | | APPLICATIONINSIGHTS_CONNECTION_STRING | Monitoring destination | | WEBSITE_RUN_FROM_PACKAGE | Immutable package deployment behavior | | Custom settings | Feature flags and endpoints | Set values:

az functionapp config appsettings set \
    --resource-group <resource-group> \
    --name <app-name> \
    --settings FUNCTIONS_WORKER_RUNTIME=<worker-runtime>

List values (redact secrets before sharing):

az functionapp config appsettings list \
    --resource-group <resource-group> \
    --name <app-name> \
    --query "[].{name:name,value:value}" \
    --output table

Example output:

Name                                         Value
-------------------------------------------  ----------------------------------------------
FUNCTIONS_WORKER_RUNTIME                     python
WEBSITE_RUN_FROM_PACKAGE                     1
APPLICATIONINSIGHTS_CONNECTION_STRING        InstrumentationKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
MySecretSetting                              @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-password/)

`host.json` essentials¶

host.json controls host-level behavior such as logging, sampling, and extension configuration.

{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request;Exception"
      }
    },
    "logLevel": {
      "default": "Information"
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  }
}

Sampling

Sampling can reduce telemetry costs, but keep critical request and exception visibility.

Show effective host-level overrides from app settings:

az functionapp config appsettings list \
    --resource-group <resource-group> \
    --name <app-name> \
    --query "[?starts_with(name, 'AzureFunctionsJobHost__')].{name:name,value:value}" \
    --output table

Example output:

Name                                                                  Value
--------------------------------------------------------------------  -----------
AzureFunctionsJobHost__logging__logLevel__default                    Warning
AzureFunctionsJobHost__extensions__serviceBus__prefetchCount         32
AzureFunctionsJobHost__extensions__queues__batchSize                 16

`local.settings.json`¶

Use local settings only for local runtime execution.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "<worker-runtime>",
    "APPLICATIONINSIGHTS_CONNECTION_STRING": "InstrumentationKey=<masked>"
  }
}

Operational rules: - Do not commit production secrets. - Keep a sanitized local.settings.json.example in source control. - Inject secrets at deployment time via secure pipeline mechanisms.

Key Vault references¶

Use Key Vault references to resolve secrets in app settings without storing plaintext secret values. Format:

@Microsoft.KeyVault(SecretUri=https://<key-vault-name>.vault.azure.net/secrets/<secret-name>/)

Set a Key Vault-backed app setting:

az functionapp config appsettings set \
    --resource-group <resource-group> \
    --name <app-name> \
    --settings "MySecretSetting=@Microsoft.KeyVault(SecretUri=https://<key-vault-name>.vault.azure.net/secrets/<secret-name>/)"

Check Key Vault reference resolution status:

az rest \
    --method get \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<app-name>/config/configreferences/appsettings/list?api-version=2023-12-01" \
    --query "properties[?contains(name, 'MySecretSetting')].{name:name,status:status,details:details}" \
    --output table

Example output:

Name             Status       Details
---------------  -----------  -----------------------------------------------
MySecretSetting  Resolved     Secret version loaded from Key Vault reference

Managed identity for secret access¶

Enable system-assigned identity:

az functionapp identity assign \
    --resource-group <resource-group> \
    --name <app-name>

Grant the identity least-privilege access to Key Vault and dependent services. Prefer identity-based connection patterns over connection strings when bindings support it.

Identity-based connection patterns (including Flex Consumption)¶

Use identity-based connections to remove secret sprawl and align with zero-trust operations. For Flex Consumption, use this pattern for production-grade storage and binding access, especially in locked-down environments. Host storage with identity:

AzureWebJobsStorage__accountName=<storage-account-name>
AzureWebJobsStorage__credential=managedidentity
AzureWebJobsStorage__clientId=<user-assigned-identity-client-id>

Binding connection with identity (MyStorage prefix example):

MyStorage__blobServiceUri=https://<storage-account-name>.blob.core.windows.net
MyStorage__queueServiceUri=https://<storage-account-name>.queue.core.windows.net
MyStorage__credential=managedidentity
MyStorage__clientId=<user-assigned-identity-client-id>

Set the settings from CLI:

az functionapp config appsettings set \
    --resource-group <resource-group> \
    --name <app-name> \
    --settings \
        AzureWebJobsStorage__accountName=<storage-account-name> \
        AzureWebJobsStorage__credential=managedidentity \
        MyStorage__blobServiceUri=https://<storage-account-name>.blob.core.windows.net \
        MyStorage__queueServiceUri=https://<storage-account-name>.queue.core.windows.net \
        MyStorage__credential=managedidentity

Slot-specific settings¶

When using slots, mark environment-specific values as slot settings.

az functionapp config appsettings set \
    --resource-group <resource-group> \
    --name <app-name> \
    --slot staging \
    --slot-settings AZURE_FUNCTIONS_ENVIRONMENT=Staging

Configuration change management workflow¶

Use a controlled workflow for every production configuration update.

flowchart LR
    A["Propose change<br/>Ticket and risk assessment"] --> B["Review<br/>Peer and platform owner approval"]
    B --> C["Deploy<br/>Staging then production"]
    C --> D["Verify<br/>Health, logs, and dependency checks"]
    D --> E["Document<br/>Record baseline and evidence"]

Recommended sequence: 1. Propose change with expected impact and rollback trigger. 2. Review against security, scale, and dependency constraints. 3. Deploy to staging slot or non-production app first. 4. Verify telemetry, trigger behavior, and secret resolution. 5. Promote to production and archive evidence links.

Configuration checklist¶

Configuration updates are versioned and reviewed.
Secrets come from Key Vault references.
host.json changes are validated before production rollout.

Verification¶

Run these checks after every change:

az functionapp config appsettings list \
    --resource-group <resource-group> \
    --name <app-name> \
    --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_RUN_FROM_PACKAGE' || starts_with(name, 'AzureFunctionsJobHost__')].{name:name,value:value}" \
    --output table

az functionapp identity show \
    --resource-group <resource-group> \
    --name <app-name> \
    --query "{type:type,principalId:principalId,tenantId:tenantId}" \
    --output table

az monitor app-insights query \
    --app <application-insights-name> \
    --analytics-query "traces | where timestamp > ago(15m) | where message contains 'Host started' | project timestamp, message | take 5" \
    --output table

Example output:

Timestamp                    Message
---------------------------  -------------------------------
2026-04-05T09:20:41.184Z     Host started (HostId=prod-func)
2026-04-05T09:20:42.017Z     2 functions loaded

Success indicators: - Changed settings appear with expected values and expected slot scope. - Managed identity remains enabled and principal ID is unchanged unless intentionally rotated. - No startup failures related to binding initialization or secret resolution. - Key Vault reference status is Resolved for all secret-backed settings.

Rollback / Troubleshooting¶

Use this section when new settings cause startup errors, trigger failures, or inconsistent behavior across environments. Config drift and incorrect settings playbook: 1. Re-list current settings and compare with approved baseline from source control or release records. 2. Restore known-good app settings and host.json values from last successful deployment. 3. Restart the app and verify host startup and trigger listener status. 4. If only one slot is affected, swap back or redeploy the previous slot package. Targeted checks: - AzureWebJobsStorage failures: confirm identity settings, role assignments, and storage DNS reachability. - Key Vault reference unresolved: confirm vault access policy or RBAC and private endpoint routing. - Unexpected throttling or backlog: review host.json concurrency and extension settings. - Local vs cloud mismatch: verify local.settings.json values are not assumed in cloud runtime. Rollback command examples:

az functionapp config appsettings delete \
    --resource-group <resource-group> \
    --name <app-name> \
    --setting-names AzureFunctionsJobHost__extensions__serviceBus__prefetchCount

az functionapp deployment slot swap \
    --resource-group <resource-group> \
    --name <app-name> \
    --slot staging \
    --target-slot production

Configuration¶

Prerequisites¶

When to Use¶

Procedure¶

Configuration layers¶

App settings¶

`host.json` essentials¶

`local.settings.json`¶

Key Vault references¶

Managed identity for secret access¶

Identity-based connection patterns (including Flex Consumption)¶

Slot-specific settings¶

Configuration change management workflow¶

Configuration checklist¶

Verification¶

Rollback / Troubleshooting¶

See Also¶

Sources¶

Configuration¶

Prerequisites¶

When to Use¶

Procedure¶

Configuration layers¶

App settings¶

host.json essentials¶

local.settings.json¶

Key Vault references¶

Managed identity for secret access¶

Identity-based connection patterns (including Flex Consumption)¶

Slot-specific settings¶

Configuration change management workflow¶

Configuration checklist¶

Verification¶

Rollback / Troubleshooting¶

See Also¶

Sources¶

`host.json` essentials¶

`local.settings.json`¶