# azure-functions-host: the C# runtime that receives triggers and dispatches function invocations

> Azure/azure-functions-host is the MIT-licensed server runtime that Microsoft deploys as the Azure Functions service, wrapping the Azure WebJobs SDK to handle trigger routing, worker language dispatch and output bindings. Developers encounter it through Azure or local tooling, not by installing this repository directly.

**Azure/azure-functions-host** — The host/runtime that powers Azure Functions

- Repository: https://github.com/Azure/azure-functions-host
- Website: https://functions.azure.com
- Stars: 2,022 · Forks: 486
- Language: C#
- License: MIT
- Published: 2026-10-09 · Updated: 2026-10-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/azure-azure-functions-host

## Trigger routing and worker dispatch: what the host adds above the WebJobs SDK

Azure Functions as a service executes event-driven code on demand. When a trigger fires (an HTTP request arrives, a queue message lands, a timer ticks), something must receive that event, route it to the correct function, provide it with input data, run the function, and handle the output. That something is this host.

Building on the Azure WebJobs SDK gives the host a foundation for continuous background processing, job scheduling and binding extensions. What the SDK alone does not provide is a per-function configuration model, a worker language abstraction layer, and the routing layer that maps external trigger events to specific function definitions. Those additions live in this host repository.

Where something goes wrong in a Functions deployment depends on which layer is affected. A misconfigured trigger is a host concern. A Python syntax error is a worker language concern, not a host concern. A crash in the invocation dispatch layer, before the worker process receives execution, points back to this repository. Knowing this layering keeps bug reports from ending up in the wrong place.

## Four branches reflect two coexisting execution models

Four active branches appear in the README's build status table: dev, in-proc, release/4.x, and release/in-proc. Their names reveal a split in the project's architecture.

In the isolated worker model (dev and release/4.x branches), function code runs in a separate process and communicates with the host over gRPC. In the in-process model (in-proc and release/in-proc branches), C# function code runs inside the same .NET process as the host itself. Both sets of branches receive ongoing builds, which means Microsoft maintains both models simultaneously rather than deprecating one.

For users of the service, this split has practical consequences. In-process functions share the .NET version of the host, which Microsoft controls. Isolated worker functions use whatever .NET version the function author targets. That difference in control is the core trade-off between the two models. Neither model is documented further in the README, and the decision between them affects which branch is relevant for a given issue or contribution.

## Language support visible from the sample folder structure

At the repository root, the sample/ folder contains subfolders for CSharp, Java, Node, PowerShell and Python, plus HttpWorker. Each subfolder holds example function implementations for that language or runtime. Placing these samples in the host repository, rather than in separate worker language repositories, reflects the host's role as the system that must work correctly with all of them.

CSharpBenchmark is separate from CSharp, which suggests performance measurement has its own harness distinct from correctness samples. PythonWorkerIndexing is separate from Python, pointing to a specific mechanism where the Python worker process enumerates and registers function definitions before execution begins.

CustomHandler and HttpWorker cover functions written in languages the host does not natively support. Any process that can serve HTTP can act as a custom handler: it receives function invocations from the host over a lightweight HTTP protocol, processes them, and returns responses. This protocol is what allows Go, Ruby or any other language to run on Azure Functions without a first-class worker SDK. CustomHandlerRetry covers the specific case of retry behavior for custom handler functions.

## NodeDrain, NodeResume and NodeRetry: what lifecycle samples reveal

Among the Node-related sample subfolders are NodeDrain, NodeResume and NodeRetry, each separate from the plain Node samples. These names point to lifecycle behaviors the host coordinates with its worker processes.

Draining stops new invocations from being sent to a worker while executions already in progress are allowed to finish. A host that drains workers before terminating avoids cutting off running functions during a scale-down or deployment event. Resume is the complementary operation: once the drain period ends, the host re-enables the worker to accept new invocations. Having NodeDrain and NodeResume as separate sample categories implies these are modeled as distinct operational states in the host, not just informal shutdown behaviors.

NodeRetry covers a distinct case: when a Node worker reports an invocation failure, the host can reattempt it rather than relying entirely on the trigger source to requeue the message. The distinction matters because some trigger sources (an HTTP endpoint, for example) cannot replay an event once it has been delivered; host-level retry is what gives a second attempt in those cases. None of this is described in the README, and the configuration model, available keys and failure modes for retry belong in the Azure Functions documentation rather than in this repository.

## No installation path from this repository; developers reach the host through Azure

Developers writing Azure Functions do not compile or install this repository. Microsoft deploys the host as part of the Azure Functions service, managing its versions independently of individual function deployments. Local function development uses the Azure Functions Core Tools, a separate project. Running func start locally invokes those tools, not a build of this repository.

No build or setup instructions appear in the README. Questions about using Azure Functions go to the azure-webjobs-sdk-script wiki, which the README identifies as the support path rather than the GitHub issue tracker. That wiki URL carries the project's old name, since azure-webjobs-sdk-script was the earlier name for the Functions scripting engine, so searches for current documentation should account for both names.

Contributing to the host itself means working with a C# solution. At the repository root are Azure.Functions.Host.slnx and WebJobs.Script.sln. A structured build pipeline is suggested by the eng/ folder and Directory.Build.props, and the .github/ folder combined with CONTRIBUTING.md and CODEOWNERS indicates a standard pull request workflow. SECURITY.md documents the security disclosure process for vulnerability reports.

## Where the WebJobs SDK ends and the host begins

Azure WebJobs SDK is named in the README as the layer the Azure Functions runtime builds upon. Continuous background processing, polling for work, running jobs on a schedule, and providing extension points for bindings and triggers are SDK capabilities that predate Azure Functions as a product.

When the Functions team added discrete function invocations, per-language workers and the function.json configuration model, those additions landed in the host rather than the SDK. Building on the SDK gives the host a runtime foundation with queue handling, blob watching, service bus integration and other binding primitives, without reimplementing those from scratch.

Bug reports need this distinction to find the right repository. A problem with the Azure Functions Blob trigger not firing correctly may be a WebJobs SDK issue rather than a host issue. When filing an issue in azure-functions-host, isolating whether the problem is in the SDK binding layer or the Functions dispatch layer narrows where the fix belongs. The repository's topics tag lists azure-webjobs-sdk alongside azure-functions, which reflects this overlap.

## MIT licence, .NET Foundation membership, and the v4.xxxx.yyy version scheme

MIT is the project licence, with the full text in LICENSE.txt. LICENSE_APACHE.txt is also present, likely covering separately licensed dependencies rather than the host code itself. Governance sits under the .NET Foundation, the organisational and legal infrastructure for open-source .NET projects. Both the MIT licence and the Microsoft Open Source Code of Conduct apply, and the README points to the Code of Conduct FAQ for further detail.

Release versioning follows a pattern like v4.1055.100. Three recent releases are v4.1055.100 on 2026-09-29, v4.1054.200 on 2026-08-28, and v4.1054.100 on 2026-08-21. Major version 4 has stayed constant across these releases. What the second and third numbers represent is not documented in the README; release_notes.md in the repository root is the file to read for change-level detail.

Last push to the repository was on 2026-10-05, and the repository is not archived. Development happens on the dev branch, not the release branches. Any contribution or investigation that needs the latest code should target dev rather than release/4.x.

## Conclusion

Study azure-functions-host if you are diagnosing a host-level bug in Azure Functions behavior, contributing to the runtime, or building a custom language worker. Skip it if you are writing Azure Functions: that workflow uses the Azure service or the Functions Core Tools, not this repository. Before filing an issue here, confirm whether the problem is at the trigger layer, the worker language layer, or the host dispatch layer, since each has its own repository. Questions about usage belong in the azure-webjobs-sdk-script wiki, which the README names as the support path.

## FAQ

### What is azure-functions-host?

azure-functions-host is the open-source C# runtime that Microsoft deploys as the Azure Functions service. It builds on the Azure WebJobs SDK to dispatch function invocations to worker processes written in C#, Python, Node.js, Java, PowerShell, or any language via the custom handler protocol.

### Can I install azure-functions-host locally?

This repository is the server-side runtime deployed by Microsoft. No installation or build instructions appear in the README. Local Azure Functions development uses the Azure Functions Core Tools, which is a separate project.

### What is the difference between the in-proc and dev branches of azure-functions-host?

The in-proc and release/in-proc branches maintain the in-process execution model, where C# function code runs inside the host process. The dev and release/4.x branches represent the isolated worker model, where functions run in a separate process.

### What licence does azure-functions-host use?

The project uses the MIT licence, with the text in LICENSE.txt. It is also under the .NET Foundation and follows the Microsoft Open Source Code of Conduct.

### What languages does azure-functions-host support?

Based on the sample folder structure, the host has dedicated samples for C#, Java, Node.js, Python, and PowerShell. CustomHandler and HttpWorker sample folders indicate support for functions in any language that can serve HTTP, using the custom handler protocol.

## Sources

- [Azure/azure-functions-host on GitHub](https://github.com/Azure/azure-functions-host)
- [License: MIT](https://github.com/Azure/azure-functions-host/blob/dev/LICENSE)
- [Project website](https://functions.azure.com)
- [README](https://github.com/Azure/azure-functions-host/blob/dev/README.md)
- [Releases](https://github.com/Azure/azure-functions-host/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-host