Apple Container: Can You Run Containers on a Mac Without Docker?

The Quiet Project That Just Hit 1.0

When Apple slipped an open-source project called Container into WWDC 2025 last year, I didn't think much of it. Version 0.1.0, and the docs came with a warning nailed to the door: stability guaranteed only across patch versions, minor versions may include breaking changes. When you see that sentence, it usually means "this is an experiment, don't put it in production."

A year later, here we are. Five days ago — June 9, 2026 — apple/container shipped 1.0.0. Over 30,000 GitHub stars, 840+ forks, 91 contributors. Those numbers alone tell you this isn't somebody's internal toy anymore.

Going from 0.x to 1.0 isn't just a number ticking over. In any project that takes versioning seriously, major version 1 is a declaration: we're standing behind this API and this behavior. It's also a promise not to casually break compatibility. Apple putting a 1.0 on this means they've decided, at least by their own standards, that it's good enough to use.

One line on what Container is: Apple's own official container tool for macOS. It creates and runs Linux containers on a Mac, it's written in Swift, and it's tuned for Apple Silicon. The part that matters is OCI compatibility. You can pull images straight from Docker Hub and push what you build to any OCI-compliant registry. Following the standard means staying plugged into the ecosystem instead of splintering off, and that's a smart call.

How It Actually Differs From Docker Desktop

On the surface it's just another way to run containers on a Mac. Look inside and the whole approach is different. This is the interesting part, so let me spend some time here.

Docker Desktop's model: boot one big Linux VM on your Mac and cram every container into it. All containers share a single kernel. macOS can't run Linux containers natively, so a Linux VM gets wedged in the middle out of necessity.

Container's model: every container runs inside its own lightweight VM. No shared kernel — each container gets an isolated VM of its own.

Different structure, different outcomes:

구분	Docker Desktop	Apple Container
VM 구조	큰 VM 1개 공유	컨테이너마다 경량 VM
커널	모든 컨테이너가 공유	컨테이너별 독립
격리 수준	컨테이너 수준	VM 수준
데이터 노출	공유 VM에 저장	필요한 데이터만 마운트
작성 언어	Go 등	Swift

The advantages that fall out of this are pretty clear.

First, security. Each container is isolated at the VM level, which shrinks the attack surface. If one container gets popped, spreading to the neighbor is hard. In a shared-kernel setup a single kernel vulnerability hits everything; here that chain is cut.

Second, privacy. Instead of piling all your data into one shared VM, you mount only what each container needs. Data doesn't accumulate in a single place, so exposure narrows on its own.

Third, resource flexibility. Your first reaction is probably "a VM per container, isn't that heavy?" In practice it uses less memory than the single big VM, and startup is comparable to a container inside a shared VM. Run container run and your container is up in a few seconds — I can barely tell the difference from Docker. I expected stronger isolation to cost me speed, and it didn't. That surprised me.

Worth being honest about one thing: a VM per container isn't a new idea. Kata Containers went down this road already. What's different is that Apple optimized it at the OS level, on top of macOS's own virtualization framework. Same idea, but who implements it and at which layer changes how polished the result is — and having the company that owns the OS do it themselves is decisive.

The Real Weapon in 1.0: Container Machines

Through the 0.x days, Container was honestly just a Docker stand-in that copied the basics. It ran containers, it built images, and that was about it — no real reason to switch. Then 1.0 landed container machines, and suddenly the tool has an identity of its own.

A container machine is, in a phrase, a persistent Linux environment. Light like a container, stateful like a virtual machine. It sits right between the throwaway nature of containers and the permanence of a VM.

The usage is straightforward:

# dev라는 이름의 머신 생성
container machine create dev

# 머신 시작
container machine start dev

# 풀 기능 리눅스 셸 실행
container machine exec dev bash

Look familiar? Yeah — it's the same flavor as WSL (Windows Subsystem for Linux). Think of it as a Linux dev environment you can live in on a Mac for months. Close it, reopen it, and everything you installed and configured is still there.

Why this matters: Mac users have never had a clean option for a proper Linux dev environment. Docker containers are too ephemeral to treat as "my dev box." A full VM is heavy and annoying to manage. Container machines fill that gap. Consider what WSL did to the Windows development experience, and you get a sense of the ceiling here.

WWDC 2026 gave container machines their own dedicated session, "Meet container machines." That tells you Apple is pushing this as a headline feature, not a nice-to-have. The ambition goes past "Docker replacement" toward "the official way to use your Mac as a Linux dev machine."

Installing and Running It: Easier Than Expected

If you want to try it, check the requirements first. You need Apple Silicon Mac + macOS 26. Intel Macs aren't supported at all, and neither are older macOS versions, because Container leans hard on the new virtualization and networking features in macOS 26. I'll come back to this dependency — it cuts both ways.

Installation itself is simple:

