HTTPS clone URL
Subversion checkout URL
Managing settings and secrets
- Accessing files via ftp
- Accessing the kudu service
- Analyzing a git client trace
- Anatomy of a git request
- Azure runtime environment
- Azure Site Extensions
- Azure Web App sandbox
- Azure Web Sites Development Stacks
- Blog posts and screencasts
- Configurable settings
- Continuous deployment
- Cool user tweets
- Cool WebJobs tweets
- Custom Deployment Script
- Customizing deployments
- Deploy locally built private kudu to azure
- Deploying from github
- Deploying inplace and without repository
- Deploying Perl apps
- Deploying to a server
- Deployment branch
- Deployment credentials
- Deployment Environment
- Deployment hooks
- Deployment Logic Flow
- Deployment vs runtime issues
- Diagnostic Log Stream
- File structure on azure
- Getting started
- Git workflow
- Information about other Azure Web Apps features
- Investigating continuous deployment
- Investigating issues
- Known issues
- Kudu architecture
- Kudu console
- Kudu deployment configuration prototype
- Kudu deployment script .cmd
- Make sure all your files are committed
- Make sure site correctly deploys locally
- Managing settings and secrets
- Post Deployment Action Hooks
- Process list and minidump
- Process Threads list and minidump gcdump diagsession
- Project governance model
- Project Structure
- Reporting WebJobs issues
- Reporting your site name without posting it publicly
- REST API
- Running tests
- Troubleshooting Node errors
- Troubleshooting PHP errors
- Understanding site swaps
- Using a custom web.config for Node apps
- Using a git repo to report an issue
- Version history
- VSO vs Kudu deployments
- Web hooks
- Web Jobs
- WebJobs API
- Xdt transform samples
Clone this wiki locally
When you deploy a site to Azure using git, all the files come from a git repository. If your site needs any secrets at runtime (e.g. credentials to access some external resource), it's generally a bad idea to commit those secrets to your repository. Even if it's a private repo, you may not want every developer working on the project to have access to those secrets.
In other cases, it's not really about the values being secrets, but simply about needing different values at runtime in Azure from the ones you use at development time on your own box.
The way to solve this is Azure Web Sites is to use runtime app settings. These are just a bunch of Key/Value pairs that you can find in the Configure section of the portal. They work in slightly different ways for .NET sites and for other sites.
Suppose you have a .NET site that has something like this in its web.config:
<appSettings> <add key="MyKey" value="Some default value" /> </appSettings>
And somewhere in your code, you use
ConfigurationManager.AppSettings["MyKey"] to access the value. The value you hard code into your web.config will typically be some default that is safe for the world to see. Or you may simply not have anything in there, and have the code fall back to some default behavior.
But when you deploy your site to Azure, you'd like this setting to take on a specific value, which may very well be a secret.
All you have to do here is add en entry in the portal's 'app settings' section (in the Confugure tab for an site). You make the Key be "MyKey", and the value is whatever you want it to be.
Then when the site runs in Azure, the call to
ConfigurationManager.AppSettings["MyKey"] will return this value instead of the one that's hard coded in your web.config.
Note that in order to do this, it never actually modifies your physical web.config file. Instead, it directly affects the runtime behavior of the .NET configuration system to make it use those alternative values. You can verify this by downloading your webconfig file (see Accessing files via ftp), and seeing that it is unchanged.
Outside of the .NET world, sites tend to simply rely on environment variables for settings, instead of having them in a web.config-like file.
e.g. in a Node app, you might have:
var mySetting = process.env.MyKey || "Some default value";
To modify this value in an Azure Web Site, you so the exact same thing as in the .NET case below: you add the new key/value pair in the portal's 'app settings' section. This causes Azure to inject this environment variable into the process running your app.
Note that even in .NET app, you end up getting this environment variable. But in most cases, .NET apps ignore it and rely on web.config instead.