What is sandbox infrastructure? A guide for AI and engineering teams

AI agents write code. Users submit scripts. LLM-powered tools generate and execute logic at runtime. Every one of these workloads needs somewhere safe to run. That is what sandbox infrastructure is: the systems, isolation layers, orchestration, networking, and lifecycle management that let you execute untrusted or unpredictable code without putting your production systems at risk.

This article explains what sandbox infrastructure is, what it consists of, why teams need it, and how to run it in production without building it yourself.

Sandbox infrastructure is the complete set of systems required to run isolated workloads safely in production. It is not just a container runtime or a single tool. It is a stack: an isolation technology to enforce security boundaries, an orchestrator to schedule and manage workloads, networking controls to restrict what code can access, secrets management to prevent credential leakage, observability to monitor what code actually does, and lifecycle management to provision and tear down environments efficiently.

The term is often used loosely to mean just the sandbox itself, but the sandbox is only the execution boundary. Everything around it is what makes it production-ready.

The isolation layer determines the security boundary between untrusted code and everything else. Three models exist in practice:

For genuinely untrusted code, containers are not sufficient. A kernel vulnerability inside a container can affect the host and every other tenant. MicroVMs give each workload its own dedicated kernel, enforcing a hardware boundary. For most AI agent code execution and multi-tenant platforms, Firecracker or Kata Containers is the right baseline.

Orchestration handles provisioning, scheduling, bin-packing, autoscaling, and lifecycle management across a fleet of sandboxes. Without it, you are spinning up individual environments by hand. With it, you can handle thousands of concurrent workloads, pre-warm pools for low-latency cold starts, and scale horizontally as demand grows. Kubernetes is the most common orchestration layer, but running microVMs on Kubernetes requires additional integration (typically via Kata Containers or firecracker-containerd).

Untrusted code should not make arbitrary outbound network requests. Production sandbox infrastructure includes default-deny egress policies, per-sandbox firewall rules, and the ability to whitelist specific endpoints. Without network controls, a sandboxed workload can exfiltrate data, call external APIs, or participate in attacks even if the kernel is isolated.

Sandbox workloads often need access to credentials, API keys, and connection strings. These must be injected securely without being baked into images or exposed in environment variables accessible to the workload. Production sandbox infrastructure provides scoped secret injection that gives each workload exactly what it needs and nothing more.

Logs, metrics, and audit trails from sandbox executions matter when something goes wrong or when you need to prove to a compliance auditor what happened. Production sandbox infrastructure captures real-time execution logs, resource consumption metrics, and network activity per workload.

Ephemeral sandboxes that are destroyed after each run prevent state accumulation between executions. Persistent sandboxes that retain filesystem state across runs support agent workflows that maintain context over time. Production sandbox infrastructure handles both models and manages teardown, cleanup, and resource reclamation efficiently.

Building sandbox infrastructure from scratch means solving each layer independently. Choosing and configuring an isolation technology. Integrating microVMs with Kubernetes. Configuring networking policies. Setting up secrets injection. Wiring in observability. Managing persistent and ephemeral lifecycle patterns. Testing everything under concurrent load.

Most teams that attempt this often take months before running their first workload in production, with ongoing maintenance afterward. Engineering time spent on sandbox infrastructure is engineering time not spent on the product. For most teams, the economics of building and maintaining this stack do not make sense when purpose-built platforms exist.

• Isolation model: Containers, gVisor, and microVMs provide different security boundaries. For untrusted code, microVM isolation with a dedicated kernel is the minimum.
• Session lifecycle: Can you run both ephemeral sandboxes destroyed after each run and persistent sandboxes that retain state? Some platforms support only one model.
• Concurrency and scaling: What is the maximum concurrent sandbox count? Can it autoscale to meet burst demand without pre-provisioning?
• BYOC deployment: Can sandboxes run inside your own cloud account or on-premises? For regulated industries and enterprises, execution that never leaves your own VPC is a hard requirement.
• Full-stack scope: Does the sandbox run alongside databases, APIs, and background workers in the same control plane, or does it require a separate infrastructure stack?
• Cold start latency: How fast can new sandboxes be provisioned? For interactive agent workflows, cold start time directly affects the user experience.

AI coding agents: Coding agents like Claude Code and Cursor generate and execute code in real time. Each execution needs an isolated environment with filesystem access, a terminal, and network controls. Sandbox infrastructure handles this at scale without exposing the host system to agent-generated code.

Code interpreters: LLM-powered code interpreter tools let users run Python, JavaScript, and shell commands through a chat interface. Every user submission is untrusted code. Sandbox infrastructure gives each execution its own isolated environment and tears it down after the run.

