Apple quietly launches Container on GitHub to bring Linux development to macOS in a native way

Apple has released a new developer tool on GitHub called Container, offering a fresh approach to running Linux containers directly on macOS. Unlike Docker or Podman, this tool is designed to feel at home in the Apple ecosystem and hooks into frameworks already built into the operating system.

Container runs standard OCI images, but it doesn’t use a single shared Linux VM. Instead, it creates a small Linux virtual machine for every container you spin up. That sounds heavy at first, but the VMs are lightweight and boot quickly. Each one is isolated, which Apple claims improves both security and privacy. Developers can run containerized workloads locally with native macOS support and without needing to install third-party container platforms.

Containers, for those unfamiliar, are compact packages that hold an app and everything it needs to run. Developers use them to ensure consistency between development, testing, and production. They’re widely used in CI pipelines and server environments because they can move from one machine to another without breaking.

Apple’s approach with Container takes this idea but swaps the shared VM model for separate minimal virtual machines. It leans heavily on Apple technologies like the Virtualization framework for launching Linux VMs, vmnet for networking, XPC for communication between processes, and launchd for service control. The tool even supports Keychain for storing credentials and uses macOS logging for diagnostics.

The container command line tool is how users build images, start containers, and interact with OCI registries. It works with a background service called container-apiserver. When you run container system start, this agent launches and manages all supporting processes. That includes container-core-images for image storage and container-network-vmnet for handling network functions. Each running container gets its own instance of container-runtime-linux, which handles communication with that VM.

Because each container has its own VM, the setup provides better isolation. It also means you don’t have to overexpose host resources when mounting files. You can mount only what is needed into the container, avoiding the catch-all file sharing setups that some other tools require.

That said, Container isn’t flawless. If a container tries to access a service on 127.0.0.1, it won’t reach your host machine. You can work around that by pointing your container to 192.168.64.1 instead and using socat to forward the traffic from that address to localhost. It’s not elegant, but it works.

There are also quirks with memory. macOS doesn’t currently support full memory ballooning, so freed memory inside the container’s Linux VM may not be returned to the host. Running a few large containers could cause macOS to hang onto more memory than necessary. Restarting the containers helps reclaim it.

On older versions like macOS 15, the experience is worse. Container was built with macOS 26 in mind. On older systems, networking between containers is broken, IP address assignment can fail, and the network stack can misbehave. Apple has no plans to fix issues that only affect macOS 15.

Still, this is a rare thing. Apple is releasing a dev tool under a permissive license and encouraging community contributions. Both Container and the lower-level Containerization package are open source. If you’re a developer working in a Linux-based environment and prefer macOS as your desktop, this tool might be worth exploring.

It’s not a replacement for Docker just yet, but it’s an interesting move from a company that usually treats the terminal like a side hobby. Container feels like a real effort to bring native Linux container development to macOS… with Apple’s own flavor baked in.