Deploy your app to Azure App Service

This article helps you determine the best option to deploy the files for your web app, mobile app backend, or API app to Azure App Service, and then guides you to appropriate resources with instructions specific to your preferred option.

Azure App Service deployment overview

Azure App Service maintains the application framework for you (ASP.NET, PHP, Node.js, etc). Some frameworks are enabled by default while others, like Java and Python, may need a simple checkmark configuration to enable it. In addition, you can customize your application framework, such as the PHP version or the bitness of your runtime. For more information, see Configure your app in Azure App Service.

Since you don't have to worry about the web server or application framework, deploying your app to App Service is a matter of deploying your code, binaries, content files, and their respective directory structure, to the /site/wwwroot directory in Azure (or the /site/wwwroot/App_Data/Jobs/ directory for WebJobs). App Service supports three different deployment processes. All the deployment methods in this article use one of the following processes:

  • FTP or FTPS: Use your favorite FTP or FTPS enabled tool to move your files to Azure, from FileZilla to full-featured IDEs like NetBeans. This is strictly a file upload process. No additional services are provided by App Service, such as version control, file structure management, etc.
  • Kudu (Git/Mercurial or OneDrive/Dropbox): Kudu is the deployment engine in App Service. Push your code to Kudu directly from any repository. Kudu also provides added services whenever code is pushed to it, including version control, package restore, MSBuild, and web hooks for continuous deployment and other automation tasks. The Kudu deployment engine supports 3 different types of deployment sources:

    • Content sync from OneDrive and Dropbox
    • Repository-based continuous deployment with auto-sync from GitHub, Bitbucket, and Visual Studio Team Services
    • Repository-based deployment with manual sync from local Git
  • Web Deploy: Deploy code to App Service directly from your favorite Microsoft tools such as Visual Studio using the same tooling that automates deployment to IIS servers. This tool supports diff-only deployment, database creation, transforms of connection strings, etc. Web Deploy differs from Kudu in that application binaries are built before they are deployed to Azure. Similar to FTP, no additional services are provided by App Service.

Popular web development tools support one or more of these deployment processes. While the tool you choose determines the deployment processes you can leverage, the actual DevOps functionality at your disposal depends on the combination of the deployment process and the specific tools you choose. For example, if you perform Web Deploy from Visual Studio with Azure SDK, even though you don't get automation from Kudu, you do get package restore and MSBuild automation in Visual Studio.

Note

These deployment processes don't actually provision the Azure resources that your app may need. However, most of the linked how-to articles show you how to provision the app AND deploy your code to it end-to-end. You can also find additional options for provisioning Azure resources in the Automate deployment by using command-line tools section.

Deploy manually by uploading files with FTP

If you are used to manually copying your web content to a web server, you can use an FTP utility to copy files, such as Windows Explorer or FileZilla.

The pros of copying files manually are:

  • Familiarity and minimal complexity for FTP tooling.
  • Knowing exactly where your files are going.
  • Added security with FTPS.

The cons of copying files manually are:

  • Having to know how to deploy files to the correct directories in App Service.
  • No version control for rollback when failures occur.
  • No built-in deployment history for troubleshooting deployment issues.
  • Potential long deployment times because many FTP tools don't provide diff-only copying and simply copy all the files.

How to upload files with FTP

The Azure Portal gives you all the information you need to connect to your app's directories using FTP or FTPS.

Deploy by syncing with a cloud folder

A good alternative to copying files manually is syncing files and folders to App Service from a cloud storage service like OneDrive and Dropbox. Syncing with a cloud folder utilizes the Kudu process for deployment (see Overview of deployment processes).

The pros of syncing with a cloud folder are:

  • Simplicity of deployment. Services like OneDrive and Dropbox provide desktop sync clients, so your local working directory is also your deployment directory.
  • One-click deployment.
  • All functionality in the Kudu deployment engine is available (e.g. package restore, automation).

The cons of syncing with a cloud folder are:

  • No version control for rollback when failures occur.
  • No automated deployment, manual sync is required.

How to deploy by syncing with a cloud folder

