Isolated compute for agents and applications
Give every workload a machine of its own.
Give agents, jobs, and preview apps a real machine with shell, files, browsers, ports, and persistent state. Every workload stays inside an explicit compute and network boundary.
Allocate
A clean runtime comes online.
The workload receives its own filesystem, process space, resource envelope, and network policy.
create(template: node, size: medium)- Isolated runtime ready
- 2 vCPU · 4 GiB memory
- Host filesystem not mounted
- 01Fresh isolated runtime
- 02Stop and revive state
- 03Signed preview URLs
- 04Allow, deny, or whitelist egress
01The execution boundary
A real machine for the workload. Nothing more.
The sandbox can be useful without becoming trusted. Files, processes, resources, and network exits remain explicit at every step.
Inside
Shell, files, browser, and processes
Outside
The gateway host and other tenants
Exits
Only declared hosts, ports, and artifacts
Never mounted
Explicit exits
02Workload profiles
Shape the environment around the work.
Choose what enters, how long state stays, and which result can leave. Everstack handles placement and isolation behind the same sandbox API.
Stateful sessions
Pause the machine, not the work.
Keep the sandbox identity and workspace across sessions. Stop it to release compute, then revive it when the next task arrives.
- Starts with
- Existing workspace
- State model
- Stop and revive
- Exit surface
- Files and events
Enters
Workspace state
Everstack sandbox
Revivable session
state preserved
Leaves
Files + history
03Network control
Outbound is policy. Inbound is deliberate.
Choose allow, deny, or whitelist behavior for egress. If a workload needs to serve traffic, expose only the port it owns and issue a signed, expiring preview.
Outbound policy
Permit only declared destinations.
Example lifecycle
Current state
Sleeping
Runtime
released
Workspace
preserved
04Lifecycle and state
Release the machine without losing the work.
Stop a sandbox to release compute while preserving its workspace snapshot. Revive the same sandbox identity when the next task arrives, or terminate it when the work is finished.
Same workspace on revive
Restore files and continue from the last controlled stop.
Retention with a clear end
Keep state only for the window the workload needs.
05Workloads
Useful anywhere code needs a controlled place to live.
Agents are one consumer. The same sandbox contract also supports human debugging, preview services, data work, and event-driven automation.
Coding agents
Clone a repository, install dependencies, run tests, inspect failures, and return a patch without touching the host workspace.
Git · shell · files · LSP
Preview environments
Run a temporary web service, expose one port, and share a signed link for product review or QA.
Ports · signed URLs · logs
Data and document jobs
Process untrusted inputs with declared resources, controlled egress, and downloadable outputs.
Uploads · storage · network policy
Browser and computer use
Give an agent a graphical environment and browser sidecar while the desktop remains inside the sandbox boundary.
Chromium · screenshots · interaction
06Compute pricing
Choose the machine. Pay while it is allocated.
Sandbox compute is metered per second. Pick a fixed resource size, estimate the active runtime, and stop the sandbox when the machine is no longer needed.
Usage counter
40% of sandbox time is spent executing code. This changes Vercel CPU cost only.
Compare provider pricing
One workload, matched against current public list rates.
Allocated CPU and memory, 20 GiB root disk included
Why teams choose Everstack beyond the meter
- Open source and self-hostable
- Agents, policy, and sandboxes share one control plane
- Execution evidence lands in the same trace
Pricing breakdown
- Allocated CPU
- 100,000 vCPU hr
- $5,040.00
- Provisioned memory
- 100,000 GiB hr
- $1,620.00
- Root disk
- 20 GiB
- Included
Estimated monthly total
Based on 50,000 allocated hours using the medium size.
$6,660.00
Competitor estimates use the linked public list rates and the closest available resource model. They do not subtract temporary credits. All estimates exclude network transfer, persistent volumes, snapshots, and applicable taxes.
Start building07Quickstart
Create the boundary before the work begins.
Start from a prepared template or image, declare the resource and network limits, then hand the sandbox to a person, an application, or an agent.
Available from the first allocation
- Isolated filesystem and shell
- Logs, metrics, and lifecycle events
- Signed previews for exposed ports
- Stop, revive, and terminate controls
08Questions
What teams usually ask first.
The short version of where sandboxes run, what they retain, and how much network access they receive.
Do application teams choose where a sandbox is placed?
No. Application code declares the template, resources, lifecycle, and network policy. Everstack handles placement and isolation behind the same sandbox API, while self-hosted operators control the deployment configuration.
Can a sandbox keep state between sessions?
Yes. Stopping a sandbox releases its runtime while preserving a workspace snapshot for revival. Persistent volumes can hold selected data independently. Terminating the sandbox permanently removes its sandbox workspace.
Can I block network access?
Yes. Set outbound traffic to allow, deny, or whitelist, and use block-all policy with explicit CIDR exceptions when the workload needs a narrower egress surface. Inbound ports remain private until you expose one.
Is a sandbox only for AI agents?
No. Agents use the same sandbox APIs as any application. Sandboxes also fit preview services, scheduled jobs, webhooks, data processing, browser automation, and direct human debugging.
Put the work somewhere safe
Give the next workload its own place to run.
Create a sandbox in Everstack Cloud or bring the same control plane to your own infrastructure.