Microsoft’s move to the cloud-native world means it’s now the custodian of several quite different Linux distributions. Some are internal tools that run deep parts of Azure’s networking infrastructure; others are part of Azure’s Internet of Things platform. However, one of the most important is almost invisible: Azure Linux.

First unveiled as CBL-Mariner, Azure Linux was designed to be a base Linux platform for Microsoft’s various container services, one that Microsoft controlled and that couldn’t, like CoreOS, be withdrawn with little advance warning. Since then, Azure Linux has provided an effective Linux tool for Microsoft projects, such as Windows Subsystem for Linux (WSL), that need a small, fast Linux with minimal CPU and memory demands. It also forms the basis of much of Azure Kubernetes Service (AKS).

Going cloud-native with Azure Linux 3.0

Azure Linux 3.0 arrived in the spring of 2025 and was at once available in AKS, as part of AKS version 1.32 and higher. Based on version 6.6 of the Linux kernel, Azure Linux 3.0 builds are available for both x64 and Arm platforms, so it will run on Azure’s high-density, front-end Arm-based Cobalt systems. There is even support from many familiar cloud-native platform tools such as Dapr and Terraform, so you can integrate them into AKS solutions running on Azure Linux 3.0.

Other updates in this release include new versions of ContainerD and SystemD, as well as support for the SymCrypt cryptography library, which will help get you ready for the switch to post-quantum cryptography algorithms.

Like much of Microsoft’s open source and free software development tools, you can find the Azure Linux repository on GitHub. Here you can download its source code to build your own installation from scratch or even create a custom fork. The source code and ready-built ISOs are available, and containers with a base Azure Linux 3.0 image are in Microsoft’s container registry.

Microsoft has recently integrated Azure Linux with its OS Guard tool, building on the idea of immutable containers and adding policy enforcement to ensure only trusted binaries can run in user space, restricting them to secure protected volumes and even to specific files. There’s now support for trusted launch, which verifies your Azure Linux environments with trusted boot components and keys held in an Azure vTPM. Only authorized code can run, significantly reducing the risks of compromise.

New releases come every three years, so Azure Linux 3.0 will be the basis of the operating system until 2028. Microsoft provides tools to move from Azure Linux 2.0 to 3.0 via an update to AKS node pools, with Azure Linux 2.0 losing support in November 2025. You can expect a similar lifespan and comparable migration tools for the shift from Azure Linux 3.0 to 4.0.

Unlike some other container Linuxes, Azure Linux is not completely immutable (though it can easily be run that way). It supports familiar package management tools based on the RPM package standard. You can use tdnf to update and upgrade packages, ensuring that your container stays secure. Even so, it’s best to download the latest base image each time you need to construct an application release or a container update.

Rolling your own Azure Linux

As the project’s GitHub repository has all the code to build a full release of Azure Linux, there’s always the possibility of building from source. Microsoft provides instructions on how to build both standard and custom images, going straight from code to a bootable Hyper-V virtual machine or to an ISO that can be installed on most virtualization platforms. The option of building a custom image is interesting as it allows you to add your own choice of packages, including specific tested versions or internally developed code that is not publicly available.

Having the ability to ship your own custom base container image is important as it ensures that you have everything you need without the complexity of supporting and merging different container definitions into a deployable image. However, it does mean having to rebuild images as security updates get pushed into the mainline codebase.

Running Azure Linux 3.0 in WSL

As part of looking at Azure Linux 3.0, I decided to run it as a WSL distribution. That’s easier said than done, as it’s only shipped as an ISO image or as a Docker-format container. However, Microsoft recently added support for tarball-based installs for custom WSL instances, making it a lot easier to go from a Docker container to a working WSL Azure Linux in surprisingly few steps. I tried out this new process by building an Azure Linux installation.

Starting in an Ubuntu WSL command line, I used Podman, the open alternative to Docker, which has the same commands, to download and prepare an Azure Linux release for use in WSL. You could use Docker desktop in Windows, but I had problems with exports: It generated an unreadable tarball that was twice the size of one generated in Linux.

I first pulled the latest release from the Microsoft container repository and then had Podman run it as a named container, listing the file system contents to check that it was running correctly. I was then able to export the container contents from the image using the Podman export command, which creates a tarball from the target container’s file system.

As Windows 11 provides a direct link to installed WSL file systems from Windows, I navigated to my Ubuntu user directory and copied the Azure Linux tarball to Windows, where it was ready to import into WSL. Microsoft does provide instructions to build configuration scripts for full-scale WSL installs, but if you just want to look at a distribution and don’t mind running as root, you can simply create a target directory for your Linux file systems and use the WSL import command to create a new instance in that folder with a specific name from your tarball.

If you want to build a standard WSL image that can be installed across a team, it’s a good idea to create a package configuration using Microsoft’s recommended scripts. This will set up groups, force the creation of a local user, and add the user to them, for example, ensuring access to sudo. You can improve integration between the Azure Linux install and Windows Terminal by creating a terminal profile with the official blue penguin logo; otherwise, all you get is the default name and icon as launch options.

Installing a small-form-factor Linux like Azure Linux takes a few seconds, and you can use the command line WSL to launch your new distribution. As Azure Linux is designed to host containers within Kubernetes, the first time it runs it will throw a handful of errors as WSL tries to mount the Windows file system. However, you don’t need Windows integration to experiment with Azure Linux, so you’re still ready to start.

Making Azure Linux part of your PC

You can even access the Azure Linux file system from inside Windows File Explorer, though you may need to reboot your PC to see it. With this in place, you can start to use tools like Visual Studio Code’s remote development extensions to make building on a local copy of Azure Linux part of your cloud-native development toolchain.

You’ve always been able to use an ISO to build an Azure Linux virtual machine in your choice of hypervisor, like Hyper-V or KVM, but having a version of Azure Linux accessible from the command line can help build and test container-based applications without having to work inside a Docker environment. This keeps resource demands to a minimum and ensures you have access to both the target environment and your development toolchain on a single machine.

With a defined life cycle and the ability to run copies in VMs or locally, Azure Linux is a useful tool for building and hosting cloud-native applications in Azure. Keeping the OS small and lightweight is key to delivering a base for containers, allowing you to add packages as needed. Running a local copy as part of your daily toolchain lets you familiarize yourself with its capabilities so you know how code interacts and what system resources your application will need to give your users the best experience possible.