Aspire Functions Secrets

This check is required when all of these are true:

Detection

Run the scan script — it finds *.cs files that call AddAzureFunctionsProject, checks whether each one already sets AzureWebJobsSecretStorageType, and prints a single verdict so you don’t have to parse raw grep output.

Bash — scripts/scan-aspire-functions-secrets.sh:

PowerShell — scripts/scan-aspire-functions-secrets.ps1:

The script prints one of three verdicts:

Fix

Add .WithEnvironment("AzureWebJobsSecretStorageType", "Files") to the Azure Functions project builder chain in the AppHost source file that contains the AddAzureFunctionsProject call (often Program.cs in the *.AppHost project).

Before

After

💡 Tip: Place .WithEnvironment(...) immediately after .WithHostStorage(...) for clarity.

Why This Is Required

Azure Functions needs storage for managing host secrets/keys (function keys, host keys, master key). By default, it stores them as blobs in the AzureWebJobsStorage account.

When Aspire configures identity-based storage access (via WithHostStorage), it sets URI-based environment variables like AzureWebJobsStorage__blobServiceUri instead of a connection string. The Functions runtime’s secret manager does not support these identity-based URIs — it requires either a connection string or SAS token.

Setting AzureWebJobsSecretStorageType=Files switches the Functions host to file-system-based key storage, bypassing the blob storage dependency for secrets.

Error Without This Setting

When This Check Does NOT Apply