Runners

Runners execute your steps. Managed runners (Linux/OpenBSD) work out of the box; self-hosted runners put builds and deploys on your own machines — the recommended setup when your targets live behind a firewall, since probes and deploys originate from the runner.

Install

Runners → New runner mints a one-time token and shows the install command for each distribution:

• Script — self-updating (signed, key-pinned), needs Elixir on the host.
• Binary — self-contained (no runtime needed), systemd unit included.
• Docker / Helm — container image, or the Helm chart for Kubernetes with optional KEDA scale-to-zero on queue depth.

Isolation

Build steps run isolated by default — hardened docker on Linux (all capabilities dropped, read-only rootfs), vmm on OpenBSD, bhyve on FreeBSD (jails as a lighter opt-in), Tart VMs on macOS, Windows containers on Windows. Self-hosted runners may opt into bare execution per runner; managed runners never run bare.

SSH access

Deploy steps (and target connectivity probes) SSH from the runner using its own keys — the web tier never holds your machine credentials. Add the runner's public key to each target user's ~/.ssh/authorized_keys.