# Durable Functions: three function types for stateful Azure Functions apps

> The Durable Task Framework extension adds orchestrator, activity and entity functions to Azure Functions, and the replay-based orchestration model is what makes long-running workflows survive restarts. It ships as three NuGet packages, one per hosting model, and the default branch is dev rather than main.

**Azure/azure-functions-durable-extension** — Durable Task Framework extension for Azure Functions

- Repository: https://github.com/Azure/azure-functions-durable-extension
- Stars: 767 · Forks: 295
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/azure-azure-functions-durable-extension

## Three function types, and the one that does the coordinating

Durable Functions is an extension that helps developers build reliable, stateful apps on the Azure Functions platform, and it adds three new function types to the Azure Functions family.

Orchestrator functions are the long-running, reliable workflow functions written in code that schedule and coordinate other functions. Activity functions are stateless and are the basic unit of work in a durable function orchestration. Entity functions are the stateful, actor-like functions that have identities and store their state explicitly.

That split is the design, and it is worth being precise about it because it determines how you write the code. An orchestrator does not do the work, it sequences the work, and it must be deterministic so that its history can be replayed. An activity does the work and is where you put anything with side effects. An entity holds state and can be called concurrently without the orchestrator having to sequence every interaction.

The entity type is the one that has no direct equivalent in the ordinary Azure Functions model. Because an entity has an identity and explicit state, a workflow can hold long-lived state, a counter, a session, or an aggregate that several different callers touch, and the extension keeps that state consistent for you rather than making you rebuild it from a history.

The primary language of this repository is C#, the default branch is dev, and the licence is MIT.

## Replaying history is what makes the workflow durable

The project is developed in collaboration with Microsoft Research, and two of its published papers describe the execution model rather than the API surface. The first is Durable Functions: Semantics for Stateful Serverless, presented at OOPSLA in 2021, and the second is Netherite: Efficient Execution of Serverless Workflows, presented at VLDB in 2022. Both are linked from the README as PDFs.

The mechanism those papers describe is the reason an orchestrator can be a long-running function and still be safe. A durable orchestration is not a function call that stays alive in memory. Its state lives in storage as a history of what happened, and when the orchestrator is scheduled again, the extension replays that history so the function reaches the same point it reached last time, then continues from there. The code must therefore be deterministic, and the point of the design is that a process restart or a redeploy does not lose the workflow.

That is also where the cost of the model lives. Every orchestration turn writes to storage, and the replay has to redo the work of the history to rebuild the in-memory state. The activity functions are stateless precisely so that they can be called again during replay without repeating their side effects, since the extension knows which activity results were already recorded.

Netherite is the research on making that execution efficient, which tells you the team treats the overhead as something to be optimised rather than accepted as a permanent cost.

## Three packages for two hosting models

Durable Functions updates are published as NuGet packages, and the README lists three of them. Microsoft.Azure.WebJobs.Extensions.DurableTask is the package for the in-process model, Microsoft.Azure.WebJobs.Extensions.DurableTask.Analyzers is described as C# only, and Microsoft.Azure.Functions.Worker.Extensions.DurableTask is the package for the isolated worker model.

The reason there are several is that Azure Functions itself has two hosting models, and the extension has to plug into both. The in-process model runs your function code inside the Functions host process, the worker model runs it in a separate dotnet worker process. The release record makes the split visible, with the WebJobs package at version 3.15.2 and the worker package at 1.19.2, both published on 2026-09-29, followed by the WebJobs package at 3.15.1 two days earlier. The two lines have different major versions, which is a hint that they do not move in lockstep.

The analyzers package exists because some mistakes are only detectable at compile time, and in a deterministic orchestrator a mistake such as calling a non-deterministic API inside orchestration code is exactly the kind of thing you want caught before deploy. That the package exists at all is a signal that the compiler-time rules around the model are real.

The repository tree is a large one for an extension, with a samples directory, a test directory, a docfx directory, a docs directory, an eng directory, a tools directory and an Azure Pipelines setup that includes separate release, nightly and dotnet-isolated release pipelines, plus a global.json, a Directory.Packages.props and a sign.snk for strong naming.

## Installing the extension and where the samples live

The NuGet package can be referenced directly in a Visual Studio project, or installed with the Azure Functions Core Tools command line:

```bash
func extensions install -p Microsoft.Azure.WebJobs.Extensions.DurableTask -v <latest version on Nuget.org>
```

Note the version placeholder. The README asks you to supply the latest version from NuGet.org rather than pinning a number, which tells you the project expects you to track releases yourself rather than offering a single version to copy.

There is a second route. Durable Functions is available in supported extension bundles, with the caveat that extension bundles are only supported for non-.NET languages. That distinction matters for the C# case, where you reference the package directly in the project file, and for the other languages, where a bundle is more convenient.

Language support is broad. The README lists C#, JavaScript, Python, PowerShell and Java as generally available, each with its own SDK and its own repository, and each of those language repositories has samples usually under a samples directory, with the JavaScript ones linked explicitly. The rule that applies to all of them is that the extension in this repository must be installed to enable the Durable Functions triggers, even when your function code is written in another language.

