Macker

The Docker Desktop replacement that runs on Apple's native container runtime.

One native macOS GUI. One CLI that doubles as docker and docker-compose. Zero gRPC. Zero NIO. Zero daemon of its own.

· · · ·

---

TL;DR

Macker replaces Docker Desktop on macOS by talking directly to Apple's apple/container runtime — no Docker daemon, no license, no Electron, no gRPC stack.

• Native SwiftUI GUI — Dashboard, Containers, Images, Builds, Volumes, Networks, Compose, Activity Monitor, Settings.
• Drop-in CLI — symlink the binary as docker and docker-compose.
• Custom Compose engine — ${VAR} interpolation, depends_on with service_healthy, service-name DNS, config-hash recreation.
• Hot reload — synthetic inotify bridge over virtiofs so Vite/webpack/nodemon rebuild on host edits.
• Menu bar extra — CPU/memory rings and per-container quick actions.

---

Screenshots

_{Dashboard — runtime status, resource cards, live CPU/Memory/Block I/O charts, and active containers.}

Containers & details

_{Containers — search & filter sidebar with running containers grouped by compose project.}

_{Container detail · Info — configuration, ports, mounts, and compose labels.}

_{Container detail · Settings — networks, published ports, resource limits, env vars, labels.}

Images · Builds · Volumes · Networks

_{Images — repository, tag, ID, size, creation date, and platform.}

_{Builds — empty state with Build and Prune cache actions.}

_{Volumes — name, driver, format, size, and created date.}

_{Networks — name, mode, subnet, and plugin.}

Compose · Activity Monitor · Settings · Menu bar

_{Compose — current compose file, services with mapped ports, Up/Down, and a logs panel.}

_{Activity Monitor — aggregate CPU/Memory/Containers/Network cards plus per-container usage.}

_{Settings · General — polling, launch at login, menu bar toggle, version, and install actions.}

_{Settings · Storage — disk usage breakdown and cleanup actions.}

_{Settings · Menu bar — visibility toggle, container list size, and metric customization.}

_{Menu bar extra — CPU/memory rings, per-project quick actions, and the Macker dropdown.}

---

Features

Native GUI	Docker-compatible CLI	Custom Compose engine
SwiftUI app — Dashboard, Containers, Images, Builds, Volumes, Networks, Compose, Activity Monitor, Settings.	One binary, two modes. Symlink it as docker and docker-compose for drop-in compatibility.	YAML parser, ${VAR} interpolation, .env support, topological depends_on with service_healthy gating.
Hot reload	Menu bar extra	Storage management
FSEvents → synthetic inotify bridge so Vite/webpack/nodemon rebuild on host edits over virtiofs.	CPU/memory rings, per-container quick actions, and customizable metrics.	Prune images, delete the buildkit builder, full cleanup — from GUI or CLI.

---

How it works

apple/container exposes a private XPC API (container-apiserver). Macker talks to it through a lightweight XPC client — no gRPC, no NIO, no daemon of its own. Operations that have no XPC route (image build, pull, push, tag, prune) fall back to the container CLI.

The single macker binary dispatches on its arguments:

Invocation	Mode
macker	Launches the SwiftUI GUI
macker <args>	Runs the headless CLI (ArgumentParser)

Read the full module map in docs/ARCHITECTURE.md.

---

Requirements

macOS	15+ (Sequoia or later)
CPU	Apple Silicon (arm64)
Runtime	apple/container installed and running (container-apiserver)
XPC protocol	pinned to 1.6.0 in Package.swift — client and runtime ship in lockstep
Runtime upgrade	Settings → Runtime shows the installed, recommended and latest container versions. The upgrade installs the recommended release after checking its SHA-256

---

Install

Option A — Homebrew (recommended)

brew install --cask djpfs/tools/macker

Installs the Macker.app bundle into /Applications (Launchpad/Spotlight discoverable). The cask lives in the homebrew-tools tap and points to the latest stable .pkg from GitHub Releases.

To use the CLI as a drop-in docker replacement, symlink the bundled binary:

ln -s /Applications/Macker.app/Contents/MacOS/macker /usr/local/bin/docker
ln -s /Applications/Macker.app/Contents/MacOS/macker /usr/local/bin/docker-compose

Option B — Install the CLI to your PATH

make install

This installs /usr/local/bin/macker. To use it as a drop-in docker replacement:

ln -s /usr/local/bin/macker /usr/local/bin/docker
ln -s /usr/local/bin/macker /usr/local/bin/docker-compose

The GUI also has a Settings → Install CLI button that does the same thing (with an administrator password prompt).

Option C — Install the app bundle

Build a .pkg installer and install it into /Applications:

./Scripts/build-pkg.sh 1.0.0
open dist/Macker-1.0.0.pkg

Or, from the GUI, use Settings → Install app in /Applications to copy the app bundle into /Applications.

Option D — Build from source

Clone and build:

git clone https://github.com/djpfs/macker.git
cd macker
make build          # debug build

---

Usage

GUI

macker

The GUI provides:

• Sidebar — Overview, Resources (with item counts), and System sections.
• Dashboard — resource cards, daemon status, and CPU/memory/I/O charts with configurable time intervals.
• Containers — list with search, All / Running / Stopped filter, sort, published-port badges, and memory use for running containers. The detail pane has Info / Stats / Logs / Terminal / Files / Settings tabs.
• Images — list, pull, and delete (with confirmation).
• Builds — build history, build an image from a context, retry failed builds, copy the build command, and prune the build cache.
• Volumes / Networks — create, inspect, and delete.
• Compose — load compose files (including drag & drop), up/down, logs, and per-project actions.
• Activity Monitor — per-container resource usage.
• Settings — appearance (System / Light / Dark), the container runtime section (installed, recommended and latest versions, with a one-click upgrade to the tested release), menu bar customization, storage cleanup, install CLI/app, launch at login, and more.

