Microsoft’s Azure Linux 4.0, announced at Open Source Summit North America in May 2026, is the company’s first general-purpose server Linux distribution. Amazon has offered Amazon Linux as a first-party EC2 option for years. With Azure Linux 4.0, Microsoft is moving into the same space: a vendor-curated Linux base image for its cloud’s VM workloads.
What Changed from CBL-Mariner
Azure Linux 4.0 descends from CBL-Mariner, Microsoft’s internal Linux distribution built to run Azure’s own cloud infrastructure. CBL-Mariner was lightweight, RPM-based, and deliberately minimal: a small attack surface for container hosts, not something you would install on a general-purpose server. Version 3.0, still branded CBL-Mariner internally, was only available through AKS as a container host image.
The 4.0 release changes the product’s scope. Azure Linux is no longer an internal-only base layer; it is now a general-purpose server distribution with DNF5 as its package manager, shipping RPM packages and targeting VM workloads beyond Kubernetes. Microsoft’s own documentation, however, marks the current release as “strictly limited to evaluation and testing purposes” and “not suitable for production use”.
Two Products, Two Philosophies
Microsoft split the Azure Linux brand into two distinct products with the 4.0 announcement.
Azure Linux 4.0 is the general-purpose VM distribution. It has a package manager (DNF5), a conventional mutable filesystem, and a two-year support lifecycle. Think of it as Microsoft’s answer to Amazon Linux 2023: a vendor-curated base image for VM workloads.
Azure Container Linux is the immutable, container-optimized host. It descends from the acquired Flatcar Container Linux project. This product is now generally available. It fills the same niche as AWS Bottlerocket: no package manager, atomic updates with rollback, software runs only as containers.
| Azure Linux 4.0 | Azure Container Linux | |
|---|---|---|
| Purpose | General-purpose VM | Immutable container host |
| Package manager | DNF5 / RPM | None |
| Update model | Conventional (RPM) | Atomic, single-step with rollback |
| Support lifecycle | 2 years | Not specified in public docs |
| Origin | CBL-Mariner lineage | Flatcar Container Linux (acquired) |
| Status | Preview | GA |
The split mirrors what AWS already does with Amazon Linux 2023 (general-purpose, yum/RPM) versus Bottlerocket (immutable, no package manager, container-only). Microsoft is catching up to a pattern Amazon has run in production for years.
The Fedora-Upstream Strategy
Azure Linux 4.0 is built as TOML configuration overlays on top of Fedora, pulling packages from Fedora upstream repositories with minimal documented deviations. This is not a fork in the traditional sense. Microsoft’s approach is closer to “Fedora, curated and slimmed down” than to Amazon’s strategy of building Amazon Linux largely from source packages with its own patch set.
The upstream-collaboration angle is real. Microsoft engineer Kyle Gospodnetich co-authored a proposal to build x86-64-v3 packages for Fedora 45, a change motivated by Azure Linux performance requirements. Microsoft is contributing to the distro it builds on top of, rather than maintaining a private patch stack. For teams that care about supply-chain provenance, contributing upstream rather than forking is the stronger signal.
The two-year support lifecycle is shorter than what teams accustomed to Ubuntu LTS (five years standard support) or RHEL (up to ten years) would expect. For workloads with long deployment horizons, that is a practical constraint.
What “Fedora-Based” Does Not Mean
Gerard Braad, a principal software engineer, cautioned that “Fedora-based” should not be read as “Fedora-compatible”. The minimal package footprint means that dependency assumptions holding on a full Fedora or Ubuntu installation may not hold on Azure Linux. Binaries for Azure Linux 4.0 were not yet publicly available at the time of the announcement despite source code being published.
This matters in practice. If your team runs container images built against Debian or Ubuntu base layers and expects to swap those for an Azure Linux base without rebuilding, the dependency graph may not resolve. The RPM ecosystem and the Debian/Ubuntu ecosystem are different package universes. “Fedora-based” describes the build methodology, not a compatibility guarantee.
The Supply-Chain Trust Question
As of May 2026, more than two-thirds of customer cores in Azure run Linux. The default base image for those workloads is currently something Microsoft does not maintain: Canonical’s Ubuntu, Red Hat’s RHEL, or community Debian. Azure Linux 4.0 gives Microsoft a path to owning the base layer under those workloads the way Amazon Linux owns the default experience on EC2.
For AKS users, the calculus is direct. AKS node images already offer Azure Linux (the CBL-Mariner lineage) as an option. As Azure Linux 4.0 matures, it will likely become the default node image for new AKS clusters. That shifts the supply-chain trust boundary: your container base layer moves from a Canonical- or Debian-maintained image to a Microsoft-maintained RPM overlay on Fedora.
This is not inherently bad. A vendor-curated minimal base can reduce attack surface and improve boot times. Amazon Linux has demonstrated that model works in production. But it does raise the cost of auditing your own image, because you are now tracing packages through Microsoft’s overlay pipeline rather than through the Fedora or Debian build systems your team may already have tooling for.
The documentation gap is real. Existing Microsoft docs still refer to “Microsoft Azure Linux Container Host for AKS”. For a product Microsoft positions as a general-purpose server OS, the documentation still reads as AKS-only.
Where the Hyperscaler Linux Race Stands
With Azure Linux 4.0, Microsoft joins Amazon in offering a first-party Linux distribution for its cloud. What differs is the architecture. Amazon built Amazon Linux from its own package set and Bottlerocket as a separate immutable project. Microsoft chose Fedora overlays for the general-purpose case and acquired Flatcar for the immutable case.
The Fedora-upstream approach is genuinely different, and whether it holds up in production will depend on how well Microsoft maintains that overlay as Fedora moves forward. The early signals are promising: upstream contributions, transparent build methodology, and a clean architectural split between mutable and immutable host types. But “promising” and “shipped” are different states. The current preview has real gaps: no public binaries, documentation that still targets AKS, and explicit Microsoft warnings against production use. Teams running AKS at any real volume should watch this closely and test early, but wait for GA before planning migrations.
Frequently Asked Questions
Where does Google fit in the hyperscaler Linux comparison?
Google is the outlier among the three major cloud providers: it ships only Container-Optimized OS for GKE nodes and has no general-purpose server distribution. Microsoft’s two-SKU approach now covers both niches (general-purpose VM and immutable container host) that Google and Amazon each address with separate products. Amazon also offers five years of support on Amazon Linux 2023, noticeably longer than Azure Linux 4.0’s two-year window.
What does planned WSL support change for developer workflows?
Azure Linux 4.0 has WSL support on its roadmap. If shipped, developers could match their local WSL environment to their Azure VM base image, closing a workflow gap that Ubuntu currently owns as the default WSL distribution. Local testing against the same RPM package set and dependency graph would reduce the risk of drift between development and production VMs.
What does the x86-64-v3 build target imply for older Azure VMs?
The x86-64-v3 instruction set that Microsoft’s Fedora 45 proposal targets requires Intel Haswell (2013) or later processors. Older Azure instance types running pre-Haswell hardware would not support these optimized packages. Teams on legacy instance families should verify CPU feature support before planning a migration to Azure Linux 4.0 base images.
What happens to existing Flatcar Container Linux users outside Azure?
Azure Container Linux is built on the acquired Flatcar project, but Microsoft has not clarified whether Flatcar will continue as a standalone community distribution. Teams running Flatcar on non-Azure infrastructure face a familiar risk: vendor acquisitions of community Linux projects have historically led to de-prioritized non-cloud use cases, as occurred when Red Hat acquired CoreOS Container Linux and replaced it with Fedora CoreOS.