{

"source_path": "articles/app-service/web-sites-configure.md",

"redirect_url": "/azure/app-service/configure-common",

"redirect_document_id": false

},

"redirect_url": "/azure/app-service/configure-common",

"redirect_url": "/azure/app-service/configure-common",

"redirect_url": "/azure/app-service/configure-common",

- name: Configure common settings

href: ../app-service/configure-common.md?toc=%2fazure%2fapp-service-mobile%2ftoc.json

Key Vault references can be used as values for [Application Settings](configure-common.md#configure-app-settings), allowing you to keep secrets in Key Vault instead of the site config. Application Settings are securely encrypted at rest, but if you need secret management capabilities, they should go into Key Vault.

title: Configure apps in the portal - Azure App Service

description: Learn to configure common settings for an App Service app in the Azure portal.

keywords: azure app service, web app, app settings, environment variables

services: app-service\web

documentationcenter: ''

author: cephalin

manager: erikre

editor: ''

ms.assetid: 9af8a367-7d39-4399-9941-b80cbc5f39a0

ms.service: app-service

ms.workload: na

ms.tgt_pltfrm: na

ms.devlang: na

ms.topic: article

ms.date: 04/25/2017

ms.author: cephalin

ms.custom: seodec18

This topic explains how to configure common settings for web apps, mobile back end, or API app using the [Azure portal].

In App Service, you use app settings like environment variables. In the [Azure portal], navigate to your app's management page. In the app's left menu, click **Configuration** > **Application settings**.


For ASP.NET and ASP.NET Core developers, setting app settings in App Service are like setting them in `<appSettings>` in *Web.config*, but the values in App Service override the ones in *Web.config*. You can keep development settings (e.g. local MySQL password) in *Web.config*, but production secrets (e.g. Azure MySQL database password) safe in App Service. The same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.

Other language stacks, likewise, get the app settings as environment variables at runtime. For language-stack specific steps, see:

- [ASP.NET Core](containers/configure-language-dotnetcore.md#access-environment-variables)

- [Node.js](containers/configure-language-nodejs.md#access-environment-variables)

- [PHP](containers/configure-language-php.md#access-environment-variables)

- [Python](containers/how-to-configure-python.md#access-environment-variables)

- [Java](containers/configure-language-java.md#data-sources)

- [Ruby](containers/configure-language-ruby.md#access-environment-variables)

- [Custom containers](containers/configure-custom-container.md#configure-environment-variables)

App settings are always encrypted when stored (encrypted-at-rest).

By default, values for app settings are hidden in the portal for security. To see a hidden value of an app setting, click the **Value** field of that setting. To see the values of all app settings, click the **Show value** button.

To add a new app setting, click **New application setting**. In the dialog, you can [stick the setting to the current slot](deploy-staging-slots.md#which-settings-are-swapped).

To edit a setting, click the **Edit** button on the right side.

When finished, click **Update**. Don't forget to click **Save** back in the **Configuration** page.

To add or edit app settings in bulk, click the **Advanced edit** button. When finished, click **Update**. Don't forget to click **Save** back in the **Configuration** page.

App settings have the following JSON formatting:

[

{

"name": "<key-1>",

"value": "<value-1>",

"slotSetting": false

},

{

"name": "<key-2>",

"value": "<value-2>",

"slotSetting": false

},

...

]

In the [Azure portal], navigate to the app's management page. In the app's left menu, click **Configuration** > **Application settings**.


For ASP.NET and ASP.NET Core developers, setting connection strings in App Service are like setting them in `<connectionStrings>` in *Web.config*, but the values you set in App Service override the ones in *Web.config*. You can keep development settings (e.g. a database file) in *Web.config* and production secrets (e.g. SQL Database credentials) safe in App Service. The same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.

For other language stacks, it's better to use [app settings](#configure-app-settings) instead, because connection strings require special formatting in the variable keys in order to access the values. Here's one exception, however: certain Azure database types are backed up along with the app if you configure their connection strings in your app. For more information, see [What gets backed up](manage-backup.md#what-gets-backed-up). If you don't need this automated backup, then use app settings.

At runtime, connection strings are available as environment variables, prefixed with the following connection types:

* SQL Server: `SQLCONNSTR_`

* MySQL: `MYSQLCONNSTR_`

* SQL Database: `SQLAZURECONNSTR_`

* Custom: `CUSTOMCONNSTR_`

For example, a MySql connection string named *connectionstring1* can be accessed as the environment variable `MYSQLCONNSTR_connectionString1`. For language-stack specific steps, see:

- [ASP.NET Core](containers/configure-language-dotnetcore.md#access-environment-variables)

- [Node.js](containers/configure-language-nodejs.md#access-environment-variables)

- [PHP](containers/configure-language-php.md#access-environment-variables)

- [Python](containers/how-to-configure-python.md#access-environment-variables)

- [Java](containers/configure-language-java.md#data-sources)

- [Ruby](containers/configure-language-ruby.md#access-environment-variables)

- [Custom containers](containers/configure-custom-container.md#configure-environment-variables)

Connection strings are always encrypted when stored (encrypted-at-rest).

By default, values for connection strings are hidden in the portal for security. To see a hidden value of a connection string, just click the **Value** field of that string. To see the values of all connection strings, click the **Show value** button.

To add a new connection string, click **New connection string**. In the dialog, you can [stick the connection string to the current slot](deploy-staging-slots.md#which-settings-are-swapped).

To edit a setting, click the **Edit** button on the right side.

When finished, click **Update**. Don't forget to click **Save** back in the **Configuration** page.

To add or edit connection strings in bulk, click the **Advanced edit** button. When finished, click **Update**. Don't forget to click **Save** back in the **Configuration** 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

},

...

]

<a name="platform"></a>

<a name="alwayson"></a>

In the [Azure portal], navigate to the app's management page. In the app's left menu, click **Configuration** > **Application settings**.


Here, you can configure some common settings for the app. Some settings require you to [scale up to higher pricing tiers](web-sites-scale.md).

- **Stack settings**: The software stack to run the app, including the language and SDK versions. For Linux apps and custom container apps, you can also set an optional start-up command or file.

- **Platform settings**: Lets you configure settings for the hosting platform, including:

- **Bitness**: 32-bit or 64-bit.

- **WebSocket protocol**: For [ASP.NET SignalR] or [socket.io](https://socket.io/), for example.

- **Always On**: Keep the app loaded even when there's no traffic. You need to enable it for continuous WebJobs or for WebJobs that are triggered using a CRON expression.

- **Managed pipeline version**: The IIS [pipeline mode]. Set it to **Classic** if you have a legacy app that requires an older version of IIS.

- **HTTP version**: Set to **2.0** to enable support for [HTTPS/2](https://wikipedia.org/wiki/HTTP/2) protocol.

> [!NOTE]

> Most modern browsers support HTTP/2 protocol over TLS only, while non-encrypted traffic continues to use HTTP/1.1. To ensure that client browsers connect to your app with HTTP/2, either [buy an App Service Certificate](web-sites-purchase-ssl-web-site.md) for the app's custom domain or [bind a third party certificate](app-service-web-tutorial-custom-ssl.md).

- **ARR affinity**: In a multi-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.

- **Debugging**: Enable remote debugging for [ASP.NET](troubleshoot-dotnet-visual-studio.md#remotedebug), [ASP.NET Core](/visualstudio/debugger/remote-debugging-azure), or [Node.js](containers/configure-language-nodejs.md#debug-remotely) apps. This option turns off automatically after 48 hours.

- **Incoming client certificates**: require client certificates in [mutual authentication](app-service-web-configure-tls-mutual-auth.md).

This setting is only for Windows apps.

In the [Azure portal], navigate to the app's management page. In the app's left menu, click **Configuration** > **Default documents**.


The default document is the web page that's displayed at the root URL for a website. The first matching file in the list is used. To add a new default document, click **New document**. Don't forget to click **Save**.

If the app uses modules that route based on URL instead of serving static content, there is no need for default documents.

In the [Azure portal], navigate to the app's management page. In the app's left menu, click **Configuration** > **Path mappings**.


The **Path mappings** page shows you different things based on the OS type.

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, click **New handler**. Configure the handler as follows:

- **Extension**. The file extension you want to handle, such as *\*.php* or *handler.fcgi*.

- **Script processor**. The absolute path of the script processor to you. Requests to files that match the file extension are processed by the script processor. Use the path `D:\home\site\wwwroot` to refer to your app's root directory.

- **Arguments**. Optional command-line arguments for the script processor.

Each app has the default root path (`/`) mapped to `D:\home\site\wwwroot`, where your code is deployed by default. If your app root is in a different folder, or if your repository has more than one application, you can edit or add virtual applications and directories here. Click **New virtual application or directory**.

To configure virtual applications and directories, specify each virtual directory and its corresponding physical path relative to the website root (`D:\home`). Optionally, you can select the **Application** checkbox to mark a virtual directory as an application.

You can [add custom storage for your containerized app](containers/how-to-serve-content-from-azure-storage.md). Containerized apps include all Linux apps and also the Windows and Linux custom containers running on App Service. Click **New Azure Storage Mount** and configure your custom storage as follows:

- **Name**: The display name.

- **Configuration options**: **Basic** or **Advanced**.

- **Storage accounts**: The storage account with the container you want.

- **Storage type**: **Azure Blobs** or **Azure Files**.

> [!NOTE]

> Windows container apps only support Azure Files.

- **Storage container**: For basic configuration, the container you want.

- **Share name**: For advanced configuration, the file share name.

- **Access key**: For advanced configuration, the access key.

- **Mount path**: The absolute path in your container to mount the custom storage.

For more information, see [Serve content from Azure Storage in App Service on Linux](containers/how-to-serve-content-from-azure-storage.md).

For Linux apps, see:

- [ASP.NET Core](containers/configure-language-dotnetcore.md)

- [Node.js](containers/configure-language-nodejs.md)

- [PHP](containers/configure-language-php.md)

- [Python](containers/how-to-configure-python.md)

- [Java](containers/configure-language-java.md)

- [Ruby](containers/configure-language-ruby.md)

See [Configure a custom Linux container for Azure App Service](containers/configure-custom-container.md)

- [Configure a custom domain name in Azure App Service]

- [Set up staging environments in Azure App Service]

- [Enable HTTPS for an app in Azure App Service]

- [Enable diagnostic logs](troubleshoot-diagnostic-logs.md)

- [Scale an app in Azure App Service]

- [Monitoring basics in Azure App Service]

- [Change applicationHost.config settings with applicationHost.xdt](https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples)

[ASP.NET SignalR]: https://www.asp.net/signalr

[Azure Portal]: https://portal.azure.com/

[Configure a custom domain name in Azure App Service]: ./app-service-web-tutorial-custom-domain.md

[Set up staging environments in Azure App Service]: ./deploy-staging-slots.md

[Enable HTTPS for an app in Azure App Service]: ./app-service-web-tutorial-custom-ssl.md

[How to: Monitor web endpoint status]: https://go.microsoft.com/fwLink/?LinkID=279906

[Monitoring basics in Azure App Service]: ./web-sites-monitor.md

[pipeline mode]: https://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture#Application

[Scale an app in Azure App Service]: ./web-sites-scale.md

In App Service, you can [set app settings](../configure-common.md?toc=%2fazure%2fapp-service%2fcontainers%2ftoc.json#configure-app-settings) outside of your app code. Then you can access them using the standard ASP.NET pattern: