What is the difference between host.json and application settings?

host.json controls the Function App runtime behavior — extension bundles, function timeout, concurrency limits, retry policies, and logging configuration. It is deployed with your code and affects all functions in the app. Application settings are environment variables configured in the Azure portal, CLI, or ARM/Bicep templates. They hold connection strings, secrets, and runtime configuration that varies between environments. Application settings marked as slot-sticky remain with the deployment slot during swaps.

How do I securely manage secrets in Function App configuration?

The recommended approach is to store secrets in Azure Key Vault and reference them in application settings using Key Vault references: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret). The Function App accesses the secret through a managed identity, so no credentials are stored in configuration. This requires enabling system-assigned or user-assigned managed identity and granting it Key Vault Secret User (Get) permission. Key Vault references work with Consumption, Premium, and Dedicated plans.

What are extension bundles and when should I use them?

Extension bundles automatically include all standard trigger and binding extensions (Service Bus, Storage, Cosmos DB, Event Hubs, etc.) without requiring explicit NuGet package references. They are the default for non-.NET Function Apps and simplify dependency management. You configure the bundle version range in host.json. For advanced scenarios where you need a specific extension version or a custom extension, you can disable bundles and manage extensions manually.

Azure Function App Config Builder

ServerlessAzure

Build Azure Function App configuration with runtime, scaling, CORS, and app settings.

Last verified: May 2026

Azure Functions Configuration

Build Azure Function App configuration settings including runtime, scaling, CORS, and app settings.

Required Fields

nameresourceGroupruntimesiteConfigappSettings

Generated Output

Output will appear here...

See It in Action

Your team is deploying a Python-based ETL pipeline as Azure Functions. The builder generates: host.json with Python isolated worker model + bundle version range + 30-min function timeout for batch jobs, Premium plan with system-assigned managed identity, app settings with Key Vault references for storage connection strings and database credentials, VNet integration to access private Azure SQL. Total time to working config: 1 hour vs the 4+ hours of Azure portal navigation it would take to discover all these settings individually.

What This Tool Does

Azure Function Apps require careful configuration of hosting plan settings, runtime stack versions, application settings, connection strings, and deployment slots. The configuration varies significantly between Consumption, Premium, and Dedicated (App Service) plans, and each runtime (Node.js, Python, .NET, Java, PowerShell) has specific version and dependency requirements. The Function App Config Builder helps you assemble host.json settings, local.settings.json for development, application settings for production, and deployment configuration including managed identity, VNet integration, and custom domain bindings.

Technical Details

The builder constructs Azure Function App configuration across two files: host.json (runtime config — extension bundles, function timeout, logging, retry policy) and the Function App resource definition (hosting plan SKU, runtime stack, application settings, connection strings, managed identity, VNet integration, deployment slots). Output includes the host.json file content, the az functionapp create + config set CLI sequence, and Terraform azurerm_linux_function_app or azurerm_windows_function_app resources.

Common Use Cases

1Building host.json configurations with correct extension bundles, logging levels, and concurrency settings for a Python Function App
2Generating application settings with managed identity references for Key Vault secrets instead of hardcoded connection strings
3Configuring Function App scaling limits, pre-warmed instances, and runtime scale monitoring for Premium plan deployments
4Creating deployment slot settings with slot-sticky application settings for staging environments that do not swap to production

Common Questions

What is the difference between host.json and application settings?: host.json controls the Function App runtime behavior — extension bundles, function timeout, concurrency limits, retry policies, and logging configuration. It is deployed with your code and affects all functions in the app. Application settings are environment variables configured in the Azure portal, CLI, or ARM/Bicep templates. They hold connection strings, secrets, and runtime configuration that varies between environments. Application settings marked as slot-sticky remain with the deployment slot during swaps.
How do I securely manage secrets in Function App configuration?: The recommended approach is to store secrets in Azure Key Vault and reference them in application settings using Key Vault references: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret). The Function App accesses the secret through a managed identity, so no credentials are stored in configuration. This requires enabling system-assigned or user-assigned managed identity and granting it Key Vault Secret User (Get) permission. Key Vault references work with Consumption, Premium, and Dedicated plans.
What are extension bundles and when should I use them?: Extension bundles automatically include all standard trigger and binding extensions (Service Bus, Storage, Cosmos DB, Event Hubs, etc.) without requiring explicit NuGet package references. They are the default for non-.NET Function Apps and simplify dependency management. You configure the bundle version range in host.json. For advanced scenarios where you need a specific extension version or a custom extension, you can disable bundles and manage extensions manually.

Expert Tips

TIP

Always default to Premium plan for production unless you specifically need Consumption's pay-per-execution model AND can tolerate cold starts. Premium eliminates cold starts via pre-warmed instances, supports VNet integration, and provides predictable performance. The cost difference is usually justified for any user-facing workload.

TIP

Use Key Vault references for ALL secrets, not just 'sensitive' ones. Connection strings, API keys, even feature flags — anything you might want to rotate without redeploying. Hardcoded secrets in app settings are visible to anyone with Reader role on the resource.

TIP

host.json's `extensionBundle` settings should specify a version range, not a specific version. The default `[3.*, 4.0.0)` ensures bug fixes and security patches are picked up automatically while preventing major-version breaking changes. Pinning to a specific version means you have to manually update for security fixes.

Related Learning Guides

Functions Hosting Plans22 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.