A virtual sandbox is an isolated execution environment that runs code, applications, or files without allowing direct changes to the host system: the guest gets a complete, working operating system, and a virtualization boundary underneath decides what, if anything, it can touch outside itself.
You have a binary from a vendor you have not audited. Or a user-submitted script. Or an email attachment that looks wrong. You need to run it, watch what it does, and be sure that when it writes to strange paths or opens outbound connections, none of it reaches your network.
That is the whole job: run it somewhere it can thrash, watch, then delete the environment. The complication is that “sandbox” covers four or five different mechanisms, and they do not offer the same protection.
What Is a Virtual Sandbox?
A virtual sandbox is an isolated execution environment for running code, applications, or files without direct impact on the host system. The “virtual” part is load-bearing: isolation comes from a virtualization layer, not from permissions inside the operating system the untrusted code is already running on. A hypervisor, or a kernel emulated in userspace, sits between the guest and the real machine and intercepts what it tries to do.
The second defining property is disposability. A sandbox starts from a known-good image, and everything the code writes lands in a layer that gets thrown away, so the next run starts from identical conditions. If the environment drifts, you cannot tell behaviour from residue.
Developers call this the blast radius. A sandbox does not make hostile code harmless. It bounds what the damage can reach.
Sandbox vs. Virtual Machine vs. Container
“Sandbox vs. virtual machine” is the comparison people search for, and it is a category error: a VM is a mechanism, a sandbox is a purpose, and a sandbox is frequently a VM with policy layered on top. The useful comparison is three-way, between the boundaries you can put under untrusted code.
| Container | Sandbox (microVM) | Traditional VM | |
|---|---|---|---|
| Isolation boundary | Namespaces and cgroups | Hardware virtualization | Hardware virtualization |
| Guest kernel | Shared with the host | Its own | Its own |
| A breakout needs | A kernel bug or misconfiguration | A hypervisor escape | A hypervisor escape |
| Start time | Milliseconds | Sub-second | Tens of seconds |
| Memory overhead | Negligible | A few MiB per instance | Hundreds of MiB |
| Persistence | Layer discarded on exit | Discarded, or checkpointed | Persists across reboots |
| Built for | Packaging and density | Containing hostile code | Long-lived workloads |
Containers were designed to isolate workloads that cooperate, not workloads that attack you. They share a kernel, so a kernel vulnerability is a shared-fate event. That does not make them useless for untrusted code, but the container alone is not the boundary; something has to sit underneath it.
The VM was always the honest answer, and the objection was weight. MicroVMs removed it.
The Isolation Ladder: From Language Sandboxes to Hardware
Weakest to strongest. Each rung buys containment and costs compatibility, speed, or both.
Language-level sandboxes
The weakest rung, and the one most often mistaken for a security boundary. Node’s built-in vm module says so itself: it is not a security mechanism, and should not be used to run untrusted code.
The real answer at this layer is a separate V8 isolate, which is what isolated-vm provides: a fresh JavaScript environment with its own heap, sharing nothing unless you marshal it across. Its README is careful too. Using it does not automatically make an application safe, because handing untrusted script a reference to any isolated-vm object is a springboard back out.
OS primitives
One rung up: Linux namespaces, seccomp filters, dropped capabilities. bubblewrap is the reference implementation, and what Flatpak uses to confine desktop applications. It builds an unprivileged sandbox from user, mount, PID, IPC, network and UTS namespaces, mounts everything nodev, disables setuid binaries, and applies a seccomp filter.
Its own documentation is blunt: bubblewrap is not a complete, ready-made sandbox with a security policy. Whatever builds the command line owns the model, and gaps such as D-Bus access are the caller’s.
Userspace kernels
gVisor takes a third approach: a Linux-compatible kernel implemented in userspace, in Go. Its Sentry component intercepts the guest’s system calls and services them itself, while a separate Gofer process mediates filesystem access, so the host kernel’s exposed surface shrinks to what Sentry calls. The project states the trade plainly: reduced compatibility and higher per-syscall overhead.
Hardware virtualization
The top rung, where the guest kernel itself can be untrusted. Firecracker is the microVM monitor that made this cheap: KVM-based isolation, five emulated devices, boot in under 125 milliseconds, under 5 MiB of memory overhead per VM, and around 150 microVMs created per second per host. That is why recent sandboxing products converged on microVMs: you stop trading isolation for weight.
The short version: if the code is hostile rather than merely buggy, the boundary has to be the hypervisor. Everything below it is defence in depth, not the wall.
What About Windows Sandbox?
Windows Sandbox is Microsoft’s built-in disposable desktop, and for opening one suspicious file on your own laptop it is the right answer. It uses hardware-based virtualization and the Microsoft hypervisor to run a separate kernel isolated from the host, launches in seconds, and discards all software, files and state on close. Every launch is a clean Windows install.
Two caveats. It is supported on Windows Pro, Enterprise, Pro Education, SE and Education, and not on Home. And networking is on by default, which Microsoft’s own documentation flags as a way to expose untrusted applications to your internal network; you turn it off in the .wsb configuration file.
It is also one instance at a time, on the machine in front of you, with no answer for sandboxes a program creates on demand.
What a Sandbox Does Not Protect You From
Isolation is not invisibility, and it is not authorization.
- The network you attached it to. Most incidents are not escapes. The code stays inside and talks to your database, your metadata service, or the internet. Restricting egress is a separate decision from picking a boundary, and the one people skip.
- Whatever you handed it. Credentials, tokens and mounted source trees cross the boundary because you put them there. A sandbox holding your production key is a sandbox around nothing.
- Sandbox-aware code. Malware fingerprints its environment through timing, device tables and absent user activity, then behaves when it thinks it is watched.
- The rung you chose. A language sandbox stops accidents, not attacks. A container stops noisy neighbours, not kernel exploits. Most failures are a boundary weaker than its operator believed.
- Drift. Stale images, uncollected snapshots, network policy loosened one exception at a time. A decayed sandbox looks like a working one until it does not.
Sandboxing agent-written code adds failure modes on top of these, covered on agent sandboxes.
Virtual Sandboxes on Fly.io
Fly.io runs every workload as a Firecracker microVM on bare-metal servers, so hardware virtualization is the default boundary rather than a premium tier. The security docs put it directly: user code is fraught with peril, and Machines run it safely, hostile code included.
Fly Machines are the general primitive. They start and stop at sub-second speeds, roughly 300 milliseconds to boot, and fly machine run --rm destroys the Machine when it stops, which is the disposable-per-run shape a sandbox wants. Each app gets a private IPv6 network, so a sandbox reaches what you scope it to and nothing else.
Sprites are the sandbox-shaped version: hardware-isolated Linux environments with a persistent ext4 filesystem that sleep when idle, wake on request, and take copy-on-write checkpoints you can restore. That covers the case where the environment must survive between runs but the code inside still cannot be trusted.
Frequently Asked Questions
Is there a difference between a sandbox and a virtual machine in terms of security?
Yes, but not the difference most people expect. A VM is an isolation mechanism; a sandbox is a disposable environment built to contain untrusted code, usually a VM with policy on top. What matters is the boundary underneath: a shared kernel, a userspace kernel, or hardware virtualization. Fly.io always uses the last.
Is a Docker container a secure sandbox for untrusted code?
No, not on its own. A standard container shares the host kernel, so a kernel bug or a privileged misconfiguration is an escape path. Rootless mode, seccomp profiles and gVisor underneath help. On Fly.io a container image still runs as a Firecracker microVM with its own kernel.
Are there lighter ways to isolate one untrusted application than running a full VM?
Yes. Bubblewrap builds an unprivileged Linux sandbox from namespaces and seccomp filters, which is how Flatpak confines desktop apps. gVisor goes further with a Linux-compatible kernel in userspace, costing compatibility and syscall overhead. Both are lighter than a VM and weaker than one. Fly.io instead made the microVM cheap.
Are there any good reasons anymore to use a VM over Docker or devcontainers?
Yes, and containment is the main one. A container shares the host kernel, the wrong boundary for code that might be hostile rather than merely broken. On Fly.io container images run inside Firecracker microVMs, so you keep the packaging without the shared kernel.
Can I run a sandbox VM on the same host or cluster as my other workloads?
Yes, if the boundary is one you would trust between tenants and the sandbox has no network path to anything you care about. The usual mistake is the network, not the compute: a sandbox sharing a private network with your database is pointless. Fly.io scopes private networking per app.
Can a virtual sandbox restrict network access while code runs?
Yes, and it usually should. Options run from full connectivity, through host-only networking, down to no network at all. Windows Sandbox, for one, enables networking by default, which Microsoft warns can expose untrusted applications to your internal network. On Fly.io each app gets its own private IPv6 network.
Is Windows Sandbox available on Windows Home?
No. Microsoft supports Windows Sandbox on Windows Pro, Enterprise, Pro Education, SE and Education, and not on Home. It is a desktop feature running one instance at a time, so it does not cover sandboxes a program creates on demand. That is the case Fly.io serves.
What is a virtual sandbox used for?
Malware analysis, opening suspicious files, running third-party or user-submitted code you cannot audit, and test runs that start from identical clean state. The shared requirement is disposability: run it, watch it, delete the environment. On Fly.io that is a microVM created per run and destroyed after.