Skip to main content
The security boundary for untrusted generated code is gVisor (runsc) running on a Linux host you provision. Everything on this page is about standing that host up correctly. Local development and building use WSL2 and Docker Desktop, but the real sandbox needs this host. For the exact commands and the acceptance tests, follow the repo runbooks; this page is the map.
Plain Docker (runc) and Docker Desktop are not the boundary. Docker Desktop cannot even register runsc. If you run generated code under runc, you have no isolation boundary, only a container. Do not treat that as safe.

​
Host requirements

1

A Linux host with nested virtualization

gVisor needs it. Docker Engine and runsc must be installed and runsc registered in /etc/docker/daemon.json (systrap platform). Set UTTER_SANDBOX_HOST=1.
2

Quota-capable storage

overlay2 on xfs with pquota, so disk caps are actually enforced per container.
3

A host egress firewall

The data proxy is deny-by-default, but the host itself needs a firewall as the outer layer.
4

An internal package registry mirror

Verdaccio (REGISTRY_MIRROR_URL) so builds install from a mirror with no network access to the public internet.
5

A wildcard TLS domain

*.resources.<domain>, issued via DNS-01. See below.

​
Wildcard TLS

Every deployed endpoint lives at https://<slug>.resources.<DEPLOY_DOMAIN>, so the host needs a wildcard certificate for *.resources.<domain>.
Let’s Encrypt refuses wildcards over HTTP-01. The certificate must be issued via DNS-01, which means your DNS provider’s credentials go in .env.local (gitignored, never committed).

​
Durability

Persistence is Postgres and Redis:
  • Postgres via DATABASE_URL. Load infrastructure/db/schema.sql once.
  • Redis via REDIS_URL.
With NODE_ENV=production the services fail closed: boot throws unless durability is configured. This is intentional. A production deploy without persistence would silently lose settlement state, so it is not allowed to start.

​
The systemd deployer

The deployer runs on the host as a supervised systemd service (infrastructure/systemd/utter-deployer.service). It needs the host Docker daemon and runsc, which is why it is not a compose service. The trusted control-plane services run in compose; the deployer runs on the metal next to the daemon it drives.

​
Follow the runbooks

The exact commands, and the three live acceptance tests that prove the host is real, live in the repo. Do not rely on this page for the specifics.
The three live acceptance tests are the gate: malicious-probe-blocked (a probe cannot reach the network or secrets), runsc-enforced caps (resource and disk caps hold under runsc), and a live 402 to 200 deploy (a real endpoint takes a real payment). If any of the three fails, the host is not ready.

The sandbox

What runsc is isolating, and why plain Docker is not enough.

Self-hosting the stack

The practical run shape once the host is provisioned.