Differences between in-process and isolated worker process .NET Azure Functions

There are two process models for .NET functions:

Execution mode Description
In-process Your function code runs in the same process as the Functions host process. Supports only Long Term Support (LTS) versions of .NET. To learn more, see Develop .NET class library functions.
Isolated worker process 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.

This article describes the current state of the functional and behavioral differences between the two models. To migrate from the in-process model to the isolated worker model, see Migrate .NET apps from the in-process model to the isolated worker model.

Execution mode comparison table

Use the following table to compare feature and functional differences between the two models:

Feature/behavior In-process3 Isolated worker process
Supported .NET versions Long Term Support (LTS) versions6 Long Term Support (LTS) versions6,
Standard Term Support (STS) versions,
.NET Framework
Core packages Microsoft.NET.Sdk.Functions Microsoft.Azure.Functions.Worker
Binding extension packages Microsoft.Azure.WebJobs.Extensions.* Microsoft.Azure.Functions.Worker.Extensions.*
Durable Functions Supported Supported (Support does not yet include Durable Entities)
Model types exposed by bindings Simple types
JSON serializable types
Service SDK types4
Simple types
JSON serializable types
Service SDK types4
HTTP trigger model types HttpRequest / IActionResult5
HttpRequestMessage / HttpResponseMessage
HttpRequestData / HttpResponseData
HttpRequest / IActionResult (using ASP.NET Core integration)5
Output binding interactions Return values (single output only),
out parameters,
Return values in an expanded model with:
- single or multiple outputs
- arrays of outputs
Imperative bindings1 Supported Not supported - instead work with SDK types directly
Dependency injection Supported Supported (improved model consistent with .NET ecosystem)
Middleware Not supported Supported
Logging ILogger passed to the function
ILogger<T> via dependency injection
ILogger<T>/ILogger obtained from FunctionContext or via dependency injection
Application Insights dependencies Supported Supported
Cancellation tokens Supported Supported
Cold start times2 Optimized Configurable optimizations (preview)
ReadyToRun Supported Supported

1 When you need to interact with a service using parameters determined at runtime, using the corresponding service SDKs directly is recommended over using imperative bindings. The SDKs are less verbose, cover more scenarios, and have advantages for error handling and debugging purposes. This recommendation applies to both models.

2 Cold start times may be additionally impacted on Windows when using some preview versions of .NET due to just-in-time loading of preview frameworks. This impact applies to both the in-process and out-of-process models but may be noticeable when comparing across different versions. This delay for preview versions isn't present on Linux plans.

3 C# Script functions also run in-process and use the same libraries as in-process class library functions. For more information, see the Azure Functions C# script (.csx) developer reference.

4 Service SDK types include types from the Azure SDK for .NET such as BlobClient. For the isolated process model, Service Bus triggers do not yet support message settlement scenarios.

5 ASP.NET Core types are not supported for .NET Framework.

6 The isolated worker model supports .NET 8 as a preview, currently for Linux applications only. .NET 8 is not yet available for the in-process model. See the Azure Functions Roadmap Update post for more information about .NET 8 plans.

Supported versions

Versions of the Functions runtime support specific versions of .NET. To learn more about Functions versions, see Azure Functions runtime versions overview. Version support also depends on whether your functions run in-process or isolated worker process.


To learn how to change the Functions runtime version used by your function app, see view and update the current runtime version.

The following table shows the highest level of .NET or .NET Framework that can be used with a specific version of Functions.

Functions runtime version In-process
(.NET class library)
Isolated worker process
(.NET Isolated)
Functions 4.x .NET 6.01 .NET 6.01
.NET 7.02
.NET Framework 4.83
.NET 8.0 (Preview)4
Functions 1.x5 .NET Framework 4.8 n/a

1 Per the .NET Official Support Policy, .NET 6 will reach end of support on November 12, 2024.

2 Per the .NET Official Support Policy, .NET 7 will reach end of support on May 14, 2024.

3 Build process also requires .NET 6 SDK.

4 Preview support for .NET 8 function apps is currently limited to Linux applications. To develop using .NET 8 Preview SDKs in Visual Studio, you must use Visual Studio 2022 Preview. Within Visual Studio, you must also get the latest toolset and template updates by navigating to Tools->Options, selecting Azure Functions under Projects and Solutions, and then clicking the Check for updates button and installing updates as prompted.

5Support 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.

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

Next steps