Isolation
The first wall is the same everywhere: the guest is an emulated machine whose only ways out are its terminal, its files and, if the site has one, the network relay. Guest code never runs as host code.
| Browser | Native | Docker | |
|---|---|---|---|
| Around the emulator | the browser's renderer sandbox | no_new_privs, Landlock and seccomp on Linux; Seatbelt on macOS | read-only root, no capabilities, memory and pid limits |
| Host files | none | reads the site; writes its cache, socket, logs and a job's workspace | the site, read-only; logs if given |
| New processes | none possible | refused | inside the container only |
| Network | the page's fetch() and WebSocket | out the way your machine goes; private addresses off | the same, from the container |
| Needs | a browser | nothing (Linux or macOS) | Docker |
The native sandbox is strongest on Linux with Landlock (kernel 5.13 or later). A run says which parts it
got; SNOWGLOBE_SANDBOX=strict refuses to run without all of them, and
snowglobe-vm sandbox-check tries what a run must not be able to do and reports each.
Native runs of one site share its snapshot's memory: the first run writes it to the cache as a
read-only image (in ram/, which only you can open), and every run maps it copy-on-write. A page
a machine writes becomes its own, so one machine never sees another's memory, and each restore gets fresh
randomness (the guest kernel reseeds on it). The image is named by a hash of the whole snapshot and checked
before use (yours, read-only, one link); anything off and the run restores the usual way.
SNOWGLOBE_RAM_IMAGE=off always does.
What none of them do: hide a site's contents from whoever runs it (the snapshot is theirs to read), or make network access safe beyond the rules above. Give a guest a network only when the work needs it.