Your CI runs untrusted code. Where?
Every deploy tool runs code from your repo — and its dependencies — on a machine. YakDeploy isolates build steps by default, across five operating systems, with VM-grade separation. Nobody else does this on your own hardware.
Isolation, per OS, by default
| OS | Default isolation |
|---|---|
| Linux | Hardened Docker — all capabilities dropped, no-new-privileges, read-only rootfs + tmpfs, pids-limit, no swap, socket never mounted |
| OpenBSD | vmm — an ephemeral VM per build |
| FreeBSD | bhyve VM (its own guest kernel); jails a lighter opt-in |
| macOS | Tart VM on Apple Silicon |
| Windows | Windows containers |
Customer-authored commands on managed runners never run bare — if the isolation runtime is missing, the job errors rather than silently degrading. Self-hosted runners may opt into bare execution per runner, explicitly. Every step run records which mechanism executed it; you'll see the badge on the deployment page.
Signed, self-updating agents
Runner releases are ed25519-signed; runners pin the key on first use (TOFU) and refuse a changed key. The server only instructs an update it can sign — no seed, no update.
Secrets & access
- Variables, cloud credentials, and runbook parameters are encrypted at rest.
- Known secret values are masked before logs are stored or forwarded. Avoid printing transformed or encoded secrets, which cannot be identified reliably.
- Role-based access (admin / deployer / viewer) with per-environment deploy scope and secret-visibility gating, enforced across the UI, REST, and MCP.
- Every deploy, approval, config change, and token mint is on an append-only audit trail.
Network posture
For targets behind your firewall, run a self-hosted runner inside your network — probes and deploys originate from it, so your machines never need inbound access from our cloud. Cloud credentials use OIDC federation (short-lived tokens, no stored long-lived keys) wherever the provider supports it.