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:

The second kind is what replaces a turn at a shared staging environment, a tradeoff covered in the complete guide to staging environments.

• 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 to create a Kubernetes sandbox

The right way to create a sandbox follows from which of the two meanings you need.

For learning and experimentation. If “sandbox” just means a safe cluster to poke at, run one locally with kind or minikube, or use a hosted playground. Nothing you break matters, and teardown is one command.

For running untrusted or AI-generated code. Define a RuntimeClass backed by a hardened runtime such as gVisor or Kata Containers and schedule the untrusted pods onto it, or use a purpose-built controller like agent-sandbox, which wraps this in a Sandbox custom resource with stable identity and persistent storage. The boundary you get is the point: the code cannot touch the host kernel or other tenants.

For testing a change against real dependencies. Copying the stack into a namespace or a separate cluster per change works at small scale, but the cost and spin-up time grow with every service. The request-level approach avoids that: a short spec forks only the workloads you changed onto the shared baseline cluster, and a routing key steers matching requests to your version. With Signadot that spec looks like this:

name: my-feature
spec:
  cluster: staging
  forks:
    - forkOf:
        kind: Deployment
        namespace: hotrod
        name: route
      customizations:
        images:
          - image: myrepo/route:pr-42

Applying it creates a sandbox in seconds. Requests carrying the sandbox’s routing key hit your forked service; every other request flows through the untouched baseline. The Kubernetes test environments page covers how teams run this pattern at scale.

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.

Frequently asked questions

What is a Kubernetes sandbox?

A Kubernetes sandbox is a temporary, isolated place to run or test something on a cluster without affecting everything else. The term covers two different things: a secure execution box for running untrusted or AI-generated code (using gVisor, Kata Containers, or microVMs), and a lightweight test environment where a code change runs against the real services on a shared cluster.

What is the difference between a Kubernetes sandbox and a namespace?

A namespace is a logical grouping inside a cluster, but workloads in one namespace can still reach services, queues, and databases in another, and copying a full stack into a namespace per change is slow and expensive. A sandbox adds an actual isolation boundary: either a hardened runtime around untrusted code, or request-level routing that isolates one change's traffic while sharing the rest of the cluster.

Is a Kubernetes sandbox the same as agent-sandbox?

No. agent-sandbox (kubernetes-sigs/agent-sandbox) is a specific open source project that adds a Sandbox custom resource for running AI agent workloads in isolation, using gVisor or Kata Containers. It belongs to the run-something-safely camp. A testing sandbox, like Signadot's, answers a different question: whether a change works against its real dependencies.

How do I create a Kubernetes sandbox?

It depends on which kind you need. For a safe place to learn or experiment, run a local cluster with kind or minikube. For running untrusted code, use a hardened runtime such as gVisor or Kata Containers via a RuntimeClass, or the agent-sandbox controller. For testing changes against real services, use a platform like Signadot: apply a short sandbox spec that forks only the workloads you changed on a shared baseline cluster.