Every run on this server says how strongly it was contained. This page says what that means here, right now — without a credential, because a claim about isolation is worth nothing if you have to be trusted to read it.
Asking the engine…
--network none unless the runtime has been given egress on purpose — and then only to the
hosts it lists. This is why data is sent with the call and packages are baked in at build time.
Read-only root filesystem, with two tmpfs mounts: the workspace and /tmp. Both are sized, both
are nosuid,nodev, and both vanish when the container stops.
Every Linux capability dropped, no-new-privileges set, running as an unprivileged user. Memory
and swap capped together — capping only memory makes a container swap instead of stopping.
The server’s own environment is scrubbed. A run gets its runtime’s variables and the secrets it is entitled to, and nothing else — no database URL, no provider keys.
The interpreter stops itself just before the outer kill, which is how an overrun still reports what it printed. CPU, address space, file size and process count are capped inside as well as out.
The job goes in on stdin and the answer comes out on stdout. No volumes, no bind mounts, nothing staged on the host — which is also what lets the engine live on another machine entirely.
With no engine reachable, a deployment can be told to run code as a plain child process instead. That is useful on a laptop and is not a sandbox: there is no kernel boundary, no filesystem it cannot read, and on a machine with a network, no network policy. Only the limits the interpreter sets on itself apply.
It is off by default anywhere that looks like a hosting platform, and has to be turned on in as many words with
CRUCIBLE_ALLOW_PROCESS_ISOLATION=true. When it is on, every run is stamped
isolation: "process" in the record and carries a warning in its reply. It is never a silent
downgrade — a caller who asks for a container and cannot have one gets an error, not a substitute.