Configure web apps in Azure App Service
This topic explains how to configure a web app using the Azure Portal.
- In the Azure Portal, open the blade for the web app.
- Click All Settings.
- Click Application Settings.
The Application settings blade has settings grouped under several categories.
Framework versions. Set these options if your app uses any these frameworks:
- .NET Framework: Set the .NET framework version.
- PHP: Set the PHP version, or **OFF **to disable PHP.
- Java: Select the Java version or OFF to disable Java. Use the Web Container option to choose between Tomcat and Jetty versions.
- Python: Select the Python version, or OFF to disable Python.
For technical reasons, enabling Java for your app disables the .NET, PHP, and Python options.
Platform. Selects whether your web app runs in a 32-bit or 64-bit environment. The 64-bit environment requires Basic or Standard mode. Free and Shared modes always run in a 32-bit environment.
Web Sockets. Set ON to enable the WebSocket protocol; for example, if your web app uses ASP.NET SignalR or socket.io.
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.
Managed Pipeline Version. Sets the IIS pipeline mode. Leave this set to Integrated (the default) unless you have a legacy app that requires an older version of IIS.
Auto Swap. If you enable Auto Swap for a deployment slot, App Service will automatically swap the web app into production when you push an update to that slot. For more information, see Deploy to staging slots for web apps in Azure App Service.
Remote Debugging. Enables remote debugging. When enabled, you can use the remote debugger in Visual Studio to connect directly to your web app. Remote debugging will remain enabled for 48 hours.
This section contains name/value pairs that you web app will load on start up.
For .NET apps, these settings are injected into your .NET configuration
AppSettings at runtime, overriding existing settings.
PHP, Python, Java and Node applications can access these settings as environment variables at runtime. For each app setting, two environment variables are created; one with the name specified by the app setting entry, and another with a prefix of APPSETTING_. Both contain the same value.
Connection strings for linked resources.
For .NET apps, these connection strings are be injected into your .NET configuration
connectionStrings settings at runtime, overriding existing entries where the key equals the linked database name.
For PHP, Python, Java and Node applications, these settings will be available as environment variables at runtime, prefixed with the connection type. The environment variable prefixes are as follows:
- SQL Server: SQLCONNSTR_
- MySQL: MYSQLCONNSTR_
- SQL Database: SQLAZURECONNSTR_
- Custom: CUSTOMCONNSTR_
For example, if a MySql connection string were named
connectionstring1, it would be accessed through the environment variable
The default document is the web page that is displayed at the root URL for a website. The first matching file in the list is used.
Web apps might use modules that route based on URL, rather than serving static content, in which case there is no default document as such.
Use this area to add custom script processors to handle requests for specific file extensions.
- Extension. The file extension to be handled, such as *.php or handler.fcgi.
- Script Processor Path. The absolute path of the script processor. Requests to files that match the file extension will be processed by the script processor. Use the path
D:\home\site\wwwroot to refer to your app's root directory.
- Additional Arguments. Optional command-line arguments for the script processor
Virtual applications and directories
To configure virtual applications and directories, specify each virtual directory and its corresponding physical path relative to the website root. Optionally, you can select the Application checkbox to mark a virtual directory as an application.
Enabling diagnostic logs
To enable diagnostic logs:
- In the blade for your web app, click All settings.
- Click Diagnostic logs.
Options for writing diagnostic logs from a web application that supports logging:
- Application Logging. Writes application logs to the file system. Logging lasts for a period of 12 hours.
Level. When application logging is enabled, this option specifies the amount of information that will be recorded (Error, Warning, Information, or Verbose).
Web server logging. Logs are saved in the W3C extended log file format.
Detailed error messages. Saves detailed error messages .htm files. The files are saved under /LogFiles/DetailedErrors.
Failed request tracing. Logs failed requests to XML files. The files are saved under /LogFiles/W3SVCxxx, where xxx is a unique identifier. This folder contains an XSL file and one or more XML files. Make sure to download the XSL file, because it provides functionality for formatting and filtering the contents of the XML files.
To view the log files, you must create FTP credentials, as follows:
- In the blade for your web app, click All settings.
- Click Deployment credentials.
- Enter a user name and password.
- Click Save.
The full FTP user name is “app\username” where app is the name of your web app. The username is listed in the web app blade, under Essentials.
Other configuration tasks
In Basic or Standard mode, you can upload SSL certificates for a custom domain. For more information, see Enable HTTPS for a web app.
To view your uploaded certificates, click All Settings > Custom domains and SSL.
Add custom domain names for your web app. For more information, see Configure a custom domain name for a web app in Azure App Service.
To view your domain names, click All Settings > Custom domains and SSL.
To view your deployment slots, click All Settings > Deployment slots.
In Basic or Standard mode, you can test the availability of HTTP or HTTPS endpoints, from up to three geo-distributed locations. A monitoring test fails if the HTTP response code is an error (4xx or 5xx) or the response takes more than 30 seconds. An endpoint is considered available if the monitoring tests succeed from all the specified locations.
For more information, see How to: Monitor web endpoint status.
If you want to get started with Azure App Service before signing up for an Azure account, go to Try App Service, where you can immediately create a short-lived starter web app in App Service. No credit cards required; no commitments.