Edit

Share via

Azure Functions runtime versions overview

  • Article

Azure Functions currently supports two versions of the runtime host. The following table details the currently supported runtime versions, their support level, and when they should be used:

Version Support level Description
4.x GA Recommended runtime version for functions in all languages. Check out Supported language versions.
1.x GA (support ends September 14, 2026) Supported only for C# apps that must use .NET Framework. This version is in maintenance mode, with enhancements provided only in later versions. Support will end for version 1.x on September 14, 2026. We highly recommend you migrate your apps to version 4.x, which supports .NET Framework 4.8, .NET 6, .NET 8, and .NET 9.

Important

As of December 13, 2022, function apps running on versions 2.x and 3.x of the Azure Functions runtime have reached the end of extended support. For more information, see Retired versions.

This article details some of the differences between supported versions, how you can create each version, and how to change the version on which your functions run.

Levels of support

There are two levels of support:

  • Generally available (GA) - Fully supported and approved for production use.
  • Preview - Not yet supported, but expected to reach GA status in the future.

Languages

All functions in a function app must share the same language. You choose the language of functions in your function app when you create the app. The language of your function app is maintained in the FUNCTIONS_WORKER_RUNTIME setting, and can't be changed when there are existing functions.

The following table shows the .NET versions supported by Azure Functions. Select your preferred development language at the top of the article.

The supported version of .NET depends on both your Functions runtime version and your chosen execution model:

Your function code runs in a separate .NET worker process. Use with supported versions of .NET and .NET Framework. To learn more, see Develop .NET isolated worker process functions.

Supported version Support level Expected community EOL date
.NET 9 Preview See policy
.NET 8 GA November 10, 2026
.NET 6 GA November 12, 2024
.NET Framework 4.8.1 GA See policy

.NET 7 was previously supported on the isolated worker model but reached the end of official support on May 14, 2024.

For more information, see Guide for running C# Azure Functions in an isolated worker process.

The following table shows the language versions supported for Java functions. Select your preferred development language at the top of the article.

Supported version Support level Expected community EOL date
Java 21 (Linux-only) Preview September 2028
Java 17 GA September 2027
Java 11 GA September 2027
Java 8 GA November 30, 2026

For more information, see Azure Functions Java developer guide.

The following table shows the language versions supported for Node.js functions. Select your preferred development language at the top of the article.

Supported version Support level Expected community EOL date
Node.js 22 Preview April 30, 2027
Node.js 20 GA April 30, 2026
Node.js 18 GA April 30, 2025

TypeScript is supported through transpiling to JavaScript. For more information, see the Azure Functions Node.js developer guide.

The following table shows the language version supported for PowerShell functions. Select your preferred development language at the top of the article.

Supported version Support level Expected community EOL date
PowerShell 7.4 GA November 10, 2026
PowerShell 7.2 GA November 8, 2024

For more information, see Azure Functions PowerShell developer guide.

The following table shows the language versions supported for Python functions. Select your preferred development language at the top of the article.

Supported version Support level Expected community EOL date
Python 3.11 GA October 2027
Python 3.10 GA October 2026
Python 3.9 GA October 2025
Python 3.8 GA October 2024

For more information, see Azure Functions Python developer guide.

For information about planned changes to language support, see Azure roadmap.

For information about the language versions of previously supported versions of the Functions runtime, see Retired runtime versions.

Run on a specific version

The version of the Functions runtime used by published apps in Azure is dictated by the FUNCTIONS_EXTENSION_VERSION application setting. In some cases and for certain languages, other settings can apply.

By default, function apps created in the Azure portal, by the Azure CLI, or from Visual Studio tools are set to version 4.x. You can modify this version if needed. You can only downgrade the runtime version to 1.x after you create your function app but before you add any functions. Updating to a later major version is allowed even with apps that have existing functions.

Migrating existing function apps

When your app has existing functions, you must take precautions before moving to a later major runtime version. The following articles detail breaking changes between major versions, including language-specific breaking changes. They also provide you with step-by-step instructions for a successful migration of your existing function app.

Changing version of apps in Azure

The following major runtime version values are used:

Value Runtime target
~4 4.x
~1 1.x

Important

Don't arbitrarily change this app setting, because other app setting changes and changes to your function code might be required. For existing function apps, follow the migration instructions.

Pinning to a specific minor version

To resolve issues your function app could have when running on the latest major version, you have to temporarily pin your app to a specific minor version. Pinning gives you time to get your app running correctly on the latest major version. The way that you pin to a minor version differs between Windows and Linux. To learn more, see How to target Azure Functions runtime versions.

Older minor versions are periodically removed from Functions. For the latest news about Azure Functions releases, including the removal of specific older minor versions, monitor Azure App Service announcements.

Minimum extension versions

There's technically not a correlation between binding extension versions and the Functions runtime version. However, starting with version 4.x the Functions runtime enforces a minimum version for all trigger and binding extensions.

If you receive a warning about a package not meeting a minimum required version, you should update that NuGet package to the minimum version as you normally would. The minimum version requirements for extensions used in Functions v4.x can be found in the linked configuration file.

For C# script, update the extension bundle reference in the host.json as follows:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

