Orchard: a native macOS front end for Apple Containers and MLX sandboxes

A desktop app for a CLI-first container runtime

Apple's container tooling is a command-line interface, and Orchard's stated job is to be the desktop experience that complements it rather than replaces it. The repository description frames the goal directly: a native UI written in Swift as a replacement for the desktop GUI people used on other runtimes.

What Orchard manages is broader than containers alone. There are persistent container machines, which are stateful Linux VMs with their own CPU, memory, home-mount and kernel settings. There are local Kubernetes clusters built on the k8s plugin that ships with newer versions of the runtime. There are compose projects, and there is a local AI view for models served on the same Mac.

The audience is narrow and the project is honest about it: developers on Apple silicon or Intel Macs who have chosen Apple's container runtime and now want the monitoring, log reading and one-click actions that a terminal makes tedious. Orchard never claims to be a workflow replacement. In the Kubernetes section it says deploying workloads stays with kubectl, k9s and Lens, and that it hands you a configured context and gets out of the way. That boundary is a design decision, not a missing feature.

Machines over XPC, not over a shell

One implementation detail separates Orchard from a wrapper script with buttons. Machines are driven over Apple's native XPC API through a component named MachineAPIClient, rather than by invoking the `container` binary and parsing its output. That means machine creation, start, stop, set-default and delete all go through a structured interface, and the app can present a live configuration editor with a single stop, apply and restart action rather than a sequence of commands the user assembles.

Configuration is not a fixed form. Machines can be created from any image that ships an init system, and the editor exposes CPU, memory, home-mount, nested virtualization and a custom kernel option. Live CPU, memory, network and disk figures appear in the machine view and roll up into the system-wide dashboard.

The guardrails are the part worth trusting. Orchard warns before you create a machine from an image with no init system, and when a machine later stops for that reason the app explains why instead of leaving you reading logs. Output and boot logs land in the same multi-pane viewer used for containers, so there is one place to look.

Sandboxes: an agent behind a VM boundary with a local endpoint

The Local AI section is where Orchard stops being a container viewer. Inference runs on the Mac's own GPU because container VMs have no GPU access, and the app bridges that gap by computing the container-reachable endpoint from the network gateway and injecting `OPENAI_BASE_URL` into the container when it is created. The result is that code inside the container talks to your local model with the ordinary OpenAI SDK, with no hand-written networking.

The reasoning behind the sandbox view is a security argument rather than a convenience one. An agent with an API key has a credential it can leak; an agent pointed at a local endpoint sits behind a hypervisor boundary. The view makes that boundary visible: each container wired to a model carries an isolation badge distinguishing host-only from internet-open, and there are chat and terminal controls plus a kill-switch next to it.

On the model side, Orchard discovers servers you already run, naming Ollama, LM Studio and MLX servers, and can start and stop `mlx_lm.server` instances itself with process supervision, crash surfacing and logs. An in-app chat tester verifies any server without leaving the app. The last piece matters for adoption: an endpoint injection that happens at create time means a container started before the model was wired will not have the variable, and there is no mention of a way to patch it into a running container.

Compose projects discovered by label, not by a file

Compose handling is where most GUI container tools quietly diverge from the CLI, and Orchard makes a specific choice here. Projects are found by the labels on their containers rather than by a compose file the app keeps track of, so a stack you brought up in the terminal shows up in the app with no import step.

The second `up` is not a blind re-create. Each service is compared against a hash stamped on the container it produced, and the app decides per service whether to create, start, leave alone, recreate or remove, listing every step as it happens. That is the behaviour you would write by hand with careful scripting, and seeing the steps enumerated is the argument for having a GUI at all.

Each service shows its container, IP address and hostname next to the networks the project created, and a service with a build goes through the same path as the Images tab, so its BuildKit log lands under Builds.

There is a Problems tab that lists unhandled keys grouped by cause, separating keys the runtime makes impossible from keys that are not built yet.

Local Kubernetes through the k8s plugin, then hands you kubectl

Cluster support requires the runtime's k8s plugin, and the README is precise about the version: container 1.2.2 or later. Installations without the plugin get an explanatory state with upgrade guidance rather than an empty screen, which is the right failure mode.

When the plugin is present, node containers are grouped into named clusters and the nodes table shows role, status, IP, CPUs, memory and published ports. You can create a cluster from the app by choosing the Kubernetes version, resource overrides and optionally your own CNI manifest, and delete it again.

Two details carry most of the practical weight. Local images can be loaded straight into the cluster's containerd, so a pod can use something you just built without pushing it to a registry. And kubeconfig is handled three ways: write or merge the cluster's context into your kubeconfig, copy its path, or open a terminal with the context already selected.

Cluster nodes are badged in the main containers list, for example `k8s · control-plane`, and the container view and cluster view cross-link. The README is explicit that deployment stays with kubectl, k9s or Lens.

Installing and getting a first look at the dashboard

The short version of installation is one command, and the README puts it at the top before anything else:

brew install orchard

It links the other install options, covering a release download and building from source. The project page is at orchard.andon.dev, and the documentation there includes separate guides for local AI, container machines and Kubernetes clusters.

The first screen you land on is the dashboard, which shows system-wide resource usage across every container. From there the useful loop is: create a machine, start it, open the log viewer, then run a compose project and watch the Problems tab tell you which keys it ignored.

To see the AI path end to end, the workflow the documentation describes is to discover or start a model server, create a container, and let Orchard inject the endpoint so that client code using the OpenAI SDK reaches the local model.

What is missing, and what the README does not say

The gaps are mostly at the seams between versions of the runtime, and they are worth knowing before you commit. Kubernetes features need container 1.2.2 or later, so older installs show an explanatory state and upgrade guidance. And because endpoint injection happens at create time, containers created before a model was configured will not have `OPENAI_BASE_URL`, and the README does not document a re-injection command.

Nothing here is about Docker, and that is the point. Orchard's runtime is Apple's, with its own VM isolation model, its own containerd-based image handling and its own plugin set. Orchard is built around Apple's container tooling, and local images can be loaded into a cluster's containerd.

The project publishes a CI badge, a services coverage badge served from its own site, an ADOPTERS.md, a SECURITY.md, a CHANGELOG and a CONTRIBUTING.md. The license is MIT. Orchard is under active development with frequent releases: the last push was on 2026-10-14, and v2.5.2, v2.5.1 and v2.5.0 landed on 2026-10-14, 2026-10-05 and 2026-09-30.

Editorial conclusion

Orchard fits developers who already committed to Apple's container runtime and want machines, sandboxes and compose projects without memorising the CLI, and it earns that role because it drives machines over MachineAPIClient rather than by shelling out. It is a macOS app built around Apple's container tooling. Before installing, check two things: that your `container` install is new enough for the features you want, since Kubernetes clusters need container 1.2.2 or later for the k8s plugin and older installs get an explanatory state instead of a cluster view, and that you are comfortable with the app inserting OPENAI_BASE_URL into containers at create time, since a container built before that injection will not reach your local model. The MIT license and a CI badge backed by a services coverage endpoint make fork-and-patch a realistic option; the last push was on 2026-10-14 and v2.5.2 shipped the same day.

Frequently asked questions

Official sources

1. andrew-waters/orchard on GitHub
2. License: MIT
3. Project website
4. README
5. Releases