ShibaStack
A native, Docker-free container manager for Apple Silicon, built on Apple's own container runtime.
Project Brief
- Role
- Solo macOS and systems developer
- Scope
- A native SwiftUI dashboard, menu-bar app, and CLI for managing Apple Silicon containers on Apple's own container runtime, with a Docker-compatible networking and registry layer
- Timeline
- Built across four releases (v0.1.0 branded dashboard through v0.4.0 honest-errors pass) in 2026
- Result
- A Docker-daemon-free container manager with a complete build/tag/push/pull registry workflow and an explicit no-silent-failure UI standard
Evidence Included
Real OCI containers, not a simulation
Every container, image, and volume operation is driven live through Apple's `container` CLI — nothing in the dashboard is mocked or placeholder data.
Honest status over optimistic UI
An unreachable container engine, a failed create, or a failed registry push each surface their real error state rather than a generic or silently-swallowed failure.
Complete registry workflow
Build from a Dockerfile, tag, push, pull, and authenticated login/logout are all implemented and versioned as a dedicated v0.3.0 release.
Swift + Go
Languages
Zero-sudo
Privilege model
Docker CLI/API
Compatibility
v0.1.0 → v0.4.0
Releases shipped
ShibaStack is a macOS app and CLI suite for managing Linux containers on Apple Silicon using Apple's native `container` runtime — no Docker daemon required. It pairs a polished SwiftUI dashboard and menu-bar app with a zero-privilege, user-space networking layer that gives every container a friendly local domain, plus a Docker-API-compatible socket so existing Docker tooling can talk to the Apple container engine. Beyond the initial dashboard, it grew through three functional releases: image builds from a Dockerfile, a full registry workflow (tag, push, pull, authenticated login), and a pass dedicated entirely to replacing optimistic UI states with honest ones — every mutating operation now either succeeds visibly or surfaces the real error, with no silent failures presented as success.
Highlights
- Native SwiftUI dashboard and menu-bar app for managing containers, images, and volumes
- Live per-container CPU/memory metrics and streaming logs, backed by real system data
- Zero-privilege user-space DNS resolver and reverse proxy — no root/sudo required
- Docker-CLI compatibility layer that bridges standard Docker tooling to Apple's container runtime
- Full image registry workflow — build from a Dockerfile, tag, push, and pull, with authenticated login/logout (password piped via stdin, never stored in shell history or config)
- Run a container directly from an image in the dashboard, with prefilled run configuration derived from the image's own metadata
- Honest-failure pass across every mutating operation — create, run, and registry actions surface the real underlying error instead of a generic or silently-swallowed failure, and the dashboard shows an explicit "container engine not running" state instead of presenting an empty list as if there were simply nothing to show
- Copy Run Command, Force Kill, and Copy ID actions added to the container list, plus edge-case test coverage locking down image-reference stripping and host-port parsing
- Collapsed a refresh subprocess storm that was spawning redundant background processes on every UI refresh tick, hardening runtime behavior under the dashboard's live-polling model
- Multi-language stack: Swift (SwiftUI + Swift Package Manager) for the app/CLI/daemon, Go for the networking layer and guest agent
Architecture & Infrastructure
Native SwiftUI app over Apple's container runtime
The dashboard, menu-bar app, and `apc` CLI are all Swift, built against Apple's own `container` binary rather than a Docker daemon. `apc-core` centralizes container, VM, USB, and VSOCK management behind one Swift package shared by the CLI and the GUI.
Zero-privilege user-space networking
A Go component (`apc-network`) runs a user-space DNS resolver and HTTP reverse proxy giving every container a friendly local domain, plus a routing registry — all without requiring root or sudo, unlike a typical Docker Desktop-style network bridge.
Docker-API compatibility bridge
A `docker.sock`-compatible bridge translates standard Docker API calls into Apple `container` commands, so existing Docker-aware tooling can point at the Apple engine without modification — the only place "Docker" appears in the stack is this translation layer and the default `docker.io` registry hostname; there is no Docker daemon anywhere.
Registry workflow: build, tag, push, pull
Images can be built directly from a Dockerfile via `container build`, then tagged and pushed to a registry, with authenticated login/logout that pipes the password over stdin rather than a command-line argument or a stored config file — completing the loop from local build to shared registry image.
Honest-failure design discipline
A dedicated pass replaced every silent or optimistic UI state with an explicit one: mutating operations that fail now surface the real underlying error instead of failing quietly, and an unreachable container engine is reported as unreachable rather than rendered as an empty, misleadingly-normal container list.