Isolated runtimes for agent code.
Your agent writes code. It has to run somewhere that is not your production server.
What you get
- Hardware-level isolation per session, so one task cannot reach another
- Sub-second startup, because agents create and discard environments constantly
- Filesystem, network, and package installs inside the sandbox
- Configurable lifetimes, from a few seconds to long-running jobs
- Multi-region placement, so the runtime sits near your users
- Usage visible per run, not per month
Where teams get this wrong
Running agent-generated code in a container that shares a kernel with anything you care about. Leaving sandboxes alive because nothing reclaims them. Discovering the cost model only after the first heavy month. We set the defaults so none of those are your problem.
Good fit if
- Your agent generates and executes code, runs data analysis, or builds files
- You need per-tenant isolation for customer workloads
- You are currently running this on a VM and know that is temporary
Common questions
Isolation is at the hardware level, per session. One task cannot reach another, which is the property you need when the code being executed was written by a model rather than by your team.
Startup is sub-second. Agents create and discard environments constantly, so start time is a throughput characteristic rather than a detail.
Lifetimes are configurable and idle environments are reclaimed automatically. Sandboxes staying alive because nothing reclaims them is one of the most common sources of unexpected cost.
Yes. Filesystem access, network access, and package installs all work inside the sandbox, within the boundaries set for your deployment.
Tell us what you are shipping.
Send the shape of the problem — what the agent does, who uses it, and what breaks today. We will tell you what we would run and what it would take.