Autonomous tool use: Agents that call external APIs, write files, and run subprocesses need a controlled environment where those actions are scoped and auditable. Sandbox infrastructure provides the execution boundary and the observability layer around it.

Reinforcement learning pipelines: RL training involves agents running iterative code experiments across many parallel environments. Sandbox infrastructure handles the concurrent provisioning, isolation between runs, and resource cleanup that RL pipelines require.

• Northflank – The only platform here that covers the full stack: microVM isolation (Kata Containers, Firecracker, gVisor), unlimited sessions, self-serve BYOC into your own cloud or on-premises, managed databases, and GPU workloads in the same control plane. No session caps. No separate infrastructure required.
• E2B – Developer-friendly sandbox API built specifically for AI agents. Firecracker microVM isolation, clean Python and TypeScript SDKs, 150ms boot times. Sessions capped at 24 hours on Pro.
• Daytona – Stateful sandbox infrastructure for AI agents with sub-90ms cold starts. Docker isolation by default with optional Kata Containers. Good for coding agents that need fast environment provisioning.
• Modal – Serverless Python-first platform with gVisor isolation and deep GPU support. Scales to 20,000 concurrent containers. No BYOC option.

Running sandbox infrastructure in production without building it yourself requires a platform that has already solved each layer. Northflank provides production-ready sandbox infrastructure that teams use to run everything from AI coding agents to multi-tenant code interpreters.

Northflank supports Kata Containers with Cloud Hypervisor, Firecracker, and gVisor, applied per workload based on your threat model. Every sandbox runs in its own microVM. Orchestration, bin-packing, autoscaling, and microVM lifecycle management are handled by the platform. Sandboxes run alongside managed databases, background workers, APIs, and GPU workloads in the same control plane, so you do not need a separate infrastructure stack for execution.

Sessions run indefinitely with no platform-imposed limits, supporting both ephemeral workloads destroyed after each run and persistent environments that retain state across agent sessions. BYOC is self-serve into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, or bare-metal. Your data never leaves your own VPC.

cto.new migrated their entire sandbox infrastructure to Northflank in two days after EC2 metal instances made scaling costs unpredictable, going from unworkable provisioning to thousands of daily deployments with linear, per-second billing. That is what production-ready sandbox infrastructure looks like when you do not build it yourself.

Pricing: $0.01667/vCPU-hour and $0.00833/GB-hour, billed per second. BYOC deployments bill against your own cloud account.

Get started on Northflank (self-serve, no demo required). Or book a demo to walk through your sandbox requirements.

A sandbox is an isolated execution environment for a single workload. Sandbox infrastructure is the full stack required to run sandboxes at scale in production: isolation technology, orchestration, networking, secrets management, observability, and lifecycle management. The sandbox is one component of the infrastructure.

For genuinely untrusted code, microVM isolation with a dedicated guest kernel per workload is the right default. Firecracker and Kata Containers both provide hardware-level isolation via KVM. gVisor provides a middle ground through syscall interception. Standard containers share the host kernel and are not sufficient for multi-tenant untrusted code execution.

Yes, if the platform supports BYOC deployment. Northflank supports self-serve BYOC into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal. The orchestration and microVM lifecycle management run on your own infrastructure. Your data never leaves your VPC.

Ephemeral sandboxes are destroyed after each run with no state carried over. They prevent state accumulation between executions and are well-suited for short, discrete code execution tasks. Persistent sandboxes retain filesystem state across runs, supporting agent workflows that maintain context across multiple sessions. Northflank supports both models in the same control plane.

Most AI agent workloads need more than just a sandbox. They need databases for agent memory, APIs for tool calls, background workers for async tasks, and sometimes GPU workloads for inference. Platforms like Northflank run all of these in the same control plane as your sandboxes, eliminating the need to stitch together a separate infrastructure stack.

Sandbox infrastructure is not a single tool. It is a stack: isolation, orchestration, networking, secrets, observability, and lifecycle management working together to let you execute untrusted or unpredictable code safely at scale. Building that stack yourself takes months and requires ongoing maintenance. For most teams, the right answer is a platform that has already been built.

Northflank provides production-ready sandbox infrastructure with microVM isolation, full-stack scope, and BYOC deployment, all without requiring you to build or maintain the stack yourself. If you are running AI agents, multi-tenant code execution, or any workload where you do not fully trust what runs, that is the infrastructure you need.

• Top AI sandbox platforms for code execution in 2026: A ranked comparison of AI sandbox platforms covering isolation, session limits, pricing, and platform completeness.
• Containers vs virtual machines: key differences and when to use each: The broader comparison covering containers, VMs, and microVMs in context.
• Firecracker vs Docker: key differences and when to use each: A direct comparison of Docker containers and Firecracker microVMs on isolation, security, and use case fit.