There's technically not a correlation between extension bundle versions and the Functions runtime version. However, starting with version 4.x the Functions runtime enforces a minimum version for extension bundles.

If you receive a warning about your extension bundle version not meeting a minimum required version, update your existing extension bundle reference in the host.json as follows:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

To learn more about extension bundles, see Extension bundles.

Retired versions

Important

Support will end for version 1.x of the Azure Functions runtime on September 14, 2026. We highly recommend that you migrate your apps to version 4.x for full support.

These versions of the Functions runtime reached the end of extended support on December 13, 2022.

Version Current support level Previous support level
3.x Out-of-support GA
2.x Out-of-support GA

As soon as possible, you should migrate your apps to version 4.x to obtain full support. For a complete set of language-specific migration instructions, see Migrate apps to Azure Functions version 4.x.

Apps using versions 2.x and 3.x can still be created and deployed from your CI/CD DevOps pipeline, and all existing apps continue to run without breaking changes. However, your apps aren't eligible for new features, security patches, and performance optimizations. You can only get related service support after you upgrade your apps to version 4.x.

End of support for versions 2.x and 3.x is due to the end of support for .NET Core 3.1, which they had as a core dependency. This requirement affects all languages supported by Azure Functions.

Locally developed application versions

You can make the following updates to function apps to locally change the targeted versions.

Visual Studio runtime versions

In Visual Studio, you select the runtime version when you create a project. Azure Functions tools for Visual Studio supports the two major runtime versions. The correct version is used when debugging and publishing based on project settings. The version settings are defined in the .csproj file in the following properties:

<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

If you are using the isolated worker model, you can choose, net8.0, net6.0, or net48 as the target framework. You can also choose to use preview support for net9.0. If you are using the in-process model, you can choose net8.0 or net6.0, and you must include the Microsoft.NET.Sdk.Functions extension set to at least 4.4.0.

.NET 7 was previously supported on the isolated worker model but reached the end of official support on May 14, 2024.

Visual Studio Code and Azure Functions Core Tools

Azure Functions Core Tools is used for command-line development and also by the Azure Functions extension for Visual Studio Code. For more information, see Install the Azure Functions Core Tools.

For Visual Studio Code development, you could also need to update the user setting for the azureFunctions.projectRuntime to match the version of the tools installed. This setting also updates the templates and languages used during function app creation.

Bindings

Starting with version 2.x, the runtime uses a new binding extensibility model that offers these advantages:

  • Support for third-party binding extensions.

  • Decoupling of runtime and bindings. This change allows binding extensions to be versioned and released independently. You can, for example, opt to upgrade to a version of an extension that relies on a newer version of an underlying SDK.

  • A lighter execution environment, where only the bindings in use are known and loaded by the runtime.

Except for HTTP and timer triggers, all bindings must be explicitly added to the function app project, or registered in the portal. For more information, see Register binding extensions.

The following table shows which bindings are supported in each runtime version.

This table shows the bindings that are supported in the major versions of the Azure Functions runtime:

Type 1.x1 2.x and higher2 Trigger Input Output
Blob storage ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Azure Data Explorer ✔ ✔ ✔
Azure SQL ✔ ✔ ✔ ✔
Dapr4 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
HTTP & webhooks ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka3 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Notification Hubs ✔ ✔
Queue storage ✔ ✔ ✔ ✔
Redis ✔ ✔
RabbitMQ3 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Table storage ✔ ✔ ✔ ✔
Timer ✔ ✔ ✔
Twilio ✔ ✔ ✔

Notes:

  1. Support will end for version 1.x of the Azure Functions runtime on September 14, 2026. We highly recommend that you migrate your apps to version 4.x for full support.
  2. Starting with the version 2.x runtime, all bindings except HTTP and Timer must be registered. See Register binding extensions.
  3. Triggers aren't supported in the Consumption plan. Requires runtime-driven triggers.
  4. Supported in Kubernetes, IoT Edge, and other self-hosted modes only.

Function app timeout duration

The timeout duration for functions in a function app is defined by the functionTimeout property in the host.json project file. This property applies specifically to function executions. After the trigger starts function execution, the function needs to return/respond within the timeout duration. To avoid timeouts, it's important to write robust functions. For more information, see Improve Azure Functions performance and reliability.

The following table shows the default and maximum values (in minutes) for specific plans:

Plan Default Maximum1
Flex Consumption plan 30 Unbounded2
Premium plan 304 Unbounded2
Dedicated plan 304 Unbounded3
Container Apps 30 Unbounded5
Consumption plan 5 10
  1. Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. This is because of the default idle timeout of Azure Load Balancer. For longer processing times, consider using the Durable Functions async pattern or defer the actual work and return an immediate response.
  2. There is no maximum execution timeout duration enforced. However, the grace period given to a function execution is 60 minutes during scale in for the Flex Consumption and Premium plans, and a grace period of 10 minutes is given during platform updates.
  3. Requires the App Service plan be set to Always On. A grace period of 10 minutes is given during platform updates.
  4. The default timeout for version 1.x of the Functions host runtime is unbounded.
  5. When the minimum number of replicas is set to zero, the default timeout depends on the specific triggers used in the app.

Next steps

For more information, see the following resources: