Microsoft has officially unveiled Azure Linux 4.0, marking a major evolution for the open-source Linux distribution designed for cloud infrastructure, enterprise workloads, and modern data centers. Formerly known as CBL-Mariner, the operating system has powered Microsoft’s internal cloud services for years, but the latest version transforms it from internal cloud plumbing into a full-fledged, general-purpose server distribution that organizations can deploy on their own servers and virtual machines.
Microsoft Releases Azure Linux 4.0 as General-Purpose Server Operating System
The release allows users to download Azure Linux ISO images and install them outside Microsoft’s own Azure cloud, expanding the platform beyond its original design. According to Microsoft’s principal program manager on Azure’s open-source team, Lachlan Evenson, the distribution uses Fedora as an upstream source, utilizing RPMs in the Fedora ecosystem while Microsoft curates the packages and supply chain to fit its cloud platform.
Core Technical Underpinnings and Enterprise Features
Azure Linux 4.0 is built on top of Fedora Linux and ships with a hardened Linux kernel 6.18 while still in beta. The operating system is tuned specifically for Hyper-V and Azure virtual machine performance, and it features SELinux-based security along with a default configuration aimed at cloud and server workloads.
The software stack in version 4.0 has been modernized with several key security and management capabilities, including:
- SELinux enabled for mandatory access controls
- Secure Boot support
- Signed packages
- Timely delivery of critical security updates
- A predictable servicing lifecycle for enterprise deployments
Microsoft states that critical and high-severity vulnerabilities are addressed through SLA-driven patch delivery to help organizations maintain secure production environments. Additionally, the distribution’s GitHub project outlines a build system that consumes Tom’s Obvious Minimal Language configuration files to produce signed RPM repositories and multiple image formats, such as Virtual Hard Disks for Azure, container images, and bootable ISOs.
Deployment Scenarios and Support Boundaries
Unlike desktop-focused Linux distributions, Azure Linux is optimized for infrastructure, virtualization, containers, and cloud-native applications. Typical deployment scenarios outlined by linuxjournal.com include cloud virtual machines, Kubernetes clusters, container hosts, AI infrastructure, edge computing, and enterprise servers.

Microsoft utilizes a dual positioning strategy by offering Marketplace images for the Azure cloud alongside downloadable ISOs for standalone use. However, the documentation notes important support distinctions for the installation media. Support for the ISO is community-based, and bare metal, ISO images, on-premises deployments, and other clouds are not officially supported. Furthermore, customized images are only supported when built on top of a prebuilt Azure Linux image using tools like Image Customizer, while images built entirely from scratch from GitHub sources are not covered. Microsoft also notes that the current ISO release remains in public preview and is intended for evaluation rather than production deployments.
Compliance Auditing and Hybrid Environment Integration
Alongside the operating system rollout, native CIS Benchmark auditing is available for Linux virtual machines in both Azure and Azure Arc-enabled environments. Powered by the azure-osconfig compliance engine, the feature allows organizations to continuously assess compliance through Azure Machine Configuration.
Microsoft explains that the audit experience is ready for production use, enabling teams to continuously assess Linux workloads against official, CIS-certified benchmarks at scale and obtain clear compliance reporting directly in Azure Policy and Azure Resource Graph. The feature provides automated compliance assessments, detailed reporting, and visibility into configuration drift. Through Azure Arc, these security audits extend to hybrid and multi-cloud environments, ensuring consistent evaluations regardless of infrastructure location.
Related reading
