Apple Container 1.0: Native Linux VMs on Apple Silicon

Ever since Apple completed its transition to its own Apple Silicon chips, one question has lingered across the developer community. Can Mac users truly run a proper Linux environment on these machines? After an initial preview at WWDC 2025, Apple has now formally released its open-source command-line tool on GitHub. Written in Swift, this project is called Container 1.0.0. Designed specifically for Apple Silicon, it treats Linux containers as lightweight virtual machines, both to create and to run them. This 1.0 release also introduces robust support for persistent, stateful environments along with improved file management.

Full Compatibility With OCI Container Images

According to the project’s documentation, Container is fully compatible with container images that follow the Open Container Initiative, or OCI, standard. As a result, developers can seamlessly pull, build, and push images using standard container registries.

A New Isolation Model: One Container, One Lightweight VM

Traditionally, running Docker or other Linux containers on a Mac meant spinning up one large Linux virtual machine first. Every container would then run inside this shared environment. While convenient, this approach often falls short when it comes to clean resource allocation and true isolation at the system level.

Apple’s Container project takes a fundamentally different approach. For every single container, the system creates its own dedicated, lightweight virtual machine. This architecture rests on Apple’s own Swift package called Containerization. In practice, this means each container gets complete virtual-machine-level isolation, while mounting only the host data that container strictly needs. The result is a project that runs natively, letting Mac developers work with Linux container workloads using the same fluidity and logic they expect from native macOS tools.

Four Major Upgrades in Version 1.0

The official release of Container 1.0.0 brings several important updates, each tailored to everyday development workflows.

First, Apple introduced state preservation for what it calls a Container Machine. Previously, most containers existed as temporary virtual machines built for a single task. The new version allows a container machine to be stopped and restarted just like a real computer, all while preserving its internal filesystem state. This proves especially useful for setting up stable development environments or for repeatedly testing the same service.

Second, configuration moved to TOML files. Gone are the somewhat cumbersome system property commands of earlier versions. Instead, the project now relies entirely on the more readable and extensible TOML format for managing configuration.

Third, Apple added seamless file transfer between the host and containers. New, intuitive file-copy commands let developers easily drop files from their Mac directly into a container, or pull test results from a finished container run straight back to the host machine.

Fourth, the tool now offers structured output for automation. Queries covering containers, images, networks, and storage now return results in a structured format. This makes it far easier for automation tools, such as CI/CD pipelines, to read and parse the information.

Hardware and System Requirements: macOS 26 Unlocks Full Power

Despite these exciting features, Container 1.0 comes with clear usage limitations. First and foremost, the project only supports Macs equipped with Apple Silicon, meaning the M-series chips. Furthermore, the tool was designed around the virtualization and networking frameworks found in the latest operating systems. Consequently, its primary target is macOS 26 Tahoe, though it also works with macOS 27 Golden Gate and later releases.

Apple notes that the tool can technically run on the older macOS 15 Sequoia as well, but with significant feature limitations. For instance, containers running under Sequoia cannot communicate with each other over a virtual network. Additionally, the underlying virtualization layer in macOS does not yet handle dynamic memory reclamation perfectly. Therefore, developers running multiple high-load containers simultaneously over long periods may occasionally need to restart containers manually to free up memory.

Apple’s Bid to Define the Mac Container Ecosystem

The release of Container 1.0 reveals a quiet but deliberate strategy at Apple. The company appears determined to build its own native container standard, one that leans heavily on the hardware advantages of Apple Silicon.

For years, the Mac has remained a favorite among web backend and software engineers. However, as cloud-native architectures and microservices have become standard practice, third-party tools like Docker turned into essential parts of the developer toolkit. Apple clearly recognizes that excessive reliance on third-party cross-platform virtualization tools prevents developers from fully tapping into the performance and power efficiency advantages of M-series chips.

By open-sourcing the Container project and adopting a clean one-container-per-VM architecture built on lightweight virtual machines, Apple is effectively sending developers a clear message. Running Linux containers through its own native framework offers the smoothest, most secure, and most power-efficient experience available. Developers interested in trying the tool can find Apple’s open-source Container project page for further documentation and source access.

What Comes Next

Container still faces challenges around memory management and version compatibility. Even so, as macOS continues refining its built-in Virtualization framework, this native Apple container tool could become one of the most disruptive new standards within the Mac developer ecosystem.