| title | description | ms.custom | ms.topic | ms.date |
|---|---|---|---|---|
Deployment technologies in Azure Functions |
Learn the different ways you can deploy code to Azure Functions. |
vs-azure |
conceptual |
04/25/2019 |
You can use a few different technologies to deploy your Azure Functions project code to Azure. This article provides an overview of the deployment methods available to you and recommendations for the best method to use in various scenarios. It also provides an exhaustive list of and key details about the underlying deployment technologies.
The deployment technology you use to publish code to Azure is generally determined by the way in which you publish your app. The appropriate deployment method is determined by specific needs and the point in the development cycle. For example, during development and testing you may deploy directly from your development tool, such as Visual Studio Code. When your app is in production, you are more likely to publish continuously from source control or by using an automated publishing pipeline, which includes additional validation and testing.
The following table describes the available deployment methods for your Function project.
| Deployment type | Methods | Best for... |
|---|---|---|
| Tools-based | • Visual Studio Code publish • Visual Studio publish • Core Tools publish |
Deployments during development and other ad-hock deployments. Deployments are managed locally by the tooling. |
| App Service-managed | • Deployment Center (CI/CD) • Container deployments |
Continuous deployment (CI/CD) from source control or from a container registry. Deployments are managed by the App Service platform (Kudu). |
| External pipelines | • Azure Pipelines • GitHub actions |
Production and DevOps pipelines that include additional validation, testing, and other actions be run as part of an automated deployment. Deployments are managed by the pipeline. |
While specific Functions deployments use the best technology based on their context, most deployment methods are based on zip deployment.
Azure Functions supports cross-platform local development and hosting on Windows and Linux. Currently, three hosting plans are available:
Each plan has different behaviors. Not all deployment technologies are available for each flavor of Azure Functions. The following chart shows which deployment technologies are supported for each combination of operating system and hosting plan:
| Deployment technology | Windows Consumption | Windows Premium | Windows Dedicated | Linux Consumption | Linux Premium | Linux Dedicated |
|---|---|---|---|---|---|---|
| External package URL1 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Zip deploy | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Docker container | ✔ | ✔ | ||||
| Web Deploy | ✔ | ✔ | ✔ | |||
| Source control | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Local Git1 | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Cloud sync1 | ✔ | ✔ | ✔ | ✔ | ✔ | |
| FTP1 | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Portal editing | ✔ | ✔ | ✔ | ✔2 | ✔2 |
1 Deployment technology that requires manual trigger syncing. 2 Portal editing is enabled only for HTTP and Timer triggers for Functions on Linux using Premium and Dedicated plans.
Some key concepts are critical to understanding how deployments work in Azure Functions.
When you change any of your triggers, the Functions infrastructure must be aware of the changes. Synchronization happens automatically for many deployment technologies. However, in some cases, you must manually sync your triggers. When you deploy your updates by referencing an external package URL, local Git, cloud sync, or FTP, you must manually sync your triggers. You can sync triggers in one of three ways:
- Restart your function app in the Azure portal
- Send an HTTP POST request to
https://{functionappname}.azurewebsites.net/admin/host/synctriggers?code=<API_KEY>using the master key. - Send an HTTP POST request to
https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.Web/sites/<FUNCTION_APP_NAME>/syncfunctiontriggers?api-version=2016-08-01. Replace the placeholders with your subscription ID, resource group name, and the name of your function app.
Azure Functions can automatically perform builds on the code it receives after zip deployments. These builds behave slightly differently depending on whether your app is running on Windows or Linux. Remote builds are not performed when an app has previously been set to run in Run From Package mode. To learn how to use remote build, navigate to zip deploy.
Note
If you're having issues with remote build, it might be because your app was created before the feature was made available (August 1, 2019). Try creating a new function app, or running az functionapp update -g <RESOURCE_GROUP_NAME> -n <APP_NAME> to update your function app. This command might take two tries to succeed.
All function apps running on Windows have a small management app, the SCM (or Kudu) site. This site handles much of the deployment and build logic for Azure Functions.
When an app is deployed to Windows, language-specific commands, like dotnet restore (C#) or npm install (JavaScript) are run.
To enable remote build on Linux, the following application settings must be set:
ENABLE_ORYX_BUILD=trueSCM_DO_BUILD_DURING_DEPLOYMENT=true
By default, both Azure Functions Core Tools and the Azure Functions Extension for Visual Studio Code perform remote builds when deploying to Linux. Because of this, both tools automatically create these settings for you in Azure.
When apps are built remotely on Linux, they run from the deployment package.
Linux function apps running in the Consumption plan don't have an SCM/Kudu site, which limits the deployment options. However, function apps on Linux running in the Consumption plan do support remote builds.
Function apps running on Linux in the Dedicated (App Service) plan and the Premium plan also have a limited SCM/Kudu site.
The following deployment methods are available in Azure Functions.
You can use an external package URL to reference a remote package (.zip) file that contains your function app. The file is downloaded from the provided URL, and the app runs in Run From Package mode.
How to use it: Add
WEBSITE_RUN_FROM_PACKAGEto your application settings. The value of this setting should be a URL (the location of the specific package file you want to run). You can add settings either in the portal or by using the Azure CLI.If you use Azure Blob storage, use a private container with a shared access signature (SAS) to give Functions access to the package. Any time the application restarts, it fetches a copy of the content. Your reference must be valid for the lifetime of the application.
When to use it: External package URL is the only supported deployment method for Azure Functions running on Linux in the Consumption plan, if the user doesn't want a remote build to occur. When you update the package file that a function app references, you must manually sync triggers to tell Azure that your application has changed.
Use zip deploy to push a .zip file that contains your function app to Azure. Optionally, you can set your app to start running from package, or specify that a remote build occurs.
How to use it: Deploy by using your favorite client tool: Visual Studio Code, Visual Studio, or from the command line using the Azure Functions Core Tools. By default, these tools use zip deployment and run from package. Core Tools and the Visual Studio Code extension both enable remote build when deploying to Linux. To manually deploy a .zip file to your function app, follow the instructions in Deploy from a .zip file or URL.
When you deploy by using zip deploy, you can set your app to run from package. To run from package, set the
WEBSITE_RUN_FROM_PACKAGEapplication setting value to1. We recommend zip deployment. It yields faster loading times for your applications, and it's the default for VS Code, Visual Studio, and the Azure CLI.
When to use it: Zip deploy is the recommended deployment technology for Azure Functions.
You can deploy a Linux container image that contains your function app.
How to use it: Create a Linux function app in the Premium or Dedicated plan and specify which container image to run from. You can do this in two ways:
- Create a Linux function app on an Azure App Service plan in the Azure portal. For Publish, select Docker Image, and then configure the container. Enter the location where the image is hosted.
- Create a Linux function app on an App Service plan by using the Azure CLI. To learn how, see Create a function on Linux by using a custom image.
To deploy to an existing app by using a custom container, in Azure Functions Core Tools, use the
func deploycommand.
When to use it: Use the Docker container option when you need more control over the Linux environment where your function app runs. This deployment mechanism is available only for Functions running on Linux.
Web Deploy packages and deploys your Windows applications to any IIS server, including your function apps running on Windows in Azure.
How to use it: Use Visual Studio tools for Azure Functions. Clear the Run from package file (recommended) check box.
You can also download Web Deploy 3.6 and call
MSDeploy.exedirectly.
When to use it: Web Deploy is supported and has no issues, but the preferred mechanism is zip deploy with Run From Package enabled. To learn more, see the Visual Studio development guide.
Use source control to connect your function app to a Git repository. An update to code in that repository triggers deployment. For more information, see the Kudu Wiki.
How to use it: Use Deployment Center in the Functions area of the portal to set up publishing from source control. For more information, see Continuous deployment for Azure Functions.
When to use it: Using source control is the best practice for teams that collaborate on their function apps. Source control is a good deployment option that enables more sophisticated deployment pipelines.
You can use local Git to push code from your local machine to Azure Functions by using Git.
How to use it: Follow the instructions in Local Git deployment to Azure App Service.
When to use it: In general, we recommend that you use a different deployment method. When you publish from local Git, you must manually sync triggers.
Use cloud sync to sync your content from Dropbox and OneDrive to Azure Functions.
How to use it: Follow the instructions in Sync content from a cloud folder.
When to use it: In general, we recommend other deployment methods. When you publish by using cloud sync, you must manually sync triggers.
You can use FTP to directly transfer files to Azure Functions.
How to use it: Follow the instructions in Deploy content by using FTP/s.
When to use it: In general, we recommend other deployment methods. When you publish by using FTP, you must manually sync triggers.
In the portal-based editor, you can directly edit the files that are in your function app (essentially deploying every time you save your changes).
How to use it: To be able to edit your functions in the Azure portal, you must have created your functions in the portal. To preserve a single source of truth, using any other deployment method makes your function read-only and prevents continued portal editing. To return to a state in which you can edit your files in the Azure portal, you can manually turn the edit mode back to
Read/Writeand remove any deployment-related application settings (likeWEBSITE_RUN_FROM_PACKAGE.
When to use it: The portal is a good way to get started with Azure Functions. For more intense development work, we recommend that you use one of the following client tools:
The following table shows the operating systems and languages that support portal editing:
| Language | Windows Consumption | Windows Premium | Windows Dedicated | Linux Consumption | Linux Premium | Linux Dedicated |
|---|---|---|---|---|---|---|
| C# | ||||||
| C# Script | ✔ | ✔ | ✔ | ✔* | ✔* | |
| F# | ||||||
| Java | ||||||
| JavaScript (Node.js) | ✔ | ✔ | ✔ | ✔* | ✔* | |
| Python (Preview) | ||||||
| PowerShell (Preview) | ✔ | ✔ | ✔ | |||
| TypeScript (Node.js) |
* Portal editing is enabled only for HTTP and Timer triggers for Functions on Linux using Premium and Dedicated plans.
When you do a deployment, all existing executions are allowed to complete or time out, after which the new code is loaded to begin processing requests.
If you need more control over this transition, you should use deployment slots.
When you deploy your function app to Azure, you can deploy to a separate deployment slot instead of directly to production. For more information on deployment slots, see the Azure Functions Deployment Slots documentation for details.
Read these articles to learn more about deploying your function apps: