Azure IoT Edge: edge-agent, edge-hub and the edgelet in one runtime

Three components carry the whole edge runtime

The README is short, and it is short because the interesting decisions live in the code rather than in the prose. It states the goal plainly: IoT Edge moves cloud analytics and custom business logic to devices, so an organisation can focus on business insights instead of data management, and a solution scales by configuring IoT software, deploying it to devices via standard containers, and monitoring it from the cloud.

What follows is the part that matters for an engineer. The repository consists of three main projects: the Edge Agent, the Edge Hub, and the IoT Edge Security Daemon, whose directory is `edgelet`. If you are trying to understand the architecture, that is the map.

The agent is the piece that owns the device's desired state and reconciles it with what is actually running, which is the shape of a container orchestrator applied to a single device rather than a cluster. The hub is the messaging component sitting between modules, so that a module can publish to a topic and another module or the cloud consumes it without either knowing the other's address. The edgelet is the trust boundary: it is the piece that decides what a module is allowed to do, and it is deliberately separated from the workload it supervises.

The overall picture is a small distributed system per device, with a strict separation between the thing that controls the device, the thing that moves data, and the thing that enforces security. That separation is the main architectural idea in the codebase.

The tree mixes C#, a Rust toolchain and packaging for several distributions

The primary language is C#, and the build is a Visual Studio solution, `Microsoft.Azure.Devices.Edge.sln`, with a matching `DotSettings` file and StyleCop configuration files for the code style rules. A `CodeCoverage.runsettings` file and separate `test/` and `smoke/` directories show the test layers are split by speed rather than being one suite.

Two entries stand out. `rust-toolchain.toml` sits at the root, so at least part of the tree is built with Rust and pinned to a specific toolchain, and the `mqtt/` directory indicates the MQTT implementation is part of this repository rather than an external dependency. The `edge-util/` directory is the shared utility layer that the agent, hub and modules all build on.

Packaging is visible too, and it is broader than a single platform. There is a `snap/` directory for snap packages, and the `builds/` directory alongside it, and the Makefile in the root handles the source distribution. The `e2e_deployment_files/` and `e2e_test_files/` directories are how the end-to-end suites get their configuration, and `samples/dotnet/` shows the published sample is.NET.

The `tools/`, `scripts/` and `doc/` directories round out a repository that is organised like a product release rather than a library. That is a fair signal of the scale of what is in here: this is an operating system component for devices, not a package you drop into an app.

Building a source tarball with make dist, versioned from edgelet/version.txt

There is no install command in the documentation, because installation of the runtime is a product operation rather than a package manager step. What the repository does give you is a reproducible source distribution, and the root `Makefile` is the entry point.

The version is not hardcoded in the Makefile. It is read from a file:

_version:=$(shell cat edgelet/version.txt)
VERSION?=${_version}
REVISION?=1

That detail is worth knowing, because the security daemon's version file is the single source of the release number, and the edgelet is the component whose version matters most when you check what is running on a device.

The `dist` target is the one you want. It creates a `target/` directory, uses `git archive` to produce a tarball with a prefix, walks the git submodules and concatenates each into the same archive, and then gzips the result:

make dist

The result is a tarball named after the package, `aziot-edge`, with the version derived from the version string, for example `aziot-edge-<version>.tar.gz` in the `target/` directory. The `clean` target removes that build directory, and the Makefile also declares a `version` target. The conversion of the debian-style version string into an rpm version happens in the Makefile itself, with the `~dev` suffix turned into an rpm release segment, which is how a single version string serves both distribution formats.

Releases are tagged as LTS, and the last push was on 2026-10-14

The release history shows a clear line. Version 1.6.4 was tagged as an LTS build on 2026-09-30, version 1.6.3 as LTS on 2026-09-09, and between them a component release, Metrics Collector 2.0.0, on 2026-09-15. The LTS marking on the version tags tells you which builds are the ones Microsoft treats as long-term support, which matters because an LTS tag and a plain tag carry different upgrade expectations.

The last push to the `main` branch was on 2026-10-14, and the repository is not archived. Combined with a release a fortnight earlier, that indicates a codebase still receiving work rather than a frozen sample.

A `CHANGELOG.md` at the root gives you the per-version history, and `versionInfo.json` holds the version metadata used across the build. Upgrade cost is therefore visible in the repository rather than hidden in release notes elsewhere, which is unusual and useful.

Licensing is straightforward here. The project is MIT licensed, with a `LICENSE` file at the root, plus `THIRDPARTYNOTICES` for the bundled third-party components and a `trademark.txt` that reserves the Microsoft name. The MIT terms grant broad reuse, but the trademark file is a separate reminder that shipping the code does not grant permission to call your product Azure IoT Edge. Whether the third-party notices obligations reach your distribution is a question for your own licensing review.

What the repository does not tell you: how to deploy any of it

The README points documentation at `https://docs.microsoft.com/azure/iot-edge` and says that the documentation for the Azure IoT Edge product is found there. The repository itself is where the code lives, not where the operational guide lives, and the split matters for anyone evaluating adoption.

What you can learn here is the shape of the system and how it is built: three components, the C# solution layout, the Rust toolchain, the MQTT implementation, the packaging targets, the release tags. What you cannot learn here is how to register a device, how the security daemon's trust model is configured in practice, what the module deployment manifests look like, or how the cloud monitoring surface is wired to the hub. Those are product documentation topics, and they are the ones you need before committing a team.

Contributors are pointed at `doc/devguide.md` for build and change instructions, and there is a `SECURITY.md` file for reporting security issues. The distinction between the product docs and the devguide is a good model for what to read: the product docs if you are adopting the runtime, the devguide only if you intend to modify it.

Where IoT Edge is the wrong tool

The binding constraint is not technical, it is architectural. The runtime is designed to be part of an Azure deployment: modules are deployed to devices, and the whole model assumes a cloud side that issues desired state and receives telemetry. The README's own summary of the workflow, configure, deploy to devices via standard containers, monitor from the cloud, describes a product with a control plane somewhere else.

If your requirement is a device agent that runs on a factory floor with intermittent connectivity and no dependency on a specific cloud provider, this is the wrong shape. A general-purpose container runtime on the device, with your own lightweight scheduling and telemetry pipeline, gives you the same module isolation without binding the deployment model to one cloud's control plane. The trade runs the other way too: building that yourself means reimplementing the reconciliation loop, the local message bus, and the device identity story, which is exactly the work this repository already does.

There is a second, narrower wrong-tool case. If all you need is a process that runs on a device and sends data upstream, a container and an MQTT client with a handful of lines of code will be less to operate than a runtime with an agent, a hub, a security daemon and a deployment control plane. The runtime earns its weight when several modules on a device need to talk to each other and need to be managed as a set.

Editorial conclusion

IoT Edge fits teams that already run workloads in Azure and need containers on device with cloud monitoring, and it does not fit teams that want an edge runtime independent of a cloud provider. Before adopting, read the product documentation at docs.microsoft.com/azure/iot-edge rather than the repository README, because the repository describes the components but leaves deployment to the product docs, and check the release line you would install, since 1.6.4 is tagged as an LTS build.

Frequently asked questions

Official sources

1. Azure/iotedge on GitHub
2. Issues
3. License: MIT
4. README
5. Releases