Running Containers the Apple Way: A First Look into Apple Container on macOS

For years, running containers on macOS has involved compromises. Docker Desktop used HyperKit to virtualize Linux, which was simple to use but resource-intensive. Alternatives like Rancher Desktop and OrbStack improved on this by being lighter, faster, and more developer-friendly, yet they all depended on the same core approach: emulating or virtualizing Linux within macOS.

Apple has now entered this space with a native solution: Apple Container, an OCI-compliant container runtime explicitly designed for Apple Silicon and macOS 15/16 and later. It is not simply a re-skin of Docker or a clone of Lima or Colima. Instead, it represents Apple’s unique approach to how containers should operate on macOS, using the Virtualization and Network frameworks that power iOS simulators and macOS sandboxing.

From Virtual Machines to Containers on macOS

On macOS, every container runtime faces a common challenge: containers are Linux processes that depend on features like cgroups, namespaces, and kernel functionalities, which macOS lacks.

The typical solution involves using a lightweight Linux virtual machine (VM).

  • Docker Desktop employs HyperKit.
  • Rancher Desktop incorporates Lima and QEMU.
  • OrbStack features an optimized virtual machine layer directly integrated with macOS networking.
  • Apple Container employs a more streamlined approach by leveraging Apple’s Virtualization Framework, which provides hypervisor and networking APIs natively supported on macOS. This results in fewer translation layers, quicker boot times, and no reliance on third-party hypervisors.

When you run “container run alpine,” it’s not a large VM. It’s a small, purpose-built micro-VM managed by macOS specifically for container workloads. The virtualization operates natively, with virtio-based I/O and macOS’s networking stack handling the interfaces. Installing Apple Container

The installation process is surprisingly clean, although it currently only supports Apple Silicon hardware. You can install it manually using the signed package from Apple’s GitHub repository.

# Check macOS version
sw_vers

# Download and install
curl -L -o container.pkg https://github.com/apple/container/releases/latest/download/container.pkg
sudo installer -pkg container.pkg -target /

# Start the container system
container system start

# Verify
container version

The installation places binaries in /usr/local/bin and sets up a background service called containersd, which is Apple’s minimal equivalent to Docker’s dockerd. You can list or inspect it using launchctl list | grep containerd.

Running Containers

After installation, the workflow resembles that of Docker or Podman. Since Apple Container adheres to the OCI standard, you can pull and run existing images without any changes.

# Pull a standard image and run it
container run alpine echo "Hello from Apple Container"

Each invocation spins up a native Linux environment running in a micro-VM, with process isolation managed through Apple’s Virtualization API. Networking behaves predictably, too. Apple Container integrates with the host’s native interface stack, rather than bridging through HyperKit.

The logs, filesystem overlays, and image caches live under ~/Library/Containers/com.apple.containerd/, and you can inspect them using container image list or container ps.

Comparing the Ecosystem

For DevOps engineers, the question isn’t “does it run containers?” but “how does it fit into my workflow?”

Docker Desktop remains the default choice for enterprise teams. It offers a mature ecosystem, graphical dashboards, Kubernetes integration, and secure credential management. However, it’s resource-intensive and requires a license for business use.

Rancher Desktop provides greater openness. It utilizes Lima and containerd internally, supports both nerdctl and Docker CLI modes, and offers built-in Kubernetes clusters through k3s. It’s reliable for developers seeking control, but it may feel slower due to its multi-layer virtualization.

OrbStack has claimed the developer experience crown. It’s lightweight, fast, and deeply integrated with macOS file systems and networking. OrbStack also supports Linux VMs and Docker images within a single UI, making local Kubernetes or Compose workloads feel seamless and intuitive.

Apple Container, on the other hand, feels minimalistic. It lacks a GUI, Kubernetes support, Compose, or swarm mode. It’s simply the container runtime. Yet, this simplicity is also its strength—it’s lean, native, and fast. It provides a clean starting point for developers who want to embed containers directly into macOS, rather than tacking them on.

What’s Missing

The initial release of Apple Container is primarily a proof of concept rather than a full production tool. It currently lacks volume mounting options aside from basic bind mounts and does not include a Kubernetes layer. Users cannot orchestrate multi-container applications or manage networks beyond the default bridge.

Most DevOps engineers rely on Docker Compose or Helm for setup, but these are not available here. To run multi-container workloads, users must manually script container run commands or use buildctl and nerdctl to integrate the runtime once the API matures.

Additionally, there is no image build subsystem yet; Docker’s BuildKit and Podman’s build engine are not yet available. Although Apple’s roadmap mentions OCI build support, it is still in the early stages. Use Cases for Apple Container

Despite its simplicity, Apple Container presents clear use cases where it already proves useful. It’s perfect for local development testing when you need to verify OCI-compliant images without Docker’s overhead. It’s also valuable for CI/CD agents on Apple hardware, especially where Docker Desktop licensing is restrictive.

With Apple Container, you can execute temporary build tasks or validate images directly, minimizing virtualization. Security-conscious developers will value its integration with macOS sandboxing and operation under Apple’s entitlement system, without requiring extra kernel extensions or privileged daemons. For some regulated development scenarios, this offers a significant advantage.

Example: Running a Web App in Apple Container

Here’s a minimal test you can try to see how it behaves under load.

# Run a small HTTP server
container run --publish 8080:8080 python:3.12-slim \
  python -m http.server 8080

Then, open http://localhost:8080 and you’ll see the directory listing of the working directory inside the container. You can inspect active sessions with ‘container ps’ and stop them with ‘container kill <id>’.

To verify network stack behavior, try pinging the host from within the container — you’ll see that Apple Container uses its own isolated subnet managed by the Virtualization framework rather than a Docker bridge.

Integration with Kubernetes (Future)

Currently, Apple Container does not offer a CRI (Container Runtime Interface) endpoint, so it cannot serve as a backend for Kubernetes. However, from an architectural perspective, nothing prevents it from supporting this functionality in future releases.

If Apple chooses to include CRI support, Kubernetes distributions such as k3s or kind could operate directly on macOS, eliminating the need for Lima or QEMU. This would enable Apple Container to become the most lightweight local Kubernetes runtime on Apple Silicon.

Currently, developers who require Kubernetes must use OrbStack, Rancher Desktop, or Docker Desktop. However, if Apple keeps advancing their technology, this could change, particularly considering the maturity of their virtualization APIs.

Closing Thoughts

Apple Container marks an interesting evolution in how macOS fits into the cloud-native developer ecosystem. It’s not trying to replace Docker Desktop or Rancher Desktop yet; instead, it’s redefining what “native” container execution means on Apple hardware.

For DevOps engineers, this is significant. A native, lightweight, secure runtime supported by Apple could eventually eliminate the licensing hurdles and performance overhead that have historically impacted container development on macOS.

It’s early, but promising. For those of us who spend our days between Kubernetes clusters, it’s another sign that containers are no longer limited to Linux. macOS is finally becoming a first-class citizen in the developer’s container ecosystem on its own terms.