Categories
Self-Hosted Developer Tools AI Infrastructure Code Sandboxes Container Platform Agent Runtime gVisorStars
Forks
Watchers
Developer links
Sandstorm
Agent code needs somewhere disposable to run, and Sandstorm turns one modest VPS into a fleet of thousands of isolated sandboxes that wake the moment work arrives. You create sandboxes through a plain HTTP API, starting from a registered template or forking a tagged snapshot, with per-sandbox memory ceilings, attached volumes, and egress rules set on each call. Every sandbox is a gVisor container with its own network namespace, so untrusted agent code runs away from your host and away from its neighbors. Idle sandboxes cool down through four tiers, from running hot, to frozen in place with a wake time near ten milliseconds, to checkpointed on disk and back in about a fifth of a second, so a small machine can hold far more sandboxes than it could ever keep running at once. A single binary acts as master, node, and web console: the master tracks desired state and places work across nodes, nodes behind NAT dial out to join the fleet, and a gateway on each node wakes a sleeping sandbox and forwards its traffic automatically. The built-in Hub pulls ready-made snapshot packs for warmed runtimes like Python with numpy or a pre-warmed Playwright browser, skipping cold starts entirely. Running on a dedicated VPS on RepoCloud with guaranteed CPU, RAM, and SSD, full root SSH access, and a browser serial console. Apache-2.0 licensed.
Benefits
- Thousands Of Sandboxes, One Machine
- Idle sandboxes freeze in place, then checkpoint to disk, so a single modest VM holds far more sandboxes than it could keep running, and each wakes when traffic arrives.
- Wake Times In Milliseconds
- A frozen sandbox resumes in about ten milliseconds and a disk snapshot restores in roughly a fifth of a second, so agents never pay full container cold-start costs.
- Isolation Without Virtual Machines
- Each sandbox is a gVisor container with its own network namespace and cgroup memory ceiling, and the fleet runs on ordinary cloud VMs with no KVM or nested virtualization.
- One Binary Runs Everything
- The same sandstormd binary serves as master, node, and web console, with placement, node pairing by code, and wake-on-traffic gateways handled inside the fleet rather than bolted on.
Features
- HTTP Sandbox API
- Create sandboxes from templates or snapshot tags with POST /v1/sandboxes, including batch creation of up to 256 sandboxes in a single call.
- Four Cooling Tiers
- Sandboxes step down from hot to frozen to snapshot to detached as they idle, squeezing cold pages into zswap and releasing memory automatically.
- Snapshot Hub Registry
- Pull ready snapshot packs for warmed runtimes, such as Python with numpy or a pre-warmed Playwright Chromium, or publish packs to your own registry mirror.
- Fleet Placement Master
- The master keeps desired state in SQLite, places sandboxes across nodes by capacity, reserves room as it places, and accepts NAT nodes that dial in.
- Wake-On-Traffic Gateway
- Requests hitting a sandbox port reach a per-node gateway that wakes the sandbox from any tier and forwards the traffic without client-side changes.
- Per-Sandbox Egress Controls
- Every sandbox gets its own network namespace plus configurable egress rules and memory limits, so agent code reaches only what you allow.