Backends

Install Apple Container support

Install, discover and diagnose the optional Apple Container 1.3 driver package.

The Apple Container backend is not a prerequisite for Maelys Warden. The core package runs native workloads with Seatbelt and contains no Swift runtime or driver.

CODE
maelys-warden                        optional component
├── C runtime                        maelys-warden-apple-container-driver
├── Seatbelt                         └── ad-hoc-signed arm64 Swift driver
├── Egress                                      │
└── CLI                                       ▼
                                      Apple Container 1.3.0

Installation modes

For normal Seatbelt execution, install only Warden:

CODE
brew install maelys-dev/tap/maelys-warden
maelys-warden run --ro -- /usr/bin/true

For OCI workloads in Apple lightweight VMs, first install and configure Apple Container 1.3.0 following its official instructions, then install the optional Warden component:

CODE
brew install maelys-dev/tap/maelys-warden-apple-container-driver

This formula downloads the release-built macOS-arm64 artifact. It does not run Swift, Xcode or make. The installed requirements.json records the exact Apple Container version, SHA-256 of the driver and guest-bundle manifest digest.

Discovery

maelys_executor_create_default() searches only trusted product locations, in this order:

  1. the absolute MAELYS_APPLE_CONTAINER_DRIVER host override, when explicitly set;
  2. ../libexec/maelys-warden-apple-container-driver beside the running executable;
  3. the stable Apple Silicon Homebrew opt path;
  4. /usr/local/libexec and /opt/maelys/libexec.

The override is trusted host configuration, not a workload variable. Relative paths are rejected. Registration requires a canonical executable regular file, owned by root or the current user and not writable by group/other. Warden pins device, inode and SHA-256 and checks them again across probe, prepare and spawn.

Automatic discovery registers apple-container. It also registers apple-container-bubblewrap when the packaged guest bundle beside the driver passes its ownership, mode, ELF and digest checks. The CLI selects either candidate for an explicit --image REFERENCE@sha256:DIGEST target; the same contract is available through the Executor RunSpec C API.

Absence and failure

No optional driver installed:

CODE
local TargetSpec ──► Seatbelt normally
OCI TargetSpec   ──► no eligible Apple candidate

Driver installed but Apple Container absent or not configured:

CODE
driver probe exits 78
       │
       ▼
MAELYS_EXECUTOR_ERR_UNSUPPORTED
capabilities = 0
no prepare, no spawn, no fallback

An invalid explicit override fails executor creation loudly. A missing implicit installation is simply treated as an unavailable optional candidate, so it can never break ordinary Seatbelt execution.

Building from source

Only maintainers and source builders need Xcode and Swift 6.2:

CODE
make apple-driver-check

The Apple Silicon linker produces an ad-hoc code signature. Release packaging verifies that signature before running scripts/package-apple-container-driver.sh; the script rejects an invalidly signed or non-arm64 driver. A Developer ID is not required, consistently with the main Warden macOS executable. End users never perform these steps.