Manage App Settings and Secrets in Azure Functions (2026)

Azure Functions can store application settings and secrets in a few different places, but the most common and recommended way is through the Azure portal’s "Configuration" blade. This is where you’ll find "Application settings" and "Connection strings," which are both essentially key-value pairs that your function code can access.

Let’s see this in action. Imagine you have a Python Azure Function that needs to connect to a Cosmos DB. You’d store the Cosmos DB connection string in your Function App’s configuration.

import os
import azure.cosmos.cosmos_client as cosmos_client

def main(myblob: func.Blob):
    cosmos_db_connection_string = os.environ["COSMOS_DB_CONNECTION_STRING"]
    client = cosmos_client.CosmosClient.from_connection_string(cosmos_db_connection_string)
    # ... rest of your logic

In the Azure portal, you’d navigate to your Function App, then to "Configuration," and under "Application settings," you’d add a new setting:

• Name: COSMOS_DB_CONNECTION_STRING
• Value: AccountEndpoint=https://your-cosmos-db.documents.azure.com:443/;AccountKey=YOUR_PRIMARY_KEY;

When your function runs, os.environ["COSMOS_DB_CONNECTION_STRING"] will resolve to the value you’ve stored.

Beyond simple configuration, "Connection strings" are a specific type for database, storage, and other services. While they function similarly to application settings, they offer a slightly more structured way to manage these common credentials. The portal provides specific input fields for common services like Azure SQL Database, Cosmos DB, and Storage Accounts, which can pre-format the connection string for you.

The real power here is that you can update these settings without redeploying your function code. If your database password changes, you update it in the Azure portal, and the next time your function starts up (or if it’s already running and picks up the change, depending on the host settings), it will use the new credentials. This is crucial for security and manageability.

For secrets, like API keys or database passwords, Azure Key Vault integration is the best practice. Instead of storing sensitive values directly in application settings, you store them in Key Vault and then reference them from your Function App’s configuration.

To set this up:

1. Create an Azure Key Vault: If you don’t have one, create a Key Vault resource in Azure.
2. Add your secret: In your Key Vault, add a secret (e.g., MyApiSecret) with its value.
3. Grant access to your Function App: Navigate to your Function App’s "Identity" blade and enable a System Assigned Managed Identity. Then, go to your Key Vault’s "Access policies" and add a new policy. Select "Secret Permissions" (Get, List) and grant it to your Function App’s managed identity.
4. Reference the secret in Function App settings: In your Function App’s "Configuration" blade, under "Application settings," add a new setting. For example:
   • Name: MY_API_KEY
   • Value: @Microsoft.KeyVault(SecretUri=https://your-keyvault-name.vault.azure.sec/secrets/MyApiSecret/your-secret-version)

Your function code would then access os.environ["MY_API_KEY"] as usual, and the Azure Functions runtime would transparently fetch the secret from Key Vault using the Function App’s managed identity.

The application settings and connection strings are environment variables available to your function process. The Azure Functions host injects these values into the Environment of the running process. This means you can access them using standard language-specific methods for reading environment variables, such as os.environ in Python, process.env in Node.js, or Environment.GetEnvironmentVariable in C#.

One thing most people don’t realize is that application settings can also be used to configure the behavior of the Azure Functions host itself. For instance, you can control the AzureWebJobsStorage setting, which dictates the storage account used for internal Azure Functions operations like managing triggers and logging. Changing this value can shift where the host keeps its operational data.

The next conceptual hurdle is understanding how these settings are applied during different deployment slots, allowing you to test configurations in a staging environment before swapping to production.