In the Azure Portal, you can designate a folder for content sync in your OneDrive or Dropbox cloud storage, work with your app code and content in that folder, and sync to App Service with the click of a button.

Deploy continuously from a cloud-based source control service

If your development team uses a cloud-based source code management (SCM) service like Visual Studio Team Services, GitHub, or BitBucket, you can configure App Service to integrate with your repository and deploy continuously.

The pros of deploying from a cloud-based source control service are:

  • Version control to enable rollback.
  • Ability to configure continuous deployment for Git (and Mercurial where applicable) repositories.
  • Branch-specific deployment, can deploy different branches to different slots.
  • All functionality in the Kudu deployment engine is available (e.g. deployment versioning, rollback, package restore, automation).

The con of deploying from a cloud-based source control service is:

  • Some knowledge of the respective SCM service required.

How to deploy continuously from a cloud-based source control service

In the Azure Portal, you can configure continuous deployment from GitHub, Bitbucket, and Visual Studio Team Services.

To find out how to configure continuous deployment manually from a cloud repository not listed by the Azure Portal (such as GitLab), see Setting up continuous deployment using manual steps.

Deploy from local Git

If your development team uses an on-premises local source code management (SCM) service based on Git, you can configure this as a deployment source to App Service.

Pros of deploying from local Git are:

  • Version control to enable rollback.
  • Branch-specific deployment, can deploy different branches to different slots.
  • All functionality in the Kudu deployment engine is available (e.g. deployment versioning, rollback, package restore, automation).

Cons of deploying from local Git is:

  • Some knowledge of the respective SCM system required.
  • No turn-key solutions for continuous deployment.

How to deploy from local Git

In the Azure Portal, you can configure local Git deployment.

Deploy using an IDE

If you are already using Visual Studio with an Azure SDK, or other IDE suites like Xcode, Eclipse, and IntelliJ IDEA, you can deploy to Azure directly from within your IDE. This option is ideal for an individual developer.

Visual Studio supports all three deployment processes (FTP, Git, and Web Deploy), depending on your preference, while other IDEs can deploy to App Service if they have FTP or Git integration (see Overview of deployment processes).

The pros of deploying using an IDE are:

  • Potentially minimize the tooling for your end-to-end application life-cycle. Develop, debug, track, and deploy your app to Azure all without moving outside of your IDE.

The cons of deploying using an IDE are:

  • Added complexity in tooling.
  • Still requires a source control system for a team project.

Additional pros of deploying using Visual Studio with Azure SDK are:

  • Azure SDK makes Azure resources first-class citizens in Visual Studio. Create, delete, edit, start, and stop apps, query the backend SQL database, live-debug the Azure app, and much more.
  • Live editing of code files on Azure.
  • Live debugging of apps on Azure.
  • Integrated Azure explorer.
  • Diff-only deployment.

How to deploy from Visual Studio directly

How to deploy using the Azure Toolkits for Eclipse and IntelliJ IDEA

Microsoft makes it possible to deploy Web Apps to Azure directly from Eclipse and IntelliJ via the Azure Toolkit for Eclipse and Azure Toolkit for IntelliJ. The following tutorials illustrate the steps that are involved in deploying simple a "Hello" world Web App to Azure using either IDE:

Automate deployment by using command-line tools

If you prefer the command-line terminal as the development environment of choice, you can script deployment tasks for your App Service app using command-line tools.

Pros of deploying by using command-line tools are:

  • Enables scripted deployment scenarios.
  • Integrate provisioning of Azure resources and code deployment.
  • Integrate Azure deployment into existing continous integration scripts.

Cons of deploying by using command-line tools are:

  • Not for GUI-preferring developers.

How to automate deployment with command-line tools

See Automate deployment of your Azure app with command-line tools for a list of command-line tools and links to tutorials.

Next Steps

In some scenarios you might want to be able to easily switch back and forth between a staging and a production version of your app. For more information, see Staged Deployment on Web Apps.

Having a backup and restore plan in place is an important part of any deployment workflow. For information about the App Service backup and restore feature, see Web Apps Backups.

For information about how to use Azure's Role-Based Access Control to manage access to App Service deployment, see RBAC and Web App Publishing.