Deploy your app to Azure App Service

12 min to read Contributors

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 the following deployment options:

  • 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): Use 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 via FTP by copying files to Azure manually

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 deploy by copying files to Azure manually

Copying files to Azure involves a few simple steps:

  1. Assuming you already established deployment credentials, obtain the FTP connection information by going to Settings > Properties, and then copying the values for FTP/Deployment User, FTP Host Name, and FTPS Host Name. Please copy the FTP/Deployment User user value as displayed by the Azure Portal including the app name in order to provide proper context for the FTP server.

    FTP Connection Information FTP Deployment Credentials

  2. From your FTP client, use the connection information you gathered to connect to your app.
  3. Copy your files and their respective directory structure to the /site/wwwroot directory in Azure (or the /site/wwwroot/App_Data/Jobs/ directory for WebJobs).
  4. Browse to your app's URL to verify the app is running properly.

For more information, see the following resource:

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.

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).

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.

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).

Con 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

Another deployment option is to use a cloud-based service such as Octopus Deploy. For more information, see Deploy ASP.NET applications to Azure Web Sites.

Automate deployment with MSBuild

If you use the Visual Studio IDE for development, you can use MSBuild to automate anything you can do in your IDE. You can configure MSBuild to use either Web Deploy or FTP/FTPS to copy files. Web Deploy can also automate many other deployment-related tasks, such as deploying databases.

For more information about command-line deployment using MSBuild, see the following resources:

Automate deployment with Windows PowerShell

You can perform MSBuild or FTP deployment functions from Windows PowerShell. If you do that, you can also use a collection of Windows PowerShell cmdlets that make the Azure REST management API easy to call.

For more information, see the following resources:

Automate deployment with .NET management API

You can write C# code to perform MSBuild or FTP functions for deployment. If you do that, you can access the Azure management REST API to perform site management functions.

For more information, see the following resource:

Deploy from Azure Command-Line Interface (Azure CLI)

You can use the command line in Windows, Mac or Linux machines to deploy by using FTP. If you do that, you can also access the Azure REST management API using the Azure CLI.

For more information, see the following resource:

Deploy from Web Deploy command line

Web Deploy is Microsoft software for deployment to IIS that not only provides intelligent file sync features but also can perform or coordinate many other deployment-related tasks that can't be automated when you use FTP. For example, Web Deploy can deploy a new database or database updates along with your web app. Web Deploy can also minimize the time required to update an existing site since it can intelligently copy only changed files. Microsoft Visual Studio and Team Foundation Server have support for Web Deploy built-in, but you can also use Web Deploy directly from the command line to automate deployment. Web Deploy commands are very powerful but the learning curve can be steep.

For more information, see the following resource:

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.

See Also

For more information about using Azure with Java, see the Azure Java Developer Center.