Cloud Sandbox Glossary: 50 Terms From MicroVM to Zero Data Retention
Updated October 27, 2026 .md
Short answer: Short, exact definitions of 50 terms you meet when running code in a cloud sandbox, from microVM, KVM and Cloud Hypervisor to snapshot, fork, memory restore, idle pause, hosted port, sandbox token, MCP server and egress. General terms follow their official docs; Sandboxer terms describe how the product works today.
Terms are in alphabetical order. Each heading is a link target, so you can share /guides/sandbox-glossary#fork and land on that entry. Where a term is general, the definition is product-neutral. Where it says "on Sandboxer", it describes current behavior from our docs.
A–C#
API key#
A secret that authenticates a program (a backend, a CI job, an SDK) rather than a person. A Sandboxer key is sbx_live_ followed by 40 characters; only a hash is stored, and each key is limited to a set of actions and the sandboxes or environments it may touch. See API keys.
API key preset#
A named bundle of actions you pick when you create a key. Sandboxer has four: read-only, full-sandbox (operate existing sandboxes), ci (full-sandbox plus create, resume, fork and delete-own) and admin (everything). See presets.
Auto-stop (TTL)#
A time-to-live after which the platform stops a sandbox on its own. On Sandboxer the default is 1 hour, the maximum is 30 days, and --no-auto-stop turns it off; the stop keeps memory and disk, so sbx resume picks up where the job was. See auto-stop.
Cloud Hypervisor#
An open-source virtual machine monitor written in Rust that runs on KVM and the Microsoft Hypervisor and aims for minimal device emulation (README). Every Sandboxer sandbox is a Cloud Hypervisor microVM. Compare it in Firecracker vs Cloud Hypervisor.
Code interpreter#
A tool that lets a language model write code, run it and read back the output, often keeping variables between calls. The code needs somewhere isolated to run, which is usually a sandbox. Build one in a stateful code interpreter with Jupyter.
Cold boot#
Starting a VM from its disk through a fresh kernel boot, with no saved memory. On Sandboxer a cold boot keeps your files and starts enabled systemd services, but processes you started by hand are gone and /tmp is empty. See resume.
Computer use#
An agent controlling a graphical desktop by taking screenshots and sending mouse and keyboard actions. On Sandboxer every agent harness gets computer tools that drive the sandbox's desktop. See run a computer-use agent on a Linux desktop.
Concurrency limit#
The number of sandboxes that may be active at once. On Sandboxer "active" means anything not stopped, errored or cancelled; the trial allows 2 and the $20 plan 100, and going over returns 429 limit_reached. See concurrency.
Container#
A process tree isolated with Linux namespaces and limited with cgroups, sharing the host's kernel. Docker runs containers; it is pre-installed inside every Sandboxer sandbox. See container vs microVM for untrusted code.
Continuous snapshot#
A disk snapshot Sandboxer takes every 10 minutes while a sandbox runs, and at every stop. Each sandbox keeps its latest two, at no charge; forks are made from them. See snapshots.
Copy-on-write (reflink)#
A copy that shares the original's data blocks and only writes new blocks when either side changes. Sandboxer snapshots and forks are reflinks, so copying a 100 GB disk takes the same time as a 1 GB one. See snapshots.
D–F#
Desktop#
A graphical session you or an agent can see and control. Each running Sandboxer sandbox has an XFCE desktop with Google Chrome, streamed to the browser over noVNC on HTTPS. See Desktop.
Egress#
Network traffic leaving the sandbox. On Sandboxer, traffic to the internet is allowed (IPv4 through NAT, IPv6 direct); traffic to other sandboxes, to the host and internal networks (except the node's DNS relay) and to SMTP port 25 is blocked. See what can reach a sandbox and what it can reach.
Environment#
On Sandboxer, the starting kit a sandbox gets at create time: variables, secret files, GitHub repositories and credential switches. Every change makes a new immutable version, and a sandbox stays on its version until you upgrade it. See Environments & secrets.
Ephemeral sandbox#
A sandbox you throw away after one task, as opposed to a persistent one you stop and resume. On Sandboxer, --no-snapshots makes one: stopping it erases it, and it can't be resumed, forked or saved. See persistent or ephemeral sandboxes.
Exit code 137#
128 plus signal 9 (SIGKILL): the process was killed, most often by the kernel's out-of-memory killer. In a Sandboxer sandbox the command exits 137 while the sandbox and its agent stay up. See fix exit code 137 or a full disk.
Fail fast#
A create, fork or resume option that returns at once instead of waiting for capacity. On Sandboxer --fail-fast answers within about 1.5 seconds with 202 or 503 no_ready_machine; a refused request bills nothing and doesn't count as a start. See fail fast.
Firecracker#
An open-source virtual machine monitor from AWS that uses KVM to run microVMs and leaves out devices it doesn't need (README). Sandboxer doesn't use it as its VMM, but you can run it inside a sandbox through /dev/kvm. See Firecracker vs Cloud Hypervisor.
Fork#
A new, independent sandbox made from a copy of another sandbox's disk. On Sandboxer a fork copies the disk only, never memory or running processes (its memoryRestored is null), gets a new id and subdomain, and starts with the default 1-hour TTL and no hosted routes. See fork a running sandbox.
G–L#
gVisor#
An application kernel that implements much of the Linux system-call interface in user space, so a container's system calls are handled by gVisor instead of going straight to the host kernel (gVisor docs). It runs as the OCI runtime runsc. It is a different isolation model from a microVM; see container vs microVM.
Hosted port#
A port inside a sandbox published on an HTTPS URL. On Sandboxer the URL is https://<subdomain>-<port>.box.sandboxer.com, made with sbx host <id> <port>; a brand-new route can return 404 for a second or two, so retry. See give a sandbox port an HTTPS URL.
Idle pause (wake on use)#
Stopping a sandbox with its memory after a period with no activity, then resuming it on the next use. On Sandboxer idleStopMinutes defaults to 15 on the trial and 30 on the $20 plan; the next API call or token-carrying request to a hosted port wakes it. See idle auto-pause and wake on use.
KVM#
The Kernel-based Virtual Machine, the hypervisor built into Linux. A user-space VMM drives it through ioctls to create VMs and vCPUs, and the CPU's virtualization extensions keep guests apart (KVM API). See what is a microVM.
Labels#
Key-value strings attached to a resource so you can find it later. On Sandboxer, sandboxes and named snapshots carry up to 64 labels, set through the REST API and the MCP server (the CLI and SDKs have no labels command yet); a PATCH replaces the whole set. See labels.
M#
MCP (Model Context Protocol)#
An open protocol that lets AI applications connect to external tools and data through servers that expose them (modelcontextprotocol.io). Its standard transports are stdio for local servers and Streamable HTTP for remote ones. See MCP server.
MCP server: local vs hosted#
A local MCP server runs as a process on your computer and talks over stdio; a hosted one runs at a URL. Sandboxer offers both: hosted at https://sandboxer.com/mcp (OAuth sign-in or an API key) and local with sbx mcp, which has the same 18 tools plus handoff_session. See local or hosted MCP.
Memory restore#
Resuming a VM from a saved image of its RAM and device state, so running processes carry on. On Sandboxer memoryRestored is true after such a resume and false after a cold boot, with resumeReason saying why; a different CPU type means a boot from disk (files kept, processes lost). See pause and resume with memory.
MicroVM#
A virtual machine run by a minimal VMM on KVM, with its own guest kernel and a few virtio devices instead of an emulated PC. It gives hardware isolation with less boot time and memory than a full VM. See what is a microVM.
N–P#
Named snapshot (template)#
A saved sandbox state with a name, used to start new sandboxes. On Sandboxer you save one with sbx snapshot <id> <name>, deploy it with sbx new --from <name>, and it is kept until you delete it, even after its source is gone. See turn a sandbox into a reusable template.
Nested virtualization#
Running a hypervisor inside a guest VM (kernel docs). Sandboxer exposes /dev/kvm in every sandbox, so QEMU, Firecracker and the Android emulator run inside; the inner guest's RAM comes out of the sandbox's. See Docker and KVM inside an agent sandbox.
No-env sandbox#
A Sandboxer sandbox created with --no-env: it receives none of your variables, secret files or credentials, and its SANDBOXER_TOKEN can only read that sandbox and host its ports. Forks of it are always no-env. See give every user their own sandbox.
Per-second billing#
Charging for compute by the second instead of rounding up to minutes or hours. Sandboxer meters each second a sandbox runs, times its size's rate; default costs $0.036 per hour, and a stopped sandbox uses no machine time. See the meter.
Preview URL#
A URL that shows a running build of an app, often one per branch or pull request. On Sandboxer a preview URL is a hosted-port URL, which keeps working across stop and resume because the subdomain doesn't change. See a preview URL for every pull request.
Private and public ports#
The two access modes of a Sandboxer hosted port. Private (the default) needs the ?_token= value in the URL, then a cookie; public is open to anyone. Switching between them mints a new token, so old private links stop working. See private and public.
R–S#
Resize#
Changing a sandbox's size. On Sandboxer you can grow it on resume or fork (--type large), which boots from disk; moving to a smaller size isn't supported yet, so create a new sandbox and copy your files. See change size.
Sandbox#
An isolated environment where code you don't fully trust can run without reaching your machine or other users. A Sandboxer sandbox is a full Ubuntu 24.04 microVM with sudo, systemd and Docker. See what is an AI agent sandbox.
Sandbox token#
The API key Sandboxer puts in every sandbox as SANDBOXER_TOKEN. It can act only on its own sandbox (exec, files, prompts, hosting, SSH, desktop, reading its snapshots), so a compromised sandbox can't reach your other sandboxes or account. See the in-sandbox key.
Setup script#
A shell script run once after a sandbox is created. On Sandboxer it is up to 64 KB, runs in the background as user after the sandbox is ready, and reports setupStatus (pending, running, done, failed). See setup scripts.
Snapshot#
A saved copy of a VM's state at a point in time. Sandboxer keeps three kinds: a stop snapshot (disk and memory, used by resume), continuous snapshots (disk, used by fork) and named snapshots (templates). See Snapshots.
Snapshots off#
A Sandboxer setting (--no-snapshots) under which nothing is captured in the background and a stop erases the sandbox. Idle pause is always off for such a sandbox. See snapshots off.
SSH proxy#
A helper that carries an SSH connection over another channel, named in ssh's ProxyCommand. sbx ssh-config --install adds a Host *.sbx block whose ProxyCommand is sbx proxy %h, so plain ssh, rsync and VS Code reach a sandbox over an authenticated WebSocket with only outbound HTTPS. See SSH from VS Code or Cursor.
Start limits#
Caps on how many sandboxes you may start per rolling minute, hour and day. On Sandboxer creates, resumes and forks each count as one start (12 / 60 / 200 on the $20 plan), and going over returns 429 rate_limited or 429 daily_limit_reached with Retry-After. See starts.
Stop and resume#
Stop saves a sandbox and ends billing; resume brings it back. A Sandboxer stop writes disk, memory and device state, then goes archiving to archived; run sbx stop --wait before resuming. A stopped sandbox uses no machine time and keeps everything. See pause and resume with memory.
Subdomain#
On Sandboxer, a sandbox's stable three-word name, such as amber-fjord-lumen, used in its hosted URLs. It stays the same across stop, resume and resize; a fork gets a new one. See Hosting.
V–Z#
virtio#
The OASIS standard for paravirtualized devices: a guest driver and the host exchange data through shared queues instead of emulating real hardware (virtio 1.2). MicroVMs use virtio for disk, network and other I/O. See what is a microVM.
VM-to-VM isolation#
Keeping one VM from reaching another. Sandboxer runs each sandbox as its own microVM with its own kernel and copy-on-write disk, and VMs share no network bridge, so traffic from one sandbox to another is blocked. See Security.
VMM (virtual machine monitor)#
The user-space program that asks the hypervisor for a VM, loads the guest and provides its devices. QEMU, Firecracker and Cloud Hypervisor are VMMs; KVM is the hypervisor they drive. See what is a microVM.
vsock#
A socket family for talking between a VM and its host without a network (vsock(7)). The Sandboxer agent inside each VM talks to the host over vsock, not TCP, so code on the sandbox's network can't reach the host's control API. See Security.
Warm pool#
A set of pre-booted, idle machines kept ready so a request doesn't wait for a boot; the provider pays for the idle capacity. A stopped Sandboxer sandbox that resumes with memory serves a similar need for your own state. For measured create and resume times, see how fast a sandbox starts, resumes and forks.
Zero data retention#
A Sandboxer account setting that deletes the data of every stopped sandbox and named snapshot instead of keeping it. With it on, a stop deletes the sandbox and idle pause is off. See data retention.
Terms that get mixed up#
| Pair | The difference on Sandboxer |
|---|---|
| Stop vs idle pause vs auto-stop | All three save memory and disk. You stop; idle pause stops after inactivity and wakes on use; auto-stop stops at a deadline and doesn't wake by itself |
| Stop vs delete | Stop keeps everything and stops billing; sbx delete removes the sandbox and its snapshots |
| Fork vs resume | Resume brings the same sandbox back, usually with memory; fork makes a new sandbox from a disk copy, without memory |
| Named snapshot vs continuous snapshot | You name and keep a named snapshot; continuous snapshots are automatic and only the latest two stay |
--environment vs --env |
--environment prod picks the kit; --env KEY=value sets one variable on one sandbox |
| Hosted port vs SSH endpoint | A hosted port is HTTPS through our proxy; sshEndpoint is a public IPv4 host:port forwarded to SSH |
FAQ#
Is a sandbox the same as a container?#
Not always. A container shares the host's kernel, while a microVM sandbox boots its own. Every Sandboxer sandbox is a microVM, and you can still run containers inside it with Docker.
Does a fork keep running processes?#
No. On Sandboxer a fork copies the disk only, so it boots fresh; systemctl enable the services you need and they start in the fork. Use resume when you need processes to carry on.
What does memoryRestored: false mean after a resume?#
The sandbox booted from disk: files are intact but running processes are not. resumeReason says why, for example cpu_mismatch or resized.
Does a stopped sandbox cost money?#
It uses no machine time. Its disk and memory image count toward your plan's included storage, which isn't billed separately.
Related#
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.