Frequently Asked Questions

For Apple Silicon Macs running macOS 26+, yes — with the compose workaround documented on this site. If you need x86 containers or cross-platform CI builds, keep Docker Desktop around for those specific use cases. Many teams run both side by side during migration.

No. Apple Container is Apple Silicon (ARM64) only. Docker images with --platform linux/amd64 won't run. If your stack depends on x86-only images, you'll need Docker Desktop for those.

Yes — for ARM64 images. Apple Container is OCI-compatible and pulls directly from Docker Hub, GHCR, and any OCI registry. Most popular images (nginx, postgres, node, python, redis) have ARM64 tags.

No. Apple Container uses macOS Virtualization.framework, which is Apple Silicon only (M1/M2/M3/M4). Intel Macs are not supported and will not be.

Container startup: noticeably faster (<1s vs 3-5s). I/O: better for bind-mounted volumes (native APFS, no Linux VM layer). Network throughput: comparable. Memory: lower idle footprint — containers only consume RAM when running, no persistent VM overhead.

Minimal. Each container runs in a lightweight VM on Virtualization.framework — Apple's hypervisor is thin. CPU-bound workloads run at near-native speed. I/O-bound workloads see a 5-10% overhead from the virtualization layer (similar to Docker Desktop on macOS).

No official timeline. The docker/compose repo has an open issue (#12934) requesting support, and Apple Container's team is aware of the demand (GitHub issues #55, #186). Until then, Container Machines + shell scripts is the working solution.

Keep them. They're still your source of truth. The conversion is manual (for now), but the structure maps cleanly: services become containers within a machine group, volumes become bind mounts or named volumes, and networking uses DNS instead of service-name resolution. See the compose alternative page for the full mapping.

Apple Container doesn't have a Kubernetes backend. If you need K8s, consider Docker Desktop with the built-in Kubernetes cluster, or a cloud-based dev environment. Apple Container is designed for local development and single-host production — not container orchestration at scale.

Yes — each container runs in its own VM, which provides stronger isolation than Docker's shared-kernel model. The production manual covers TLS termination, network isolation, and secrets management specific to Apple Container. The Virtualization.framework entitlement model also means apps can't escape their sandbox.

Export from Docker first: docker run --rm -v your_vol:/data -v $(pwd):/backup alpine cp -a /data /backup/. Then bind-mount the backup into your Apple Container or create a new named volume and copy the data in. The manual includes step-by-step volume migration for PostgreSQL, MySQL, and Redis.

Yes. They coexist without conflict. Apple Container uses Virtualization.framework, Docker Desktop uses its own hypervisor. You can run containers on both simultaneously while testing the migration.

This is a known issue (GitHub #1693, #856). Apple Container's DNS uses a dev.internal domain that sometimes loses resolution after restarts or network changes. Workarounds: (1) Check DNS config with scutil --dns | grep containerization, (2) Recreate your network with container network create new-net and re-attach containers, (3) Fallback: use /etc/hosts entries with container IPs (get IPs from container ps). The production manual covers 4 DNS troubleshooting patterns with exact commands.

Snapshots and rootfs.ext4 files can silently consume hundreds of GB without user-initiated snapshots (GitHub #784). Check disk usage: du -sh ~/Library/Application Support/com.apple.container/. The manual includes a maintenance section on pruning snapshots and managing disk consumption.

Apple Container doesn't auto-start containers natively (GitHub #158). You need a launchd plist. Here's a basic example: create ~/Library/LaunchAgents/com.maccontainer.webstack.plist with a RunAtLoad key pointing to your start script. The production manual covers launchd auto-start with health checks, startup ordering, and failure recovery — not just a basic plist.

Single-container setup: 10–15 minutes. A 3-service docker-compose stack: 1–2 hours. A 5+ service stack with health checks, startup ordering, and persistent data: 2–4 hours with the manual (4–8 hours without). These estimates include debugging time. They don't include time reading GitHub issues.

Each container runs in its own VM on Virtualization.framework — stronger isolation than Docker's shared-kernel model. But production readiness requires work Apple didn't document: TLS termination, network isolation, log rotation, auto-start, resource limits, backup strategies. The production manual covers all of these with tested configurations. Apple Container itself is solid; the gap is operational knowledge — which is exactly what the manual provides.