1. GitHub Releases로 가서 최신 pkg 설치 파일을 받습니다
2. 두 번 클릭해서 설치합니다
3. 설치 후 시스템 서비스를 시작합니다
4. 처음 실행하면 리눅스 커널을 설치하라는 메시지가 뜨는데, 계속 '예'를 선택하면 됩니다

After that you work almost exactly the way you would with Docker.

# 이미지 받아서 실행
container run -it --rm alpine:latest sh

# Dockerfile로 빌드
container build --tag my-app --file Dockerfile .

# 이미지 푸시
container image push registry.example.com/my-app:latest

# 실행 중인 컨테이너 보기
container ls

The command surface tracks Docker closely. Even the shorthands carry over: container ls is container list, container rm is container delete. If you've used Docker at all, the learning curve is basically zero.

That's not an accident, it's the design. The biggest barrier to adopting a new tool is having to abandon what you know and learn something else. Match the commands to Docker and that barrier evaporates — migration cost drops to nearly nothing. It's the same strategy as adopting OCI: use compatibility to lower the entry cost, then differentiate on the structural stuff (VM isolation, container machines).

The project also ships a getting-started tutorial that walks you through building a web server image from scratch and pushing it to a registry. Well organized for someone coming in cold.

Details Worth Noticing If You Actually Work In This

It's not just the commands that feel familiar. The features you reach for day to day got real attention too. A few worth calling out.

SSH forwarding — pass --ssh and your macOS SSH agent socket gets mounted into the container automatically. No hand-wiring volumes, and the connection survives a container restart. Anyone who's fought with this in Docker knows how much that one flag saves.

Local domains — you can attach a local DNS domain like my-web-server.test to a container. Hit it in the browser by name, no memorizing IPs. The payoff is biggest when you've got several containers up at once.

Port forwarding — works like Docker's -p, and supports both IPv4 and IPv6 loopback.

Cross-architecture builds — one command builds an image supporting both arm64 and amd64.

container build --arch arm64 --arch amd64 --tag my-image .

Working on Apple Silicon while also needing amd64 images for servers is a common spot to be in, and handling it in one shot simplifies the workflow.

Resource control — --cpus and --memory limits, same as Docker. You can also set separate resource quotas for the builder at build time, so a container can't eat your whole laptop.

Details like these tell me somebody thought about how developers actually use the thing, rather than shipping it and moving on. Sitting where it can pull directly on the OS's networking and credential features gives it a smoothness outside tools can't fake.

So Can You Drop Docker? Not Yet

It all sounds good so far, but let's be blunt: 1.0 does not fully replace Docker Desktop. There are real holes.

First, there's no built-in equivalent to docker-compose. If you want to compose multiple containers into one unit, you're rolling your own. Multi-container setups are table stakes in real work, so this is a sizable gap — a huge number of dev environments are compose-based.

Second, the ecosystem is behind. Third-party tooling and CI/CD integration are far less mature than Docker's. Docker has a decade-plus of accumulated ecosystem; a one-year-old project isn't closing that overnight.

Third, you're permanently tied to macOS 26. No Apple Silicon + macOS 26, no Container. Intel Mac users and anyone on an older macOS are excluded outright. That's the price of coupling deeply to the virtualization framework — paid in exchange for performance and integration, but if your environment doesn't match, the tool simply isn't an option. Not a constraint you can wave away.

Fourth, it's still new. The community is just getting going and the plugin ecosystem is still taking shape.

Hard to hold all that against it, though. The project is one year old. It's open source under Apache 2.0, the Apple team maintains it actively, and the bar for contributing is low — the docs explicitly invite anyone to file bug fixes and add features. Given it went from zero to 30k stars and 1.0 in a year, the missing pieces filling in is probably a matter of time.

What This Project Means

Step back a bit and the market picture comes into focus. Docker Desktop went paid and took heat for a while, and tools like Colima and OrbStack moved into that opening, each in their own way. Now the company that owns the OS has walked into the same territory.

That's the difference that counts. However well Colima or OrbStack are built, they're third parties sitting on top of macOS. Container's core Swift package, Containerization, is wired into macOS's virtualization framework, vmnet networking, Keychain credential management, launchd service management, even the unified logging system. Foundation to roof, all their own. Third parties essentially cannot match that kind of vertical integration. Only a company with access to the OS's internal APIs can build this.

So this isn't one more tool on the pile. It's the first officially supported, fully native way to run Linux containers on a Mac. It sets a direction.

Nobody's ripping out Docker tomorrow, obviously. No compose, young ecosystem. But put the architecture, the depth of integration, and the fact that it's Apple together, and the long-run trajectory isn't hard to sketch. It looks small now, but OS-level integration compounds.

If you're on an Apple Silicon Mac running macOS 26, it's worth installing at least once. The next time someone asks "is there any way to run containers on a Mac other than Docker?", you've got a different answer.

Tools survive on standards or on integration. Container took OCI for compatibility and built its edge on OS integration. What that combination looks like a year from now is the reason I'm already curious about the next WWDC.