CLI

docker version
docker selftest
docker system status
docker ps
docker compose up -d

Some commands with the 1.6.0 runtime:

docker commit web myimage:1                        # container commit (needs REPOSITORY[:TAG])
docker run -d --network-alias api nginx            # DNS alias on the default network
docker network connect --alias api mynet web       # DNS alias on an existing network

docker commit does not support -a, -c or -m; they are refused with an error.

Docker compatibility

Because the binary is meant to be symlinked as docker, unknown top-level subcommands are transparently routed to the docker shim. So these are equivalent:

docker ps
macker ps

Registries, build and push

echo "$TOKEN" | docker login ghcr.io -u myuser --password-stdin   # password never in argv
docker login registry.local:5000 --scheme http -u ci --password-stdin
docker logout ghcr.io

docker build -t app:1 --target prod --platform linux/arm64 --label team=web \
  --secret id=token,src=$HOME/.npmrc --pull -f Dockerfile.dev .
docker build -t app:1 --no-cache .
docker tag app:1 registry.example.com/team/app:1
docker push registry.example.com/team/app:1

docker login reads the password from --password-stdin or a hidden prompt. Build caching is controlled with --no-cache and --pull. The 1.6.0 CLI has no cache-from/cache-to options, so cache import and export are not available yet.

Contexts and other daemons

docker context ls
docker context create colima --docker host=unix://$HOME/.colima/default/docker.sock
docker context use colima           # later commands go to Colima through its docker CLI
docker --context default ps         # one call on the local runtime
docker context rm colima

The default context is Macker's own runtime. Any other context sends the command, unchanged, to the docker CLI installed with that runtime (Docker Desktop, Colima and OrbStack ship one). Macker never uses itself for that.

Migrating from Docker Desktop, Colima or OrbStack

macker migrate --from colima --dry-run       # list images (and volumes with --volumes)
macker migrate --from colima                 # copy every image
macker migrate --from orbstack --volumes     # also copy named volumes, with contents
macker migrate --from docker-desktop --volumes --helper-image alpine:latest

Images are saved with the source's docker CLI and loaded with container image load. Named volumes are read and written with tar in a helper container (default alpine:latest, which must contain tar). Containers, compose projects, bind mounts and anonymous volumes are not moved; recreate them with docker compose up once the images and volumes are in place.

Compose extras

docker compose -f compose.yaml -f compose.prod.yaml up -d     # files are merged in order
COMPOSE_FILE=compose.yaml:compose.dev.yaml docker compose up -d
docker compose --profile debug up -d                            # or COMPOSE_PROFILES=debug
docker compose up -d --scale web=3                              # replicas: web-1, web-2, web-3
docker compose stop web                                         # acts on every replica

• Without -f, Macker uses compose.yaml (or docker-compose.yml) and its .override file when present.
• Services with profiles: run only when a matching profile is active.
• deploy.replicas sets the replica count when scale: and --scale are unset.
• configs: and secrets: with a file: source are mounted read-only at their target: (default /<name> for configs, /run/secrets/<name> for secrets).
• healthcheck: { disable: true } (or test: [NONE]) turns a healthcheck off.

Not yet supported in Compose: inline content: configs, environment-backed secrets, external configs and secrets, healthcheck status in ps, and the per-check timeout.

Full command reference — see docs/COMMANDS.md.

---

Documentation

Architecture	Layers, modules, and how they fit together
Supported commands	Full docker and docker compose reference
Compose engine & hot reload	How docker compose up works and the virtiofs inotify bridge
GUI features	Menu bar and storage & cleanup
Security	Security policy and notes
Contributing	Development setup, code style, testing, releasing
Roadmap & limitations	Known limitations and planned improvements

---

Security

• Privilege escalation: the Settings "Install CLI" and "Install app in /Applications" actions run osascript with administrator privileges. These are user-initiated and only copy the app's own binary into standard locations. See SECURITY.md.
• No secrets: the project contains no hardcoded credentials, API keys, or tokens. Do not commit .env files or firebase-adminsdk-*.json.
• Keychain-backed secrets: runtime secrets can be managed with docker secret ... and referenced as keychain://SECRET_NAME in KEY=VALUE environment entries.
• Shell safety: subprocesses are launched with argument arrays (not shell string interpolation), so command arguments are not shell-injected.

---

Contributing

Contributions are welcome — bug reports, feature requests, docs, and pull requests.

make build          # debug build
make test           # unit tests (needs full Xcode)
make release        # release build
make lint           # swift-format (if installed)
make guest-agent    # cross-compile the hot-reload agent
make clean          # remove build artifacts

Tests run in CI on macOS with full Xcode (XCTest is not shipped with CommandLineTools). The XPC protocol is not a stable public API — client and container-apiserver ship in lockstep. When updating the runtime, bump both containerVersion in Package.swift and RuntimeVersion.recommended in Sources/ContainerBackend/RuntimeVersion.swift.

Full guide — see docs/CONTRIBUTING.md.

---

License

MIT © 2026 macker contributors

_{Made for the Apple Silicon crowd that just wants containers to work.}