What Is a Kubernetes Sandbox?

Search for “Kubernetes sandbox” today and you get two unrelated answers. One is a secure box for running untrusted or AI-generated code. The other is a lightweight, isolated environment for testing a code change against real services. They share a name and almost nothing else. This page explains both, so you can tell which one you actually need.

The short version

A Kubernetes sandbox is a temporary, isolated place to run or test something on a cluster without affecting everything else. The term splits into two camps:

• Run-something sandboxes care about safety. They give code you don’t fully trust, often code an AI agent just wrote, its own locked-down place to execute so it cannot touch the host or other tenants.
• Test-something sandboxes care about fidelity. They let a developer or an agent try a change against the real services, databases, and queues it will run with in production, without copying the whole stack.

If you are running code you don’t trust, you want the first kind. If you are checking whether a change works, you want the second. Signadot builds the second kind.

A sandbox for running code safely

This is the meaning that has taken over the term lately, pushed by AI coding agents. When an agent writes and runs code on its own, that code needs somewhere isolated to execute. Two layers of tooling cover this.

At the lower level are general execution sandboxes that will run code from any kind of agent, not just a coding one:

• E2B runs each session in a Firecracker microVM, so the code gets its own kernel and a hardware-level boundary.
• Daytona focuses on fast startup for running AI-generated code, with an SDK that agents call to open a session.
• agent-sandbox, a Kubernetes SIG project (kubernetes-sigs/agent-sandbox), adds a Sandbox custom resource for long-running, stateful agent runtimes, using gVisor or Kata Containers for kernel and VM-grade isolation.

A layer up are environments built specifically for coding agents. Ona (formerly Gitpod) is one example: it gives each software engineering agent a full, isolated cloud workspace to read the repo, write code, run it, and open a pull request. The focus here is the development workflow, not just safe execution.

The common thread across both layers is the same: they isolate where code runs. The question they answer is “where can this agent do its work without doing damage?” None of them tell you whether the change is actually correct against your real services.

A sandbox for testing a change

This is what Signadot means by a sandbox. Here the problem is not safety. It is that you cannot tell if a change works until it runs against its real dependencies. Spinning up a full copy of thirty services for every change is slow and expensive, and a single shared staging environment turns into a queue.

A Signadot Kubernetes sandbox solves this with tunable isolation. You start from a shared, production-like baseline cluster and decide, for each change, what to isolate and what to borrow from the baseline. For the services you are changing, a routing key on each request sends traffic to your version while everything else falls through to the baseline. For stateful dependencies you isolate as much as the test needs: resource plugins spin up ephemeral database instances on demand, and for message queues you either route messages by the same key or spin up ephemeral topics. Because you choose what is shared and what is forked, you get a high-fidelity, production-like environment without copying the whole stack, and many developers or agents can run their own sandboxes on the same cluster at once.

This is the same idea behind ephemeral environments in Kubernetes: start from a shared baseline and isolate only what each change needs.

	Execution sandbox	Coding-agent environment	Signadot sandbox
Examples	E2B, Daytona, kubernetes-sigs/agent-sandbox	Ona (formerly Gitpod)	Signadot
What it does	Runs any code in isolation	Hosts a coding agent so it can write and run code	Tests a change against real services in a cluster
Scope	Any agent	The coding workflow	The coding workflow
Answers	Can this run safely?	Where does the agent work?	Does this change actually work?

How they fit together

These pieces are complementary, and the coding case is where they line up best. A coding agent can run inside an environment like Ona, where it has a workspace to read the repo, write code, and open a pull request. That covers writing and running the code. It does not cover whether the change works against the rest of your system.

That is the gap Signadot fills. You connect the agent’s environment to a real Kubernetes cluster and run the change against live services, databases, and queues, the same dependencies it will meet in production. The coding agent writes the change in a host like Ona, and Signadot lets it run integration and system tests against the real cluster before the pull request merges.

So the split is clean. A tool like Ona hosts the agent and its workspace. Signadot handles the integration testing and verification against real dependencies. One proves the code can run. The other proves the change does what it should. For more on that step, see validating AI-generated code against real Kubernetes.

When to use a Signadot Kubernetes sandbox

• Developing locally against real cluster dependencies, without rebuilding images for every change.
• Previewing a pull request in a production-like environment before it merges.
• Running integration and end-to-end tests in parallel, one sandbox per change.
• Letting a coding agent check its own work against the real system.

For the bigger picture on testing across the lifecycle, see the complete guide to microservices testing.