Sandbox Environments
Request-level isolation patterns that test changes in production-like conditions without duplicating the whole environment, so you pay for the services you actually changed rather than for a second copy of everything
services only
What Are Sandbox Environments?
A fundamentally different approach to testing changes that uses request-level routing instead of full environment duplication - now extended to isolate AI agent workloads with hardware-enforced boundaries.
The Core Concept
Sandbox environments are isolated testing contexts that intercept and route specific requests to modified versions of individual services while leaving the rest of the application stack untouched. Rather than spinning up a complete copy of your entire infrastructure, sandboxes deploy only the services you have changed and use intelligent traffic routing to direct relevant requests to those modified instances.
This approach is sometimes called "request-level isolation" or "traffic sandboxing." The key insight is that most changes affect only one or two services in a microservices architecture, so duplicating the entire environment is wasteful. Sandboxes leverage the existing shared infrastructure for all unchanged services and only spin up isolated instances for the specific components under test.
The result is a testing experience that feels like a full production-like environment from the perspective of the request being tested, but consumes a fraction of the infrastructure resources. Teams can run dozens or even hundreds of concurrent sandboxes on the same base infrastructure without significant cost increases.
How Request Routing Works
Sandbox environments rely on a routing layer - typically a service mesh or smart proxy - that inspects incoming requests for routing metadata. This metadata, often passed as HTTP headers or baggage context, tells the router which sandbox a request belongs to. When a request arrives with a sandbox identifier, the router checks whether the target service has an isolated sandbox instance. If it does, the request is forwarded to the sandbox version. If not, the request flows to the shared baseline service as normal.
Requests carry a sandbox ID in HTTP headers that propagates through the entire call chain
OpenTelemetry baggage or custom middleware ensures routing context survives across service-to-service calls
Only services with sandbox overrides receive routed traffic - everything else uses the shared baseline
Unmatched requests pass through to shared services, maintaining full application functionality
Sandbox Request Flow
Traffic routing through a sandbox environment in a microservices architecture
Incoming Request
Request arrives with sandbox header (e.g., x-sandbox-id: feature-123)
Smart Router
Service mesh inspects header and checks for sandbox overrides
Route Decision
Changed service gets sandbox instance; unchanged services use baseline
Response
Full end-to-end response combines sandbox and baseline services
AI Agent Sandboxing
As AI coding agents generate and execute code autonomously, sandboxing has evolved from a developer convenience to a security requirement. Modern agent sandboxes use microVMs for hardware-enforced isolation.
Why AI Agents Need Sandboxes
AI coding agents such as Claude Code, Codex CLI, Antigravity CLI, and Kiro generate and execute code with increasing autonomy. Unlike a human developer who can inspect a command before running it, agents operate at machine speed and may execute destructive operations, install untrusted packages, or make unexpected network calls. Sandboxing provides the safety boundary that lets organizations run agents unsupervised without risking host systems or production infrastructure.
The deeper reason containment moved into the infrastructure layer is that prompt injection has no reliable fix at the model layer. An agent cannot durably distinguish instructions you gave it from instructions embedded in the content it reads - a dependency README, a stack trace, an issue title. Simon Willison's "lethal trifecta" names the conditions that turn that weakness into a breach: access to private data, exposure to untrusted content, and a way to communicate outward. A coding agent running in CI has all three by default, so the control has to sit outside the model, in what the sandbox permits the agent to touch and where its traffic is allowed to go.
The industry has converged on that answer from several directions. Cloudflare's Sandboxes reached general availability on 04-13-2026 leading with secure credential injection through a programmable egress proxy, so the agent uses a credential it never sees. Coder renamed its agent-scoping product Agent Firewall. Open-source agent firewalls have appeared to fill the same gap. Incidents through 2026 have followed the predicted shape - agent hijacking through poisoned data an agent was expected to read, and supply-chain compromise chained from a single attacker-controlled string in a repository. Reporting on the specifics is largely secondary-sourced, so treat the class of attack as the durable lesson rather than any one account of it.
Isolation strength matters for the same reason. Containers share the host kernel, so a kernel exploit reached by agent-generated code can cross the container boundary. MicroVM-based sandboxing gives each workload its own kernel and hardware-enforced boundary, closing that path while keeping startup times close to a container's.
Agent sandboxes also need capabilities beyond simple isolation: filesystem snapshots for branching execution paths, network allow/deny lists to control agent access, session time limits to prevent runaway processes, and observability into what the agent is doing inside the sandbox.
Pin the agent binaries your sandbox images install, because the CLI layer turns over quickly. Google retired Gemini CLI for free and Google AI Pro/Ultra users on 06-18-2026 in favor of Antigravity CLI, released 05-19-2026; holders of enterprise or Gemini Code Assist licenses are unaffected and keep Gemini CLI, so a mixed fleet may legitimately need both. Amazon Q Developer's IDE product is winding down - new signups closed 05-15-2026 and support ends 04-30-2027, with Kiro as the replacement, though Q inside the AWS Console, Slack, Teams, and documentation is unaffected.
MicroVM-Based Isolation
MicroVMs are lightweight virtual machines optimized for fast startup and minimal resource overhead. Technologies like Firecracker (which powers AWS Lambda and Fargate) boot in under 200ms with only 3-5MB of memory overhead per instance - a fraction of traditional VMs. Each microVM gets its own kernel, providing hardware-enforced isolation without the performance penalty of full virtualization.
Sub-200ms boot times with dedicated kernels, used by E2B and Docker Sandboxes for agent isolation
OCI-compatible microVMs that integrate with Kubernetes, used by Northflank for agent sandboxing
Intercepts syscalls without full VMs - lighter weight but weaker isolation than hardware-enforced boundaries
Agents can snapshot mid-execution and fork into parallel branches, enabling speculative exploration of multiple solution paths
E2B
Purpose-built sandbox platform for AI agents using Firecracker microVMs. Offers 150ms startup times, Python and JavaScript SDKs, and OCI image support. Each sandbox gets a dedicated kernel for hardware-enforced isolation of AI-generated code execution.
Daytona
Left the CDE market to build agent sandbox infrastructure, and is no longer a CDE. Provides fast sandbox launches with snapshotting and parallel branch forking. Raised a $24M Series A in February 2026 led by FirstMark, with participation from Datadog and Figma Ventures. Evaluate it as a commercial product rather than an open-source one: its public repository stopped being maintained in June 2026 when core development moved to a private codebase.
Docker Sandboxes
Isolates coding agents such as Claude Code, Codex, and Antigravity CLI inside dedicated microVMs with their own Docker daemon. Each agent gets a version of your development environment with only project workspace mounted. Includes network allow/deny lists for controlling agent access.
Sandboxes vs Ephemeral Environments
Both approaches solve the "test in isolation" problem, but they take fundamentally different paths to get there. Understanding the trade-offs helps you choose the right tool.
Sandbox Environments
REQUEST-LEVEL ISOLATION- Intercepts specific requests via header-based routing
- Only deploys changed services - shares everything else
- Cheaper than full duplication, in proportion to how few services you actually change
- Tests against real production-like traffic patterns
- Scales to hundreds of concurrent sandboxes
Best for: Microservices architectures, high team concurrency, cost-sensitive organizations, production-like validation, AI agent workloads
Ephemeral Environments
FULL DUPLICATION- Creates a complete copy of the entire application stack
- Fully isolated - no shared state or infrastructure
- Simpler mental model - "my own copy of everything"
- No routing complexity or header propagation required
- Works with any architecture (monolith or microservices)
Best for: Monolithic applications, full-stack E2E testing, compliance requirements needing complete isolation, smaller teams
| Dimension | Sandbox | Ephemeral |
|---|---|---|
| Isolation level | Per-request / per-service | Full environment |
| Resource cost | Low (only changed services) | High (full stack per env) |
| Spin-up time | Milliseconds to seconds (microVM / single service) | Seconds to minutes (full stack) |
| Concurrency | 100s on same base infra | 10s before cost becomes prohibitive |
| Complexity | Requires service mesh / routing layer | Simpler - standard IaC provisioning |
| Architecture fit | Microservices on Kubernetes | Any architecture |
| Data isolation | Shared databases with tenant routing | Dedicated databases per environment |
| AI agent support | MicroVM isolation, snapshot/fork, network controls | Full environment per agent session |
When to Use Each Approach
Choose Sandboxes When:
- You run microservices on Kubernetes
- Many developers need concurrent isolated testing
- Cost efficiency is a top priority
- You want production-like traffic conditions
- Changes typically affect 1-3 services at a time
- AI agents need isolated execution environments
Choose Ephemeral Environments When:
- You run a monolithic or tightly coupled application
- Full data isolation is required for compliance
- You need stakeholder-facing preview URLs
- Changes span many services simultaneously
- Routing complexity is not acceptable for your team
Tools and Platforms
The sandbox ecosystem includes purpose-built platforms for request-level isolation, CDE tools with sandbox capabilities, and a growing category of AI agent sandbox infrastructure.
Signadot
Kubernetes-native sandbox platform purpose-built for request-level isolation in microservices architectures. Deploys lightweight sandboxes containing only changed services while sharing the existing cluster for everything else. Includes AI development support through the Model Context Protocol (MCP), letting coding agents such as Claude Code drive sandbox resources directly for autonomous testing. MCP itself is vendor-neutral: Anthropic donated it to the Agentic AI Foundation under the Linux Foundation in December 2025, under Apache 2.0, with AWS, Anthropic, Google, Microsoft, and OpenAI among the founding platinum members.
Telepresence
Telepresence builds a two-way network tunnel between your local machine and a remote Kubernetes cluster, intercepting traffic destined for a specific service and redirecting it to your laptop. Developers get sandbox-like isolation with hot reload and full debugger access against live cluster traffic, without deploying to the cluster during active development. Confirm the current commercial packaging and support status before standardizing on it: the vendor product pages have moved, and Ambassador Labs' Telepresence URL now redirects to Gravitee.
Coder
Coder's Terraform-based workspace templates provision sandbox-style environments connected to shared cluster infrastructure. Its agent story rests on two Premium add-ons: AI Gateway, which brokers and meters model access, and Agent Firewall, which scopes what an agent may reach. Both were renamed in April 2026 from AI Bridge and Agent Boundaries respectively, so older documentation and blog posts still use the previous names. Coder Agents, in beta since 05-06-2026, is self-hosted and model-agnostic and supersedes Coder Tasks, which is scheduled for removal from new mainline releases starting with v2.37 on 09-01-2026 - a published plan rather than a shipped change, with a twelve-month Extended Support Release from 06-02-2026 for Premium customers. Modules exist for Codex, Cursor, Kiro, and other agent CLIs, with scoped API keys for secure automation.
Ona (formerly Gitpod)
Ona rebranded from Gitpod in September 2025, moving from a pure CDE platform to an AI agent development platform. Ona Environments remain the secure, ephemeral CDEs that Gitpod pioneered, now paired with Ona Agents, which generate code, run commands, open pull requests, and respond to review feedback. Workspace configurations can connect to shared sandbox infrastructure for resource-efficient testing.
Two constraints matter when you evaluate it. There is no customer-managed self-hosted Ona: the closest option is Ona-managed runners deployed into your own AWS or GCP VPC, and that is Enterprise plan only, so an air-gapped or fully self-operated deployment is off the table. And OpenAI announced an agreement to acquire Ona on 06-11-2026; the deal has not closed as of this writing, so confirm the roadmap and contract terms before committing.
CDE Integration
How cloud development environments and sandbox environments work together to create a seamless development and testing workflow - now with AI agent orchestration built in.
CDE Workspaces Meet Sandbox Infrastructure
The most powerful development workflow combines CDE workspaces for coding with sandbox environments for testing. In this model, developers write and build code inside a CDE workspace - a remote, cloud-based development environment with full IDE support. When they are ready to test, the CDE workspace provisions a sandbox that deploys only their changed services into the shared testing cluster.
This integration eliminates the traditional gap between development and testing. Developers do not need to push code to a CI pipeline and wait for a full environment build. Instead, their CDE workspace directly connects to the sandbox infrastructure, enabling instant testing of in-progress changes against the full service mesh.
CDE platforms like Coder and Ona can be configured with workspace templates that automatically set up sandbox connections, inject routing headers into local development servers, and tear down sandbox resources when the workspace is stopped. With Coder Agents behind Agent Firewall, or with Ona Agents, coding agents can provision sandboxes, run tests, and validate changes without a human in the loop for each step.
Template-Driven Sandbox Provisioning
Platform engineering teams can create standardized sandbox templates that abstract away the complexity of request routing and service mesh configuration. These templates define which services are sandboxable, how routing rules are applied, and what shared infrastructure is available as a baseline.
Reusable Terraform modules that provision sandbox instances with proper routing rules and network policies
Developers and AI agents request sandboxes through CDE workspace UI, CLI, or MCP without platform team involvement
Sandboxes are tied to workspace lifecycle - when the CDE workspace stops, sandbox resources are automatically cleaned up
Templates enforce resource limits, TTL policies, agent egress rules, and per-team sandbox quotas to prevent sprawl
CDE + Sandbox Architecture
How CDE workspaces connect to sandbox infrastructure for seamless development, testing, and AI agent orchestration
CDE Workspace
Developer or AI agent operates in a remote workspace with full IDE, build tools, and Git integration
Agent Layer
AI agents provision sandboxes via MCP or SDK, run tests, and validate changes autonomously
Sandbox Layer
Changed services deployed in microVM-isolated sandboxes with routing rules for targeted traffic
Shared Cluster
Baseline services, databases, and infrastructure shared across all sandboxes and workspaces
Cost-Benefit Analysis
The economics of sandbox environments versus full environment duplication, with real-world cost projections.
Why Sandboxes Cost Less
The cost savings from sandbox environments come from a simple principle: most of the infrastructure in a typical development or staging environment is unchanged between tests. When you duplicate an entire environment for each developer or PR, you are paying for dozens of identical copies of services that nobody modified. Sandboxes eliminate this waste by sharing the unchanged baseline.
In a typical microservices application with 20-50 services, a developer's change usually touches 1-3 services. With full duplication, you are paying for 20-50 service instances per environment. With sandboxes, you pay for 1-3 instances plus the shared baseline that serves all developers. The math is straightforward: if you have 20 developers each needing isolated testing, full duplication requires 20x your full stack, while sandboxes require 1x your full stack plus roughly 20 x 2 additional service instances.
Beyond compute savings, sandboxes also reduce storage costs (no per-environment databases), networking costs (shared ingress and service mesh), and operational overhead (one baseline to maintain instead of dozens of full environments). For organizations running AI agents that spin up environments at machine speed, the cost multiplier of full duplication becomes even more prohibitive.
ROI and Payback Period
Organizations adopting sandbox environments typically see ROI within 2-4 months, significantly faster than the 6-12 month payback period for full CDE adoption. The initial investment is smaller because sandbox tooling layers on top of your existing Kubernetes infrastructure rather than requiring a new platform. The ongoing savings are immediate and compound as team size grows.
Beyond direct infrastructure savings, sandbox environments deliver productivity ROI through faster feedback loops. Developers who previously waited 10-15 minutes for a full environment to provision can have a sandbox running in seconds. Over a team of 20 developers running 5-10 test cycles per day, this time savings alone justifies the tooling investment. AI agents amplify this further - an agent running 50-100 test cycles per day in millisecond-launch sandboxes can validate changes at a pace impossible with traditional environments.
The ROI improves further when you factor in the reduction in shared staging environment conflicts. Teams that previously queued for access to a single staging environment can now run unlimited concurrent sandboxes, eliminating the bottleneck that causes context-switching and delayed releases.
Example: 20-Developer Team, 40-Service Application
Monthly infrastructure cost comparison for concurrent isolated testing
Full Duplication
20 full environments x 40 services each x $60/service/month
800 total service instances running
Sandbox Approach
1 shared baseline (40 services) + 20 devs x 2 sandboxed services x $60
80 total service instances running
Monthly Savings
90% reduction in infrastructure spend
$518,400 annual savings
Database Cost Savings
Shared databases with tenant-level isolation eliminate the need for per-environment database instances, reducing storage and licensing costs by 80-95%.
Developer Time Savings
Sandbox spin-up in seconds versus minutes for full environments. Over 20 developers averaging 8 test cycles daily, this saves 40-80 hours of wait time per month.
Operational Overhead
One shared baseline to maintain instead of dozens of full environments. Platform teams spend less time on environment provisioning and more time on developer experience improvements.
Next Steps
Explore related topics to deepen your understanding of sandbox environments and cloud development infrastructure.