Isolation
Isolation is how the runtime runs untrusted code airtight. When an operation is a
code action — python, javascript, go-fn, ruby, and the rest of the actions
category — the code is yours, but to the platform it is untrusted: it can loop
forever, try to read a file it should not, or try to open a socket to the outside
world. Isolation lets it compute anything while reaching nothing it should not. This
page is the runtime’s reference entry; the concept that teaches the model is
isolation.
A real machine, not a wrapper
Code actions do not run in the physics process. They run in a Firecracker
microVM on the isolation fleet — a hardware-virtualized guest with its own kernel,
filesystem, and network namespace, scheduled by the isolation-executor (the
isolator/ crate). Physics hands the code, inputs, and a language tag to the executor
over HTTP and waits for a structured result. The virtualization is the security
boundary, and it is a hardware one: a bug or an escape attempt in your code is
contained by the CPU’s virtualization extensions, not by a language sandbox a payload
could talk its way out of.
A locked-down network and cheap fresh machines
Two properties make the boundary trustworthy and affordable:
- No egress for code sandboxes. The network posture is default-deny, and the
code-action sandboxes run with no internet egress — untrusted code can spin the
CPU and parse its inputs but cannot phone home, so a leaked secret has nowhere to
go. This is the compute-side mirror of the schema wall that keeps a circle’s data
airtight. (The same isolation fleet also hosts browser microVMs for the
chromeless/user-browsertools, and those are granted broad outbound egress on purpose — a real browser has to reach the open web. Egress is therefore a property of the workload, not of “isolation” as a blanket: code sandboxes get none, browser guests get the internet.) - Snapshot restore. Booting a VM per operation would be slow, so the executor keeps a golden per-language microVM image and restores from it on demand — a restore lands in roughly 30 milliseconds (closer to ~20 ms when the snapshot carries a dependency volume), versus the hundreds a full boot would cost. That economy is what lets every run get its own pristine machine instead of recycling a shared one.
The guest runs your code under a per-request timeout and returns the result (or a
structured error) over a Vsock channel — an in-host IPC link, not a network socket, so
the no-egress guarantee holds even for the control path. Captured stdout/stderr
forwards to SigNoz, trace-correlated to the run’s span.
Where isolation applies
The microVM sandbox is what the runtime reaches for whenever it must run something it
cannot trust in-process. The primary case is the actions category — python,
javascript, and the rest, where the code is yours. The browser tools
(chromeless, user-browser) run in the same Firecracker fleet, for the same
reason: a real browser driving arbitrary sites is untrusted execution too (those
guests get egress, as above; the code sandboxes do not). Other operations have their
own boundaries instead — an intelligence call goes through the LLM gateway, a data
query runs against the circle’s own Postgres schema, an io element calls out through
its own vetted client. So isolation is not “the actions category and nothing else”;
it is the substrate the runtime dispatches to whenever the
thing being run is untrusted code, whether that is your action or a browser session.
Related
- Concept: isolation — the full model (the teaching home)
- Concept: tenancy-airtight — the data-side wall isolation mirrors
- Pillar: Runtime — the executor that dispatches code actions here