AZ Functions Configuration and Application Settings

Configuration in Azure Functions means storing values like database connection strings, API keys, feature flags, and environment-specific settings outside the code. Hardcoding sensitive values directly in code creates security risks and makes the application difficult to maintain across different environments (development, testing, production).

Azure Functions provides several mechanisms to manage configuration cleanly and securely.

Why Configuration Matters

┌──────────────────────────────────────────────────────────────┐
│             HARDCODED vs CONFIGURATION                       │
│                                                              │
│  Bad (Hardcoded):                                            │
│  const connStr = "Server=prod-db;Password=MySecret123";      │
│  Problems: Secret exposed in code, committed to Git,         │
│  must change code to switch environments                     │
│                                                              │
│  Good (Configuration):                                       │
│  const connStr = process.env.DB_CONNECTION_STRING;           │
│  Benefits: Secret stored securely, different value           │
│  per environment, no code change needed                      │
└──────────────────────────────────────────────────────────────┘

Configuration Layers in Azure Functions

local.settings.json – Local Development

This file stores local environment variables. It is only used when running functions locally. Azure never reads this file — it is exclusively for the local machine.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "DB_CONNECTION_STRING": "Server=localhost;Database=devdb;User=admin;Password=dev123",
    "SENDGRID_API_KEY": "SG.devkey...",
    "MAX_RETRY_COUNT": "3",
    "ENVIRONMENT": "development"
  }
}

Important Rules for local.settings.json

• Add this file to .gitignore immediately — it contains sensitive values
• The Values section maps key names to string values
• All values must be strings (wrap numbers in quotes)
• Settings here are accessible in code via process.env.KEY_NAME

Reading Settings in Function Code

module.exports = async function (context, req) {

    // Read environment variables (works both locally and in Azure)
    const dbConnection = process.env.DB_CONNECTION_STRING;
    const apiKey = process.env.SENDGRID_API_KEY;
    const maxRetries = parseInt(process.env.MAX_RETRY_COUNT) || 3;
    const environment = process.env.ENVIRONMENT || "production";

    context.log(`Running in ${environment} environment`);
    context.log(`Max retries configured: ${maxRetries}`);

    // Use the values (never log secrets!)
    await connectToDatabase(dbConnection);
    await sendEmail(apiKey);
};

App Settings in Azure Portal

When a function app runs in Azure, it reads settings from Application Settings instead of local.settings.json. The Application Settings in Azure are secure, encrypted at rest, and accessible as environment variables inside the function.

┌──────────────────────────────────────────────────────────────┐
│           AZURE APP SETTINGS FLOW                            │
│                                                              │
│  Azure Portal                                                │
│  └── Function App                                            │
│       └── Configuration → Application Settings              │
│            ├── DB_CONNECTION_STRING = "Server=prod-db;..."   │
│            ├── SENDGRID_API_KEY = "SG.prodkey..."            │
│            └── ENVIRONMENT = "production"                    │
│                       │                                      │
│                       │  Injected as environment variables   │
│                       ▼                                      │
│  Function Code: process.env.DB_CONNECTION_STRING             │
└──────────────────────────────────────────────────────────────┘

Adding Settings via Azure CLI

# Add a setting to a deployed function app
az functionapp config appsettings set \
  --name MyFunctionApp \
  --resource-group MyResourceGroup \
  --settings "DB_CONNECTION_STRING=Server=prod-db;..."

# List all current settings
az functionapp config appsettings list \
  --name MyFunctionApp \
  --resource-group MyResourceGroup

host.json – Global Function App Settings

The host.json file controls the behavior of the entire function app — not individual functions. It configures things like logging levels, retry policies, and extension-specific settings.

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "default": "Information",
      "Host.Results": "Error",
      "Function": "Information"
    }
  },
  "extensions": {
    "queues": {
      "batchSize": 16,
      "maxDequeueCount": 5,
      "visibilityTimeout": "00:00:30"
    }
  },
  "functionTimeout": "00:05:00"
}

Common host.json Settings

Azure Key Vault – For Highly Sensitive Secrets

For the most sensitive values (database master passwords, certificate private keys, payment gateway credentials), use Azure Key Vault. Key Vault is a dedicated secret store with access control, audit logs, and rotation capabilities.

┌──────────────────────────────────────────────────────────────┐
│             KEY VAULT INTEGRATION                            │
│                                                              │
│  1. Store secret in Key Vault                                │
│     Key Vault → Secret Name: "DB-PASSWORD"                   │
│     Secret Value: "SuperSecretProd123"                       │
│                                                              │
│  2. Get the secret URL                                       │
│     https://mykeyvault.vault.azure.net/secrets/DB-PASSWORD   │
│                                                              │
│  3. Reference it in App Settings                             │
│     Key: DB_PASSWORD                                         │
│     Value: @Microsoft.KeyVault(SecretUri=https://...)        │
│                                                              │
│  4. Function code reads it normally                          │
│     process.env.DB_PASSWORD                                  │
│     ↓ Azure resolves Key Vault reference automatically       │
│     "SuperSecretProd123"                                     │
└──────────────────────────────────────────────────────────────┘

Managing Multiple Environments

Most real applications have at least three environments: development, staging, and production. Each environment needs different settings (different databases, different API endpoints, different log levels).

Best Practices for Configuration

• Never hardcode any secret, connection string, or API key in code
• Always add local.settings.json to .gitignore
• Use Azure Key Vault for passwords and certificates in production
• Prefix related settings with a common name (e.g., DB_HOST, DB_PORT, DB_NAME)
• Document all required settings in a README.md file so other developers know what to configure
• Use the same setting names across all environments — only the values change