Deployment technologies in Azure Functions

  • Article

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.

Deployment methods

The deployment technology you use to publish code to your function app in Azure depends on your 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're more likely to publish continuously from source control or by using an automated publishing pipeline, which can include validation and testing.

The following table describes the available deployment methods for your code project.

Deployment type Methods Best for...
Tools-based • Visual Studio Code publish
• Visual Studio publish
• Core Tools publish		 Deployments during development and other improvised deployments. Deploying your code on-demand using local development tools.
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 • GitHub Actions Production pipelines that include validation, testing, and other actions that must be run as part of an automated deployment. Deployments are managed by the pipeline.

Specific deployments should use the best technology based on the specific scenario. Many of the deployment methods are based on zip deployment, which is recommended for deployment.

Deployment technology availability

The deployment method also depends on the hosting plan and operating system on which you run your function app.
Currently, Functions offers three hosting plans:

Each plan has different behaviors. Not all deployment technologies are available for each hosting plan and operating system. This chart provides information on the supported deployment technologies:

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 ✔ ✔ ✔ ✔ ✔
FTPS1 ✔ ✔ ✔ ✔ ✔
In-portal editing2 ✔ ✔ ✔ ✔ ✔3 ✔3

1 Deployment technologies that require you to manually sync triggers aren't recommended.
2 In-portal editing is disabled when code is deployed to your function app from outside the portal. For more information, including language support details for in-portal editing, see Language support details.
3 In-portal editing is enabled only for HTTP and Timer triggered functions running on Linux in Premium and Dedicated plans.

Key concepts

Some key concepts are critical to understanding how deployments work in Azure Functions.

Trigger syncing

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}.chinacloudsites.cn/admin/host/synctriggers?code=<API_KEY> using the master key.
  • Send an HTTP POST request to https://management.chinacloudapi.cn/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. This request requires an access token in the Authorization request header.

When you deploy using an external package URL, you need to manually restart your function app to fully sync your updates when the package changes without changing the URL.

Remote build

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.

All function apps running on Windows have a small management app, the SCM site provided by Kudu. 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.

The following considerations apply when using remote builds during deployment:

  • Remote builds are supported for function apps running on Linux in the Consumption plan, however they don't have an SCM/Kudu site, which limits deployment options.
  • Function apps running on Linux a Premium plan or in a Dedicated (App Service) plan do have an SCM/Kudu site, but it's limited compared to Windows.
  • Remote builds aren't performed when an app has previously been set to run in run-from-package mode. To learn how to use remote build in these cases, see Zip deploy.
  • You may have issues with remote build when your app was created before the feature was made available (August 1, 2019). For older apps, either create a new function app or run az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> to update your function app. This command might take two tries to succeed.

App content storage

Several deployment methods store the deployed or built application payload on the storage account associated with the function app. Functions tries to use the Azure Files content share when configured, but some methods instead store the payload in the blob storage instance associated with the AzureWebJobsStorage connection. See the details in the Where app content is stored paragraphs of each deployment technology covered in the next section.

Important

The storage account is used to store important app data, sometimes including the application code itself. You should limit access from other apps and users to the storage account.

Deployment technology details

The following deployment methods are available in Azure Functions.

External package URL

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_PACKAGE to 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. When you change the contents of the package file and not the URL itself, you must also restart your function app manually.

Where app content is stored: App content is stored at the URL specified. This could be on Azure Blobs, possibly in the storage account specified by the AzureWebJobsStorage connection. Some client tools may default to deploying to a blob in this account. For example, for Linux Consumption apps, the Azure CLI will attempt to deploy through a package stored in a blob on the account specified by AzureWebJobsStorage.

Zip deploy

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_PACKAGE application setting value to 1. 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.

Where app content is stored: App content from a zip deploy by default is stored on the file system, which may be backed by Azure Files from the storage account specified when the function app was created. In Linux Consumption, the app content instead is persisted on a blob in the storage account specified by the AzureWebJobsStorage connection.

Docker container

You can deploy a function app running in a Linux container.

How to use it: Create your functions in a Linux container then deploy the container to a Premium or Dedicated plan in Azure Functions or another container host. Use the Azure Functions Core Tools to create a customized Dockerfile for your project that you use to build a containerized function app. You can use the container in the following deployments:

When to use it: Use the Docker container option when you need more control over the Linux environment where your function app runs and where the container is hosted. This deployment mechanism is available only for functions running on Linux.

Where app content is stored: App content is stored in the specified container registry as a part of the image.

Web Deploy (MSDeploy)

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.exe directly.

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.

Where app content is stored: App content is stored on the file system, which may be backed by Azure Files from the storage account specified when the function app was created.

Source control

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.

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.

Where app content is stored: The app content is in the source control system, but a locally cloned and built app content from is stored on the app file system, which may be backed by Azure Files from the storage account specified when the function app was created.

Local Git

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: To reduce the chance of errors, you should avoid using deployment methods that require the additional step of manually syncing triggers. Use zip deployment when possible.

Where app content is stored: App content is stored on the file system, which may be backed by Azure Files from the storage account specified when the function app was created.

FTP/S

You can use FTP/S to directly transfer files to Azure Functions, although this deployment method isn't recommended. When you're not planning on using FTP, you should disable it. If you do choose to use FTP, you should enforce FTPS. To learn how in the Azure portal, see Enforce FTPS.

How to use it: Follow the instructions in FTPS deployment settings to get the URL and credentials you can use to deploy to your function app using FTPS.

When to use it: To reduce the chance of errors, you should avoid using deployment methods that require the additional step of manually syncing triggers. Use zip deployment when possible.

Where app content is stored: App content is stored on the file system, which may be backed by Azure Files from the storage account specified when the function app was created.

Portal editing

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/Write and remove any deployment-related application settings (like WEBSITE_RUN_FROM_PACKAGE).

When to use it: The portal is a good way to get started with Azure Functions. For more advanced development work, we recommend that you use one of the following client tools:

Where app content is stored: App content is stored on the file system, which may be backed by Azure Files from the storage account specified when the function app was created.

The following table shows the operating systems and languages that support in-portal editing:

Language Windows Consumption Windows Premium Windows Dedicated Linux Consumption Linux Premium Linux Dedicated
C#
C# Script ✔ ✔ ✔ ✔* ✔*
F#
Java
JavaScript (Node.js) ✔ ✔ ✔ ✔1 ✔1
Python2 ✔ ✔1 ✔1
PowerShell ✔ ✔ ✔
TypeScript (Node.js)

1 In-portal editing is enabled only for HTTP and Timer triggers for Functions on Linux using Premium and Dedicated plans.
2 In-portal editing is only supported for the v1 Python programming model.

Deployment behaviors

When you deploy updates to your function app code, currently executing functions are terminated. After deployment completes, the new code is loaded to begin processing requests. Review Improve the performance and reliability of Azure Functions to learn how to write stateless and defensive functions.

If you need more control over this transition, you should use deployment slots.

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.

Next steps

Read these articles to learn more about deploying your function apps: