Azure Linux 4: Microsoft Launches Fedora-Based Distro

Microsoft has just released Azure Linux 4 in public preview, and this time the story is different: for the first time, the company's server distribution is not born from an isolated internal fork — it is built directly on Fedora. Brendan Burns, co-creator of Kubernetes and Corporate Vice President of Azure OSS, made the announcement at the Open Source Summit North America on 18 May 2026, and the message is clear: CBL-Mariner is in the past.

TL;DR

• Azure Linux 4 abandons the independent packaging of CBL-Mariner and now derives packages from Fedora Linux via TOML overlays.
• First version of the family designed for Azure VMs, not just AKS containers.
• Still in public preview; full release expected at Microsoft Build in June 2026.
• Announced by Brendan Burns (co-founder of Kubernetes, CVP of Azure OSS).
• 2-year support window per release.

Why Microsoft Swapped CBL-Mariner for Fedora

CBL-Mariner — rebranded as Azure Linux in versions 2 and 3 — always carried a structural problem: it was a fork. Every package had to be packaged, reviewed, and maintained by Microsoft's own team, even when equivalent work had already been done upstream by Red Hat, IBM, and the Fedora community. At the scale of an entire distribution, this becomes operational cost and delays in the security patch pipeline.

The decision to rebase on Fedora solves this problem at its root. Fedora is the upstream base of Red Hat Enterprise Linux, has an aggressive release cycle (about six months), and a mature security process with review by a huge community. By anchoring there, Microsoft shifts the burden of package bring-up to a much larger team and gains a more auditable software supply chain.

Strategically, there is another reading: Microsoft is consuming the work of the IBM/Red Hat ecosystem without paying for RHEL. It is an elegant move — it delivers a free Linux server to Azure customers, maintains RPM compatibility close to RHEL, and takes pressure off its own engineering. For those operating large VM fleets on Azure, this is exactly the kind of simplification that makes a difference at the end of the fiscal year.

What is Azure Linux 4.0 — Technical Summary

Azure Linux 4 is an RPM-based distribution, maintained by Microsoft, with sources derived from Fedora upstream. The code lives in the official repository at github.com/microsoft/azurelinux, in the 4.0 branch.

These are the confirmed facts from official materials and coverage reports:

• Build pipeline: standard RPM packaging tools — mock, rpmbuild, and Koji.
• Packaging model: TOML configuration files that describe minimal overlays applied on top of Fedora.
• SPEC files: automatically generated and versioned in the repository, instead of maintained by hand. This makes it auditable what Microsoft changed relative to Fedora.
• Workload targets: VMs, containers, and bare metal — a clear expansion from versions 1, 2, and 3, which existed primarily to serve AKS.
• Support: two-year window per release.

The choice of TOML and restricted overlays is deliberate: Microsoft wants to avoid repeating the Mariner mistake, where divergence from upstream accumulated over the years. The smaller the overlay, the easier it is to rebase when Fedora advances a version.

Will CBL-Mariner Still Exist? The Fate of Azure Linux 3

Yes, for now. Microsoft itself recommends Azure Linux 3 (Mariner) for production workloads today, precisely because version 4 is still in preview and no downloads have been released. As of the date of this post (25/05/2026), there is no official end-of-life date for Mariner — but the market signal is unequivocal: once Azure Linux 4 exits preview, Mariner enters maintenance mode.

For those already running production workloads on Mariner, two practical paths:

1. Stay on Mariner until official support ends and migrate in a planned window.
2. Validate v4 in a staging environment as soon as the public preview goes GA — expected at Microsoft Build in June 2026.

We do not recommend early migration. A distro in preview changes package contracts without notice, and that breaks deployment and monitoring automation. Those who have been operating infrastructure for a while have been through this and know the cost of being a test rabbit.

How Azure Linux 4 is Built on Fedora

Technically, the distro works as a set of targeted overlays on top of Fedora. Each overlay changes only what needs to be Azure-specific — kernel patches for hypervisor integration, default cloud-init settings, specific hardening, native integrations with Azure Arc, Defender for Cloud, and Azure Monitor.

Packages come directly from Fedora's upstream repositories. This means the security update cycle no longer depends on Microsoft repackaging anything: when Fedora releases a fix, the distro inherits it almost immediately, with much shorter propagation time than the old Mariner.

The choice of TOML as the description language is not aesthetic. TOML is strictly declarative and auditable — anyone can read the repository and understand exactly which packages come from Fedora intact and which have been altered, without needing to interpret complex build logic in shell or Python.

For those maintaining infrastructure, this reduces the time to answer "how was this distro made?" from hours to minutes. And for compliance audits — common in government, finance, and healthcare — it becomes a real differentiator when approving the stack.

Where to Run: VMs, AKS, and Azure Container Linux

The Azure Linux family gained two distinct legs in 2026:

• Azure Linux 4 — general-purpose Fedora-based distro, suitable for Azure VMs, AKS, and bare metal.
• Azure Container Linux — immutable distro, derived from Flatcar Container Linux, suitable for container hosts in regulated or high-security scenarios. It is already generally available (GA).

The difference is important and separates two worlds:

Feature	Azure Linux 4	Azure Container Linux
Base	Fedora	Flatcar
Model	Traditional (mutable)	Immutable, read-only
Package manager	Yes (RPM)	No
Use case	VMs, AKS, bare metal	Hardened container hosts
Status	Public preview	GA

For most Azure customers running traditional applications — Java, .NET, PHP, Node, Python — this is the right choice. For those wanting a minimalist host, without a package manager, with atomic updates (classic A/B partition scheme), Azure Container Linux is the perfect match.

Who is Behind It: Brendan Burns and Microsoft's Open Source Strategy

The announcement was made by Brendan Burns — and that is not a detail. Burns is co-founder of Kubernetes, former Google engineer, and now Corporate Vice President of Azure Open Source at Microsoft. When he signs off, the Linux community listens.

There is an institutional reading here that goes beyond the product. Five years ago, "Microsoft Linux server distro" would have sounded like a contradiction in terms. In 2026, the company operates one of the largest Linux fleets in the world on Azure, contributes heavily to the mainline kernel, maintains WSL, and now runs its own distro derived from Fedora. The "Microsoft vs Linux" war is over — and Microsoft won by stopping fighting it.

For the end customer, this translates into something concrete: the chance to run Linux workloads on Azure with a single vendor, no extra license, native integration with Azure Arc, Defender, Monitor, and Update Manager. Fewer contracts, fewer points of failure, less negotiation at year-end.

How Azure Linux 4 Affects Azure Customers in Brazil

For those operating infrastructure in Brazil — including customers hosting Moodle platforms, APIs, and e-commerce on Azure — the arrival of the new distro opens three practical possibilities:

1. License cost reduction. Today, many Linux VMs on Azure run Ubuntu Pro or RHEL, with an extra hourly licensing fee per VM. Azure Linux is free and optimised for Azure.
2. Vendor simplification. SLA, patches, integration with Defender for Cloud, updates via Azure Update Manager — all in one place to manage.
3. Compliance and LGPD. Log integration with Azure Monitor comes pre-configured by default. It does not change what you need to do for LGPD, but it eliminates hours of agent configuration. It is worth remembering that infrastructure is only part of it: the customisation of Moodle and the mobile ecosystem that delivers real value continues to be what differentiates the product, regardless of the distro underneath.

The Brazil South (São Paulo) region already receives most Azure offers on the same day as the global announcement. When v4 exits preview, it should appear in the local image marketplace without significant delay compared to the United States.

Comparison: Azure Linux 4, Ubuntu Pro for Azure, and RHEL on Azure

To decide on a VM distro on Azure in 2026, the picture looks like this:

Criteria	Azure Linux 4	Ubuntu Pro for Azure	RHEL on Azure
Maintainer	Microsoft	Canonical	Red Hat (IBM)
Base	Fedora upstream	Ubuntu LTS	RHEL upstream
Licensing model	Free	Paid (per hour/VM)	Paid (per hour/VM)
Declared support	2 years per release	Up to 10 years (LTS + ESM)	10 years
Release stability	Recent (preview)	Mature	Mature
Azure integration	Native, first-class	Deep	Deep
Community	Under construction	Huge	Huge (enterprise)

When to choose each:

• Azure Linux 4: new workloads, environments where reducing license cost matters, teams already operating an RPM stack and wanting alignment with the Azure roadmap.
• Ubuntu Pro for Azure: workloads that depend on packages from the Debian/Ubuntu universe (snap, specific PPAs, third-party repositories that only publish .deb), teams accustomed to apt.
• RHEL on Azure: regulated environments where the customer requires a vendor with 25 years of enterprise Linux track record and a support window of an entire decade.

How to Test Azure Linux 4 Before Build 2026

Since there is no official image on the marketplace yet, those who want to experiment need to build locally from the repository. The flow is the traditional Fedora world:

1. Clone the repo: git clone https://github.com/microsoft/azurelinux.git --branch 4.0
2. Install mock and rpmbuild on a recent Fedora or RHEL machine.
3. Apply the TOML overlays from the repository following the README of the 4.0 branch.
4. Run the documented build target to generate a VHD image usable in a Hyper-V environment or Azure VM.

For those who just want to run, not build, the recommendation is straightforward: wait for the Microsoft Build announcement in June 2026. The image should appear on the Azure Marketplace shortly after, with a direct "Create VM" button. It is not worth automating a local build of a preview distro for production — it is time wasted on something that will change.

What to Expect at Microsoft Build (June 2026) and Next Steps

Microsoft Build 2026 will be the official stage for the full rollout. What to expect, based on Microsoft's pattern from previous releases:

• Official Marketplace images with vendor support.
• Ready-to-deploy ARM/Bicep templates.
• Documented integration with Azure Arc, Defender for Cloud, Update Manager, and Azure Monitor.
• Likely some assisted migration tooling from Mariner to v4.
• Possible specific SKUs for AI/GPU workloads — given Microsoft's investment in infrastructure for OpenAI, Copilot, and its own models. It is precisely at this point that v4 becomes a strategic piece: the OS base behind the company's AI infrastructure.

For CTOs and platform teams, the recommendation is simple: follow, but do not migrate yet. Use the interval between May and Build to map which current workloads would make sense to migrate, validate costs compared to Ubuntu Pro, and design the pilot. When GA arrives, the migration decision will be based on fact, not hype.

Conclusion

Azure Linux 4 marks a rare turning point: Microsoft has moved from "having a distro to say it has one" to "operating Linux server seriously, in the same ecosystem as Red Hat." The Fedora base reduces maintenance cost, improves patch speed, and opens the door for the largest Linux fleet in the world — Azure's — to receive a native, free, and well-integrated alternative.

For those operating infrastructure, the next useful move is not to migrate now, but to measure: how much of your current Azure fleet runs Ubuntu Pro paying extra license? How much would that fleet cost on a free, integrated Azure Linux 4 maintained by the same vendor that operates the hypervisor? That number will guide the decision in Q3 and Q4 of this year. And if you operate platforms like Voyia, it is worth remembering that real savings usually come from architecture — not just the infrastructure underneath it.