Meet container: Apple’s Open-Source Swift Tool for Running Linux Containers as Lightweight VMs on Apple Silicon

Apple research team recently released the container project. It is an open-source command-line tool written in Swift. It creates and runs Linux containers as lightweight virtual machines on a Mac. The project ships under the Apache 2.0 license and targets Apple silicon. Containers are how you ship reproducible environments from a laptop to a datacenter. Apple now offers a native path that avoids a single always-on Linux VM. What is Apple’s container ? container is a CLI tool that can be used to build images, run containers, and move images to and from registries. It consumes and produces OCI-compatible container images. So you can pull from Docker Hub or GitHub Container Registry and run those images. You can also push images you build to any standard registry. container uses the open-source Containerization Swift package. That package handles low-level container, image, and process management. The tool requires a Mac with Apple silicon. Intel Macs are not supported. Apple supports container on macOS 26, which adds virtualization and networking enhancements. You can run it on macOS 15, but with networking limitations. How container Runs Your Containers Most macOS container tools run one shared Linux VM that hosts every container. Apple takes a different path. container runs a separate lightweight VM for each container you create. Apple describes three properties of this design: Security: Each container has the isolation of a full VM. A minimal set of core utilities and dynamic libraries reduces resource use and attack surface. Privacy: You mount only the data each VM needs, instead of sharing everything. Performance: These containers use less memory than full VMs. Boot times are comparable to containers in a shared VM. The runtime integrates several macOS frameworks. It uses the Virtualization framework for the VMs, and the vmnet framework for networking. It uses XPC for interprocess communication, launchd for service management, and Keychain services for registry credentials. The control plane has a few moving parts. container system start launches container-apiserver, a launch agent. The apiserver then starts an XPC helper container-core-images for image management and the local content store. It also starts container-network-vmnet for the virtual network. For each container, it launches container-runtime-linux, the per-container management helper. Interactive Explainer (function(){ window.addEventListener("message", function(e){ if(e.data && e.data.mtpContainerDemoHeight){ var f = document.getElementById("mtp-container-frame"); if(f){ f.style.height = e.data.mtpContainerDemoHeight + "px"; } } }); })(); Use Cases With Examples Local backend development. Run a service in its own isolated VM, then forward a port to your loopback address. Copy CodeCopiedUse a different Browsercontainer run -d --rm -p 127.0.0.1:8080:8000 \ node:latest npx http-server -a :: -p 8000 curl http://127.0.0.1:8080 Reproducible CI-style builds. container build starts a builder utility container that uses BuildKit. You can size the builder VM for heavy builds. Copy CodeCopiedUse a different Browsercontainer builder start --cpus 8 --memory 32g container build --tag web-test:latest --file Dockerfile Cross-architecture images for datacenter deployment. Build one image for both Apple silicon and x86-64 servers. The amd64 variant runs under Rosetta translation. Copy CodeCopiedUse a different Browsercontainer build --arch arm64 --arch amd64 \ --tag registry.example.com/fido/web-test:latest Mounting datasets for analysis. Share a host folder into the container with --volume. This is useful for feeding local data into a containerized job. Copy CodeCopiedUse a different Browsercontainer run --volume ${HOME}/Desktop/assets:/content/assets \ docker.io/python:alpine ls -l /content/assets Isolating untrusted or generated code. Each container runs in its own VM, not a shared kernel. That boundary suits running code from an agent or an unknown image with less host exposure. Hands-On: Core Commands Default container resources are 1 GiB of RAM and 4 CPUs. You override them per run. Copy CodeCopiedUse a different Browsercontainer run --rm --cpus 8 --memory 32g big Inspect live resource usage, similar to top for processes. Copy CodeCopiedUse a different Browsercontainer stats --no-stream my-web-server Read virtual machine boot and init logs when debugging startup. Copy CodeCopiedUse a different Browsercontainer logs --boot my-web-server On macOS 26, you can create isolated networks. Containers on different networks cannot reach each other. Copy CodeCopiedUse a different Browsercontainer network create foo --subnet 192.168.100.0/24 container run -d --name web --network foo --rm web-test By default, containers start with a restricted set of Linux capabilities. You tune them explicitly. Copy CodeCopiedUse a different Browsercontainer run --cap-drop ALL --cap-add SETUID --cap-add SETGID alpine id Version 1.0.0 also adds container machines. These are persistent Linux environments built from OCI images. Your home directory is mounted in, and the login user matches your Mac account. The filesystem survives stop and start. Any image containing /sbin/init qualifies as a container machine. Two other 1.0.0 changes affect upgraders. System settings moved to a TOML file at ~/.config/container/config.toml. The container system property get and set subcommands were removed. The tool also added structured JSON, YAML, and TOML output for list and inspect, easing automation. Apple container vs Docker Desktop PropertyApple containerDocker DesktopIsolation modelOne lightweight VM per containerShared Linux VM, shared kernelIdle footprintNear-zero when nothing runsAlways-on background VMImage formatOCI-compatibleOCI-compatibleBuild engineBuildKit via builder VMBuildKitLicenseApache 2.0Commercial terms for larger orgsHardwareApple silicon onlyApple silicon and IntelCompose / GUINot built inYesBest fitSingle-container runs, native isolationCompose workflows, mature ecosystem Strengths and Limitations Strengths: Per-container VM isolation reduces shared attack surface versus a shared kernel. Idle memory cost is low, since stopped containers free their footprint. OCI compatibility means your images run elsewhere without conversion. The Apache 2.0 license carries no feature paywall. Limitations: The macOS Virtualization framework supports only partial memory ballooning. Pages freed inside a container are not always relinquished to the host. Heavy workloads may need occasional restarts to reduce memory use. There is no built-in Docker Compose. macOS 15 users face networking restrictions, and Intel Macs are unsupported. Check out the Repo here. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Meet container: Apple’s Open-Source Swift Tool for Running Linux Containers as Lightweight VMs on Apple Silicon appeared first on MarkTechPost.