I’m working on an Azure Static Web App project using VS Code with the Azure extension. I followed some tutorials to create the API part using Node.js and added several functions that work perfectly when running locally. These functions connect to table storage using bindings, so I set up the AzureWebJobsStorage setting in my local.settings.json file to connect to my Azure Storage Account. Local testing works great.
However, when I deploy and try to use the live app, the API functions fail. I’m getting a System.InvalidOperationException from the Microsoft.Azure.WebJobs.StorageAccountProvider.Get method.
I know that local.settings.json only works for local development. When I tried adding AzureWebJobsStorage as an App Setting in the Azure Portal, it gave me an error saying this setting isn’t allowed. I read that Static Web Apps manages this setting automatically.
My question: What’s the correct way to configure which storage account my Static Web App API functions should use for their table storage bindings?
Indeed, you’ve encountered a known limitation of Azure Static Web Apps. The platform restricts certain configuration keys, such as AzureWebJobsStorage, for security purposes. A solution I found effective recently is to create your own custom connection string in the Azure portal under app settings. For instance, I named mine CUSTOM_STORAGE_CONNECTION and input the respective storage account connection string there. You then need to modify your function bindings to reference this new name instead of AzureWebJobsStorage. Make sure to update the connection property in your function.json files to point to your newly created setting. After deployment, it’s wise to test everything since binding behavior may vary in Static Web Apps compared to standard Azure Functions.
This happens because Static Web Apps lock down certain settings - you can’t override them through the portal. I hit the same problem when I moved a project from regular Azure Functions to Static Web Apps. Here’s the fix: create a custom connection string with a different name instead of using AzureWebJobsStorage. Add a new setting in the portal called something like TableStorageConnection and paste your storage account connection string there. Then update your function.json files to point to this custom setting name in the connection property. It’s basically a workaround that gets you the same result. Redeploy your Static Web App after these changes and your table storage bindings should work fine in production.
had this same problem b4! just add the storage conn string as an app setting but rename it something like StorageConnection or TableStorageConnectionString. then update ur funct bindings to use that new name instead of AzureWebJobsStorage. SWA blocks the default name but allows custom ones.