brew install orchardOrchard is a native (Swift) macOS application for managing containers, machines and local AI models using Apple's container tooling.
It gives you a desktop experience that complements the container command-line interface.
Thousands of installations and starred by engineers from Apple, Microsoft, NVIDIA, IBM, Stripe, Cisco, LinkedIn, Uber, Vercel & more - see who's adopting Orchard
- Local AI & Sandboxes
- Container Machines
- Benefits of Apple Containers
- Orchard Features
- How Orchard compares
- Requirements
- Architecture
- Installation
- Adoption
- Star History
- License
Orchard wires local MLX models into Apple containers. Inference runs on your Mac's GPU (container VMs have no GPU access) and containers reach it with no hand-configured networking.
- Discover model servers already on your Mac (Ollama, LM Studio, MLX servers), or start and stop
mlx_lm.serverinstances from the app - with process supervision, crash surfacing and logs - The container↔model bridge: Orchard computes the container-reachable endpoint from the network gateway and injects
OPENAI_BASE_URLat create time, so containerised apps just use the OpenAI SDK - Sandboxes: a first-class view of containers wired to a local model - isolation badge (host-only vs internet-open), chat and terminal access, and a kill-switch. Run an agent behind a hypervisor boundary with a local endpoint instead of an API key it could leak
- An in-app chat tester to verify any model server without leaving the app
See the Local AI guide for a full walkthrough and a runnable quick start.
Orchard manages Apple container machines natively: persistent, stateful Linux VMs you can create, configure, run and monitor without leaving the app or dropping to the CLI.
- Create machines from any init-capable image, with CPU, memory, home-mount, nested-virtualization and custom-kernel options
- Start, stop, set-default and delete, plus a one-click stop / apply / restart configuration editor
- Live CPU, memory, network and disk usage, in the machine view and on the dashboard
- Output and boot logs in the same multi-pane log viewer as containers
- Guardrails that warn before creating from an image with no init system, and explain a machine that stopped because of it
Machines are driven over Apple's native XPC API (MachineAPIClient), not by shelling out. See the Container Machines guide for a full walkthrough and the pitfalls to avoid.
Orchard manages local Kubernetes clusters built on Apple container's k8s plugin (container 1.2.2+): cluster nodes are grouped, inspectable and one click from a working kubectl.
- Node containers are grouped into named clusters, with per-node role, status, IP, CPUs, memory and published ports
- Create (with resource overrides and a custom node image), start and delete clusters from the app
- Load any local image into the cluster's containerd, so pods can use it without a registry
- Write or merge the cluster's context into your kubeconfig, copy its path, or open a terminal with the kubectl context already selected
- Cluster nodes are badged in the containers list ("k8s · control-plane"), and container and cluster views cross-link both ways
- Installs without the k8s plugin get an explanatory state with upgrade guidance
Deploying workloads stays with the tools you know - kubectl, k9s, Lens - Orchard hands you a configured context and gets out of the way. See the Kubernetes Clusters guide for a walkthrough.
- Native support, incredible performance and the engineering resources to make it work.
- Sub second startup times
- Kernel isolation by design
- Easier networking - no more port mapping (every container gets its own IP address), networks out of the box
- Command palette: press Cmd+K to fuzzy-search everything Orchard manages, jump to any resource, or run actions from the keyboard - "stop db", "logs api", "console web"
- Local AI: discover or run MLX model servers, bridge containers to them, and manage agent sandboxes with isolation badges and a kill-switch
- Container machines: create, configure, run and monitor persistent Linux VMs over native XPC
- Kubernetes clusters: create and manage local k8s clusters (container's k8s plugin), load images into them, and get one-click kubectl access
- Container management: create, start, stop, force stop, delete
- Image management: pull, delete, search Docker Hub
- Network and DNS domain management
- Real-time container stats with sortable columns
- Sortable container and image lists with persistent preferences
- Multi-container log viewer with split panes, filtering, and per-container colour coding
- Container log viewer with search highlighting
- Builder, kernel and system property management
- Menu bar integration
Press Cmd+K anywhere and type: results rank with real fuzzy matching across containers, images, mounts, machines, k8s clusters, AI models, sandboxes, DNS domains and networks. Verbs work too - "stop db" stops the container, "logs api" opens the log viewer, "console web" drops you into a shell - and the actions section covers running containers, pulling images, and starting or stopping the container system itself.
Per-container detail with CPU, memory, network and disk over time, cross-links to the cluster or sandbox a container belongs to, and one-click terminal and log access. (The system-wide dashboard above is the default view when the app opens, summing usage across every container with headline disk-usage tiles and live sparklines.)
Browse, pull, and delete container images. Search Docker Hub directly from the app and inspect image metadata without dropping to the CLI.
Stream logs from multiple containers side by side. Split panes, filter by text, and use per-container colour coding to keep output readable when debugging across services.
Manage networks and DNS domains without touching the CLI - see every container's IP address and hostname at a glance, set the default DNS domain, and create or remove domains and networks.
Keep an eye on things from the menu bar: CPU and memory usage rings across all running containers, a per-container list with start/stop controls, and one-click access back to the app.
Orchard isn't the only way to work with Apple's container runtime:
| Capability | Orchard | Podman Desktop | container CLI |
|---|---|---|---|
Purpose-built for apple/container |
✅ | ➖ 1 | ✅ |
| Native macOS app | ✅ 2 | ❌ 3 | ❌ |
| Native XPC integration (no CLI shelling) | ✅ | ❌ 4 | ✅ |
| Container machines (native XPC) | ✅ | ❌ | ✅ |
Kubernetes clusters on apple/container |
✅ | ❌ | ✅ |
| Local AI models & agent sandboxes | ✅ | ❌ | ❌ |
| Command palette (fuzzy search + actions) | ✅ | ➖ 9 | ❌ |
| Signed & notarized | ✅ | ✅ | ✅ |
| Multi-pane log viewer | ✅ | ➖ | ➖ 5 |
| Live container stats (CPU/mem/net/disk) | ✅ | ✅ | ➖ |
| Network, DNS & builder management | ✅ | ➖ | ✅ |
| Focused, lightweight footprint | ✅ | ❌ 6 | ✅ |
| Open source | ✅ 7 | ✅ 8 | ✅ 8 |
✅ full support · ➖ partial or indirect · ❌ not available
- Supported through a community extension, not natively.
- Native Swift / SwiftUI.
- Built on Electron.
- Talks to a Docker-API shim rather than the native XPC API.
- Terminal output only - no multi-pane viewer.
- General-purpose, multi-runtime tool.
- MIT licensed.
- Apache-2.0 licensed.
- The F1 command palette covers commands and navigation; no fuzzy resource search with per-resource actions.
Orchard is the native, purpose-built choice: a lightweight Swift app focused solely on giving Apple's container a first-class desktop experience, rather than a heavyweight cross-platform tool that supports it as one runtime among many. (Note: OrbStack and Docker Desktop are separate container runtimes and don't manage apple/container - see Choosing a runtime below.)
Being native goes beyond the UI: Orchard talks to the container daemon over the same typed XPC API the container CLI uses internally, rather than spawning the CLI and parsing its output. That means structured data instead of screen-scraping (no breakage when CLI wording changes), no child processes on every refresh, real log streams feeding the multi-pane viewer, and typed errors instead of exit codes.
The table above compares apps that manage Apple's container runtime. OrbStack and Docker Desktop are a different decision: they're separate container runtimes with their own apps. If you're choosing a stack rather than a frontend:
Orchard + apple/container |
OrbStack | Docker Desktop | |
|---|---|---|---|
| Isolation model | VM per container | Shared VM & kernel 1 | Shared VM & kernel |
| Built on Apple's Virtualization.framework | ✅ | ➖ 2 | ❌ |
| Native macOS app | ✅ | ✅ | ❌ 3 |
| Docker API & ecosystem compatibility | ➖ 4 | ✅ | ✅ |
| Kubernetes | ✅ multi-node 5 | ➖ single-node | ➖ single-node |
| Local AI models & agent sandboxes | ✅ | ❌ | ➖ 6 |
| Free for commercial use | ✅ | ❌ 7 | ➖ 8 |
| Open source | ✅ MIT + Apache-2.0 | ❌ 9 | ➖ 10 |
- All containers share one Linux VM and kernel; OrbStack's docs note its isolated machines are "not a substitute for a full VM against actively malicious code."
- Native Swift app, but on a custom proprietary virtualization stack.
- The Docker Desktop dashboard is built on Electron.
- Runs standard OCI images; does not expose a Docker-compatible API socket.
- Experimental, via the
container k8splugin (control plane + workers). - Docker Model Runner runs local models; no agent-sandbox workflow.
- Free for personal, non-commercial use; commercial use requires Pro ($8/user/month).
- Free only for personal use, education, and companies under 250 employees and $10M annual revenue.
- Closed-source core with some open-source components.
- Engine, CLI, and Compose are Apache-2.0; Docker Desktop itself is proprietary.
Different trade-offs, honestly stated: OrbStack and Docker Desktop win on Docker ecosystem compatibility today. Orchard's stack wins on isolation, openness, and being built the way Apple builds things.
- macOS 26 (Tahoe)
- Xcode 26 / Swift 6.2 (for building from source)
- Apple Container installed - follow the instructions here
Orchard communicates with the container daemon primarily through the ContainerAPIClient Swift library (from apple/container) over XPC - typed Swift APIs for containers, images, networks, stats, logs, and system health, with no CLI process spawning or output parsing on this path. Every operation the API exposes goes over XPC; the remaining CLI-backed operations are the exceptions noted below.
A small number of operations still use the container CLI via Foundation.Process, each for a structural reason rather than convenience: system start/stop/restart (the daemon is registered with launchd - there is nothing to XPC to until it's running), builder lifecycle (the API exposes no builder surface; the CLI orchestrates it client-side), system properties (a local defaults store, not an API), DNS domain create/delete (requires root, so it runs the CLI under administrator privileges), and kernel selection (installing the recommended kernel provisions it - an operation the API doesn't expose as a single call).
You can install Orchard via homebrew or via a prebuilt release package. You can also download the source and build it yourself!
Every release is code-signed with a registered Apple Developer ID and notarized by Apple, so it installs and launches cleanly with no Gatekeeper "unidentified developer" warning.
brew install orchard- Download the latest release from GitHub Releases
- Open the
.dmgfile and drag Orchard to your Applications folder - Launch Orchard from the Apps directory
git clone https://github.com/andrew-waters/orchard.git
cd orchard
open Orchard.xcodeprojThe project uses Swift Package Manager for dependencies. Xcode will resolve the apple/container package automatically on first build.
Orchard is installed hundreds of times a month via Homebrew - see the live install stats - and has been starred by engineers from Apple, Microsoft, NVIDIA, IBM, Stripe, Cisco, LinkedIn, Uber, GitHub, Red Hat, SUSE, Amazon, VMware, Siemens, Hitachi, Alibaba, Tencent, MongoDB, Honeycomb, Automattic, Vercel and across the wider cloud-native community.
Using Orchard at your company or in your day-to-day workflow? We'd love to hear about it - add yourself to ADOPTERS.md with a quick pull request.
This project is licensed under the MIT License - see the LICENSE file for details.