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`)

Architecture layers — Presentation, Service, Backend, Platform

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.2.2 in `Package.swift` — client and runtime ship in lockstep

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:

Dashboard — resource cards, daemon status, and CPU/memory/I/O charts with configurable time intervals.
Containers — list with search, start/stop/restart, and a detail pane with 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 — 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

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

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; bump containerVersion in Package.swift when updating the runtime.

Full guide — see docs/CONTRIBUTING.md.

License

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

FilesExpand file tree

README.md

Latest commit

History