Events
May 19, 6 PM - May 23, 12 AM
Calling all developers, creators, and AI innovators to join us in Seattle @Microsoft Build May 19-22.
Register todayThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
This article explains how to configure common settings for web apps, a mobile back end, or an API app. For Azure Functions, see App settings reference for Azure Functions.
Note
Starting June 1, 2024, newly created App Service apps can generate a unique default host name that uses the naming convention <app-name>-<random-hash>.<region>.azurewebsites.net
. For example: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
. Existing app names remain unchanged.
For more information, see the blog post about creating a web app with a unique default host name.
In Azure App Service, app settings are variables passed as environment variables to the application code. The following conditions apply to app settings:
For example, to set an environment variable in App Service for Linux with the value "pa$$w0rd\"
, the string for the app setting should be "pa\$\$w0rd\\"
.
For Linux apps and custom containers, App Service passes app settings to the container by using the --env
flag to set the environment variable in the container. In either case, they're injected into your app environment at app startup. When you add, remove, or edit app settings, App Service triggers an app restart.
For ASP.NET and ASP.NET Core developers, configuring app settings in App Service is like configuring them in <appSettings>
in Web.config
or appsettings.json
. The values in App Service override the ones in Web.config
or appsettings.json
. You can keep development settings, such as local MySQL password, in Web.config
or appsettings.json
. You can keep production secrets, such as Azure MySQL database password, safely in App Service. The same code uses your development settings when you debug locally. It uses your production secrets when you deploy it to Azure.
Other language stacks get the app settings as environment variables at runtime. For steps that are specific to each language stack, see:
App settings are always encrypted when they're stored (encrypted at rest).
Note
If you store secrets in app settings, consider using Azure Key Vault references. If your secrets are for connectivity to back-end resources, consider connectivity options that are more secure and that don't require secrets. For more information, see Secure connectivity to Azure services and databases from Azure App Service.
In the Azure portal, search for and select App Services, and then select your app.
On the app's left menu, select Settings > Environment variables. Then select App settings.
By default, values for app settings are hidden in the portal for security. To see a hidden value of an app setting, under Value, select Show value. To see the hidden values of all app settings, select Show values.
Note
Read/Write user permimssions are required to view this section in the Azure portal. RBAC built-in roles with sufficient permissions are Owner, Contributor, and Website Contributor. The Reader role alone would not be allowed to access this page.
To add a new app setting, select Add. To edit a setting, select the setting.
In the dialog, you can stick the setting to the current slot.
Note
In a default Linux app service or a custom Linux container, any nested JSON key structure in the app setting name needs to be configured differently for the key name. Replace any colon (:
) with a double underscore (__
). Replace any period (.
) with a single underscore (_
). For example, ApplicationInsights:InstrumentationKey
needs to be configured in App Service as ApplicationInsights__InstrumentationKey
for the key name.
When you finish, select Apply. Then select Apply on the Environment variables page.
App settings have the following JSON formatting:
[
{
"name": "<key-1>",
"value": "<value-1>",
"slotSetting": false
},
{
"name": "<key-2>",
"value": "<value-2>",
"slotSetting": false
},
...
]
This section describes how to configure connection strings.
Note
Consider connectivity options that are more secure and that don't require connection secrets. For more information, see Secure connectivity to Azure services and databases from Azure App Service.
For ASP.NET and ASP.NET Core developers, setting connection strings in App Service is like setting them in <connectionStrings>
in Web.config
. The values that you set in App Service override the ones in Web.config
. You can keep development settings, such as a database file, in Web.config
. You can keep production secrets, such as SQL database credentials, safely in App Service. The same code uses your development settings when you debug locally. It uses your production secrets when you deploy it to Azure.
For other language stacks, it's better to use app settings instead. Connection strings require special formatting in the variable keys to access the values.
There's one case where you might want to use connection strings instead of app settings for non-.NET languages. Certain Azure database types are backed up along with the app only if you configure a connection string for the database in your App Service app. For more information, see Create a custom backup. If you don't need this automated backup, use app settings.
At runtime, connection strings are available as environment variables, prefixed with the following connection types:
SQLCONNSTR_
MYSQLCONNSTR_
SQLAZURECONNSTR_
CUSTOMCONNSTR_
POSTGRESQLCONNSTR_
NOTIFICATIONHUBCONNSTR_
SERVICEBUSCONNSTR_
EVENTHUBCONNSTR_
DOCDBCONNSTR_
REDISCACHECONNSTR_
Note
.NET apps that target PostgreSQL, Notification Hubs, Service Bus, Event Hubs, Azure Cosmos DB, and Redis cache should set the connection string to Custom as a workaround for a known issue in .NET EnvironmentVariablesConfigurationProvider.
For example, a MySQL connection string named connectionstring1 can be accessed as the environment variable MYSQLCONNSTR_connectionString1
. For steps that are specific to each language stack, see:
Connection strings are always encrypted when they're stored (encrypted at rest).
Note
You can also resolve connection strings from Key Vault by using Key Vault references.
In the Azure portal, search for and select App Services, and then select your app.
On the app's left menu, select Settings > Environment variables. Then select Connection strings.
By default, values for connection strings are hidden in the portal for security. To see a hidden value of a connection string, under Value, select Show value. To see the hidden values of all connection strings, select Show values.
To add a new connection string, select Add. To edit a connection string, select the connection string.
In the dialog, you can stick the connection string to the current slot.
When you finish, select Apply. Then select Apply on the Environment variables page.
Connection strings have the following JSON formatting:
[
{
"name": "name-1",
"value": "conn-string-1",
"type": "SQLServer",
"slotSetting": false
},
{
"name": "name-2",
"value": "conn-string-2",
"type": "PostgreSQL",
"slotSetting": false
},
...
]
To configure language stack settings, see these resources:
To configure general settings, follow the steps for your preferred tools.
In the Azure portal, search for and select App Services, and then select your app.
On the app's left menu, select Settings > Configuration. Then select General settings.
Here, you can configure some common settings for the app. Some settings require you to scale up to higher pricing tiers.
Stack settings: Configure settings for the software stack to run the app, including the language and SDK versions.
For Linux apps, you can select the language runtime version and set an optional startup command.
Platform settings: Configure settings for the hosting platform, including:
Platform: Choose 32-bit or 64-bit. For Windows apps only.
FTP state: Allow only FTPS, or disable FTP altogether.
HTTP version: Set to 2.0 to enable support for the HTTPS/2 protocol.
Note
Most modern browsers support the HTTP/2 protocol over TLS only. Unencrypted traffic continues to use HTTP/1.1. To ensure that client browsers connect to your app with HTTP/2, secure your custom DNS name. For more information, see Provide security for a custom DNS name with a TLS/SSL binding in App Service.
Web sockets: Configure for ASP.NET SignalR or socket.io, for example.
Always On: Turn on if you want to keep the app loaded even when there's no traffic.
When Always On is turned off (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time.
When Always On is turned on, the front-end load balancer sends a GET
request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
Always On is required for continuous WebJobs or for WebJobs that a cron expression triggers.
Session affinity: In a multiple-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to Off for stateless applications.
Session affinity proxy: Turn on if your app is behind a reverse proxy (like Azure Application Gateway or Azure Front Door) and you're using the default host name. The domain for the session affinity cookie aligns with the forwarded host name from the reverse proxy.
HTTPS Only: Enable if you want to redirect all HTTP traffic to HTTPS.
Minimum TLS version: Select the minimum TLS encryption version that your app requires.
Debugging: Enable remote debugging for ASP.NET, ASP.NET Core, or Node.js apps. This option turns off automatically after 48 hours.
Incoming client certificates: Require client certificates in mutual authentication.
The default document is the webpage that appears at the root URL of an App Service app. The first matching file in the list is used. If the app uses modules that route based on URL instead of serving static content, there's no need for default documents.
The setting to configure default documents is only for Windows apps.
By default, App Service starts your app from the root directory of your app code. But certain web frameworks don't start in the root directory. For example, Laravel starts in the public
subdirectory. Such an app would be accessible at http://contoso.com/public
, for example, but you typically want to direct http://contoso.com
to the public
directory instead. If your app's startup file is in a different folder, or if your repository has more than one application, you can edit or add virtual applications and directories.
The feature of mapping a virtual directory to a physical path is available only on Windows apps.
In the Azure portal, search for and select App Services, and then select your app.
On the app's left menu, select Settings > Configuration. Then select Path mappings.
Select New virtual application or directory. Then take one of these actions:
D:\home
).Select Ok. Then select Save on the Configuration page.
For Windows apps, you can customize the IIS handler mappings and virtual applications and directories. Handler mappings let you add custom script processors to handle requests for specific file extensions.
To add a custom handler:
In the Azure portal, search for and select App Services, and then select your app.
On the app's left menu, select Settings > Configuration. Then select Path mappings.
Select New handler mapping. Configure the handler as follows:
*.php
or handler.fcgi
.D:\home\site\wwwroot
to refer to your app's root directory.Select Ok. Then select Save on the Configuration page.
Events
May 19, 6 PM - May 23, 12 AM
Calling all developers, creators, and AI innovators to join us in Seattle @Microsoft Build May 19-22.
Register todayTraining