Why Hostwright

Hostwright exists because of a specific change in the Mac development landscape, and because of a gap that change leaves open.

Apple container is a new runtime surface

For years, running Linux containers on a Mac meant a shared Linux VM managed by a third-party tool. Apple container changes the substrate: it is Mac-native, built for Apple silicon, and uses a lightweight VM per container with an OCI image flow.

A runtime is not a workflow. Apple container can start and stop containers; it does not, by itself, declare a multi-service stack, validate it, converge to it, or report drift.

Local desired-state control is the missing layer

Without a control layer, a local stack is a set of imperative commands and an operator’s memory of what should be running. A desired-state layer records that model instead:

• The stack is declared once.
• Changes are planned before they run.
• Drift between declared and observed state is detected and reported.
• Cleanup is ownership-checked.

This is the layer Hostwright provides. It uses a local control loop without claiming Kubernetes behavior or compatibility.

Why single-host first

A single Mac is the environment the v0.0.2 release targets. Multi-Mac membership, remote control, and cross-host scheduling are outside that release scope.

Why Swift

The runtime substrate is Apple-native, so the control plane is too. Swift gives Hostwright access to macOS facilities such as the Keychain, process control, and SQLite. The runtime provider boundary supports both the Apple container CLI and a separate Containerization helper.

Why the RuntimeAdapter is the core boundary

The single most important design decision is to route runtime observation and effects through one typed provider boundary, the Runtime Provider API. Providers expose only their declared capabilities; unsupported effects fail before mutation.