# Azure Linux 4: Microsoft's Fedora-Derived Distro, Reviewed for Adopters

> Azure Linux 4 is an RPM-based Linux distribution built for Azure VMs, containers and bare metal, with sources derived from Fedora. The 4.0 branch is still in development, so the practical question is what you can run today and what you should wait on.

**microsoft/azurelinux** — General purpose Linux OS for Azure

- Repository: https://github.com/microsoft/azurelinux
- Stars: 5,344 · Forks: 707
- Language: Python
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-azurelinux

## What Azure Linux 4 is for, and who should care

Azure Linux is a general purpose Linux OS for Azure, built and optimized for the platform with sources derived from Fedora Linux. The README frames the target as virtual machines, containers and bare-metal platforms, and lists hardened security posture, an Azure-optimized kernel, supply chain security, native Azure integration and a predictable lifecycle as the features it competes on. It is not pitched at desktop users or at people running a homelab on hardware they own.

The audience is narrower than the tagline suggests. If you build container images, the base image reference is the reason to look: the README gives mcr.microsoft.com/azurelinux-beta/base/core:4.0 as the current 4.0 base container. If you provision Azure VMs, the Marketplace page is the entry point. If you package RPMs, this repository is the distro definition itself, and the packaging workflow is the product you are adopting. Everyone else is a spectator for now.

## How the distro is defined: TOML configs, overlays and rendered specs

This is the part worth understanding before you trust a build. Azure Linux 4 is not a fork of Fedora's packaging tree. It is a layer applied to it. The repository describes the distro almost entirely in TOML configuration files, and the open-source tool azldev applies that configuration to upstream Fedora spec files and packaging sources. The README shows the entry point as azldev.toml, which includes distro/ for distro-wide configs and base/ for the base project.

Components are the unit of packaging. Most are imported in source form from Fedora's upstream dist-git repositories, and each component produces one or more RPMs. Where Azure Linux needs to differ, it does so through overlays: declarative modifications to upstream specs and sources, such as patches, additions or removals, and build parameters. The README states that overlays always carry a description explaining why the change is needed, and that they exist so the project can avoid forking upstream specs.

The output is rendered specs. These are the final .spec files produced by applying overlays, mechanically generated by azldev, and checked in under specs/ for visibility and auditability. The README is explicit that they are derived output and should not be hand-edited, and that they feed standard RPM tooling such as mock and rpmbuild, or koji. Two directories carry the same warning: specs/ and locks/. The locks directory holds per-component lock files pinning upstream commits and input fingerprints. That combination, declarative overlays plus pinned upstream commits, is the supply chain argument in concrete form. It also means the interesting review work happens in base/comps/ and locks/, not in the generated specs.

## Installing Azure Linux 4 from the ISO or the WSL package

The README gives three ways in: an Azure VM from the Marketplace, a container image, and a local VM or WSL install. The ISO path is the most self-contained, so start there. Download the x86_64 or ARM64 ISO from the links the README provides, then verify it before booting. The repository ships a dedicated document for this, docs/verify-iso-signature-and-checksum.md, and the README says to follow it before using a downloaded ISO.

Once verified, the install itself is Anaconda, the same installer Fedora uses. The README points to docs/iso-installer-in-local-vm.md for installing in Hyper-V on Windows or QEMU/KVM on Linux, and notes that ISO support is community based, with bugs filed through GitHub Issues after searching existing ones.

For WSL, the flow is a .wsl distribution package rather than an ISO. Download the package for your architecture, verify it against docs/verify-wsl-signature-and-checksum.md, then install it. The README gives this command:

```powershell
wsl --install --from-file "C:\Path\To\AzureLinux-4.0-ARCH.wsl"
```

The path and file name must match what you downloaded. After it completes, list the installed distributions to confirm the name:

```powershell
wsl --list
```

Then start it with the distribution name the listing shows:

```powershell
wsl -d AzureLinux-4
```

If you only want the container base, the README gives the image reference directly, and there is nothing to install locally. Note the beta in that registry path. It matches the README's own warning that Azure Linux 4 is still in development.

## Where Azure Linux 4 is the wrong tool

The README says plainly that Azure Linux 4 is still in development. That single sentence governs every adoption decision here. The 4.0 branch is the in-development source tree, and the README directs anyone who wants Azure Linux 3 to the 3.0 branch instead. If you need a distro with a settled support commitment today, the 4.0 branch is not that, and the README does not claim otherwise.

The container reference reinforces the point. It points at azurelinux-beta on Microsoft Container Registry, not at a stable channel. Pinning a beta base image in production means you inherit whatever changes land on that tag, and the README does not document a stability or deprecation policy for it.

The ISO has its own boundary. Support for the ISO is described as community based, which is a different level of commitment from the Marketplace and container paths. If your team expects vendor-backed installation support for a local VM, that expectation does not match what the README states.

Finally, the desktop question. The README describes VMs, containers and bare metal, and says nothing about a desktop edition or a GUI stack. Anyone arriving from a search for an Azure Linux desktop is looking for something this repository does not document. The same applies outside Azure: the kernel is described as Azure-optimized and the integration as Azure-native, so the further you move from that environment, the less of the stated value you actually receive.

## Azure Linux 4 against Ubuntu, Alpine and Amazon Linux

The nearest comparison is Ubuntu, because both are general purpose Linux distributions that people run on Azure VMs and in containers. The difference in approach is packaging lineage and tooling. Ubuntu is Debian-derived and uses dpkg and apt. Azure Linux is RPM-based with sources derived from Fedora, so it uses the RPM ecosystem, and its build path runs through mock, rpmbuild and koji. If your team already builds RPMs and maintains Fedora spec files, Azure Linux reuses that knowledge. If your tooling is apt-based, moving means rebuilding your image and package pipeline around RPM.

Alpine is the other common base image choice, and the split is architectural rather than cosmetic. Alpine is built around musl libc and BusyBox, which is why its images are small and why glibc-linked binaries can need compatibility layers. Azure Linux follows the Fedora lineage and inherits that ecosystem's assumptions, which matters if you depend on prebuilt binaries compiled against glibc. The trade is image size against compatibility.

Amazon Linux is the closest in intent: a cloud vendor's RPM-based distribution tuned for its own platform. The structural difference is how the distro is defined. Azure Linux 4 publishes its definition as TOML configuration plus declarative overlays applied to upstream Fedora sources, with rendered specs and lock files checked in for audit. That gives an outside reader a path to see exactly what was changed and why, provided they read base/comps/ and locks/ rather than the generated specs/ tree. Whether that transparency is worth more than the familiarity of a distribution you already run is the actual decision.

## Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-09-22. Releases on the 3.0 line have been arriving roughly monthly, with 3.0.20260909-3.0 published on 2026-09-12, 3.0.20260809-3.0 on 2026-08-13 and 3.0.20260706-3.0 on 2026-07-08. Those are 3.0 releases, not 4.0 releases, and the 4.0 branch is where the in-development work sits. Do not read a monthly 3.0 cadence as a commitment for 4.0.

The upgrade cost sits in the lock files. Because locks/ pins upstream commits and input fingerprints per component, and specs/ is generated output, the work of moving to a newer upstream Fedora state is a matter of updating locks and re-rendering, not editing specs by hand. The README is explicit that both directories should not be hand-edited. A team that edits specs/ directly will lose those changes on the next render, which is a predictable failure mode rather than a hypothetical one.

The repository is licensed MIT. That is permissive and short, and it covers the repository contents. It does not by itself tell you the licensing of every RPM the distro builds, since components are imported from Fedora's upstream packaging sources and each carries its own licence. If you redistribute images or packages, check the licence metadata of the components you ship. Nothing here is legal advice.

## Conclusion

Adopt Azure Linux 4 if you are standardizing container base images on Microsoft Container Registry or provisioning Azure VMs from the Marketplace, and you are comfortable that the README labels the branch as in development. Do not adopt it for a desktop, for a non-Azure cloud, or as a general-purpose server distro where you need a long support window today; the README offers no desktop story and no support commitment for the 4.0 branch. Before committing, verify the checksum and signature of the ISO or the .wsl package using the linked docs, confirm the exact image tag you intend to pin, and read DEVELOPING.md to see how overlays and locks pin upstream Fedora commits, because that is where the distro's real behavior is defined.

## FAQ

### What is Azure Linux 4 based on?

It is an RPM-based Linux distribution whose sources are derived from Fedora Linux, with Azure-specific changes applied through declarative overlays. The README describes it as built on the Fedora ecosystem and enhanced with Azure-specific innovations.

### Can I use Azure Linux on WSL?

Yes. The README provides .wsl distribution packages for x86_64 and ARM64, installed with wsl --install --from-file, and notes that you should verify the checksum and signature of the package first.

### how to install azure linux 4.0

The README lists three routes: an Azure VM from the Microsoft Marketplace, the base container image mcr.microsoft.com/azurelinux-beta/base/core:4.0, or a local install from the x86_64 or ARM64 ISO using the Anaconda installer. For a local VM it points to docs/iso-installer-in-local-vm.md.

### Is Azure Linux free?

The repository is licensed MIT, which is a permissive open source licence. The README does not state pricing for the Azure VM Marketplace image, so cost for that route is not documented in this material.

### What can I use Azure Linux 4 for?

The README describes it as a secured, reliable operating system for virtual machines, containers and bare-metal platforms. It also supports a container base image and a WSL distribution package.

## Sources

- [Issues](https://github.com/microsoft/azurelinux/issues)
- [License: MIT](https://github.com/microsoft/azurelinux/blob/4.0/LICENSE)
- [microsoft/azurelinux on GitHub](https://github.com/microsoft/azurelinux)
- [README](https://github.com/microsoft/azurelinux/blob/4.0/README.md)
- [Releases](https://github.com/microsoft/azurelinux/releases)

---

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