The samples in this repository cover a wide spread of shapes, including distributed tracing, managed identity for the durable client, entities in C#, F#, precompiled functions, unit tests for isolated functions, a todo list on ASP.NET Core, work item filters, and a samples solution with its own Directory.Packages.props.

## Where Durable Functions is the wrong tool

The first wrong case is short work. An ordinary Azure Function is cheaper and simpler for anything that finishes inside a single invocation, because a durable orchestration pays for storage writes on every turn and for the replay that reconstructs state. If you are wrapping a call to a third party API and returning the result, Durable Functions is overhead you have to justify.

The second is a workload that does not fit the model. The orchestrator has to be deterministic, which rules out calling a random number generator, reading the clock, or making a network request from orchestration code. That restriction is real and it is enforced by convention and by the analyzer package. Teams who write orchestration code the way they write regular function code will hit it, and the fix is to push the impure work into an activity function, which is a structural change rather than a small edit.

The third is the platform dependency. The extension runs anywhere Azure Functions runs, including the Consumption plan, Elastic Premium, Kubernetes with KEDA, and locally in Visual Studio or Visual Studio Code, but that reach is also the constraint. There is no way to take an orchestration out of the Azure Functions hosting model and run it elsewhere, and the extension bundles route is not available for .NET languages, so a .NET project always manages the package reference itself.

A related limit is the entity model. Entities are actor-like and hold state explicitly, which is a different concurrency contract from a request and response handler. If your team has not met that model before, the entity type is the part of the extension with the steepest learning curve, and the samples under samples/entitites-csharp are the fastest way to see the intended shape.

## Release cadence, packaging and where the source of truth lives

The project moves quickly and publishes on several tracks. The recent tags include 3.15.2 for the WebJobs package on 2026-09-29, 1.19.2 for the worker extension the same day, and 3.15.1 for the WebJobs package on 2026-09-28, with the last push on 2026-10-20. The default branch is dev, and the CI status badge in the README points at the Durable Task Framework build definition on the dev branch, so continuous integration runs against the working branch rather than a release branch.

The pipeline files show how the release variants are separated. There is a general azure-pipelines.yml, a release pipeline, a nightly release pipeline, and a separate release pipeline specifically for the dotnet-isolated worker path, which confirms that the two hosting models are released independently rather than from one cut. There is also an analyzer release pipeline, matching the separate analyzers package.

Documentation lives in the repository as well as on the docs site, with a docfx directory, a docs directory, a pending_docs.md file and a release_notes.md file at the top level, and the official documentation is hosted separately at the Microsoft docs site for Durable Functions.

On licensing, the project is under the MIT licence, and the README points to the azure-webjobs-sdk licence text for it. The project has also adopted the Microsoft Open Source Code of Conduct. For a dependency of this size, the practical thing to track is the release notes file, because the version you pin and the version already deployed in your function app are usually different numbers, and the behaviour changes between the WebJobs 3.x line and the worker 1.x line are not interchangeable.

## Conclusion

Adopt Durable Functions when your Azure Functions work needs to survive a restart, span minutes or hours, or coordinate other functions, since the orchestration history is replayed from storage and the activity and entity types cover the stateful cases that plain functions cannot. Stay away for short stateless handlers, where the storage round trip and the replay model cost more than they save. Before you deploy, check which of the three NuGet packages matches your hosting model, because the in-process and isolated worker packages are released on separate schedules, with 3.15.2 and 1.19.2 published on 2026-09-29, and review the release notes in the repository for the version you pin.

## FAQ

### What is the Durable Functions extension and which function types does it add?

It is an extension for building reliable, stateful apps on the Azure Functions platform, adding orchestrator functions that schedule and coordinate other functions, stateless activity functions as the unit of work, and stateful actor-like entity functions that have identities and store state explicitly.

### How do I install Durable Functions in an Azure Functions project?

Reference the NuGet package directly in a Visual Studio project, or run func extensions install -p Microsoft.Azure.WebJobs.Extensions.DurableTask -v <latest version on Nuget.org> with the Azure Functions Core Tools. It is also available in extension bundles, but bundles are only supported for non-.NET languages.

### Which languages does Durable Functions support?

C#, JavaScript, Python, PowerShell and Java are all listed as generally available, each with its own language-specific SDK and repository and its own samples. Whichever language you use, the extension in this repository must be installed to enable the Durable Functions triggers.

### What are the limits of the Durable Functions model?

Orchestrator functions must be deterministic, so impure work has to move into activity functions, and the model pays a storage cost on every orchestration turn. A short stateless handler is cheaper as a plain Azure Function, and the extension only runs inside the Azure Functions hosting model.

## Sources

- [Azure/azure-functions-durable-extension on GitHub](https://github.com/Azure/azure-functions-durable-extension)
- [Issues](https://github.com/Azure/azure-functions-durable-extension/issues)
- [License: MIT](https://github.com/Azure/azure-functions-durable-extension/blob/dev/LICENSE)
- [README](https://github.com/Azure/azure-functions-durable-extension/blob/dev/README.md)
- [Releases](https://github.com/Azure/azure-functions-durable-extension/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-azure-functions-durable-extension