JuicyTalk
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 renderArch(mode){
if(mode===’apple’){
stage.innerHTML=’
macOS · Apple silicon · Virtualization.framework
‘
micro-VM A
‘+box(‘web (nginx)’)+box(‘vminitd init’)+’
‘+
‘
micro-VM B
‘+box(‘db (postgres)’)+box(‘vminitd init’)+’
‘+
‘
micro-VM C
‘+box(‘builder (BuildKit)’)+box(‘vminitd init’)+’
‘+
‘
‘;
archcap.innerHTML=’Each container gets its own lightweight VM with its own kernel. Isolation is at the VM boundary, and idle containers free their footprint.’;
}else{
stage.innerHTML=’
macOS · single always-on Linux VM
Shared Linux VM (one kernel)
‘;
archcap.innerHTML=’All containers share one kernel inside a single background VM. Simpler networking, but a wider shared attack surface and constant idle cost.’;
}
resize();
}
root.querySelectorAll(‘.mcd-seg’).forEach(function(s){
s.addEventListener(‘click’,function(){
root.querySelectorAll(‘.mcd-seg’).forEach(function(x){x.classList.remove(‘is-active’)});
s.classList.add(‘is-active’);renderArch(s.dataset.arch);
});
});
renderArch(‘apple’);
// auto-resize: component offsetHeight + 40 (per WordPress embed contract)
function resize(){
try{
var h=root.offsetHeight+40;
if(window.parent&&window.parent!==window){
window.parent.postMessage({mtpContainerDemoHeight:h},’*’);
}
}catch(e){}
}
window.addEventListener(‘load’,resize);
setTimeout(resize,120);
})();
“>
Use Cases With Examples
Local backend development. Run a service in its own isolated VM, then forward a port to your loopback address.
container run -d --rm -p 127.0.0.1:8080:8000 \
node:latest npx http-server -a :: -p 8000
curl http://127.0.0.1:8080Reproducible CI-style builds. container build starts a builder utility container that uses BuildKit. You can size the builder VM for heavy builds.
container 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.
container build --arch arm64 --arch amd64 \
--tag registry.example.com/fido/web-test:latestMounting datasets for analysis. Share a host folder into the container with --volume. This is useful for feeding local data into a containerized job.
container run --volume ${HOME}/Desktop/assets:/content/assets \
docker.io/python:alpine ls -l /content/assetsIsolating 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.
container run --rm --cpus 8 --memory 32g bigInspect live resource usage, similar to top for processes.
container stats --no-stream my-web-serverRead virtual machine boot and init logs when debugging startup.
container logs --boot my-web-serverOn macOS 26, you can create isolated networks. Containers on different networks cannot reach each other.
container network create foo --subnet 192.168.100.0/24
container run -d --name web --network foo --rm web-testBy default, containers start with a restricted set of Linux capabilities. You tune them explicitly.
container run --cap-drop ALL --cap-add SETUID --cap-add SETGID alpine idVersion 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
| Property | Apple container | Docker Desktop |
|---|---|---|
| Isolation model | One lightweight VM per container | Shared Linux VM, shared kernel |
| Idle footprint | Near-zero when nothing runs | Always-on background VM |
| Image format | OCI-compatible | OCI-compatible |
| Build engine | BuildKit via builder VM | BuildKit |
| License | Apache 2.0 | Commercial terms for larger orgs |
| Hardware | Apple silicon only | Apple silicon and Intel |
| Compose / GUI | Not built in | Yes |
| Best fit | Single-container runs, native isolation | Compose 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
