What Is a Sandbox Environment? Types and Setup

What a sandbox environment is

A sandbox is a space where something can be run, broken and thrown away without consequence. In software delivery the thing being run is usually a build of your application, together with its configuration and some data. The sandbox gives it its own compute, its own network path, its own credentials and its own data, so a failed migration, a runaway loop or a bad feature flag stays inside the boundary.

The test of a real sandbox is the blast radius. Ask what a worst-case change could touch. If the answer includes production database credentials, a shared message queue or a live payment key, the environment is only a test copy, not a sandbox. Good sandboxes are also disposable. They are cheap to create, cheap to reset and easy to delete, so nobody is afraid to use them.

The three kinds of sandbox

Most confusion comes from the word itself. Three kinds of sandbox appear in practice, and they share the idea of isolation but little else.

Developer sandboxes

A developer sandbox is a running copy of the application stack that one person or one branch uses to try changes. It can be a shared environment that a team resets on a schedule, or a per-developer namespace in a cluster. This is the sense most DevOps teams mean.

Vendor and API sandboxes

Many SaaS and payment providers offer a sandbox or test mode. It is a separate API host or a set of test credentials that accept requests but move no real money and touch no real customer records. Your integration points at the test host during development, and you switch to live credentials only in production. The exact key formats, test data rules and webhook behaviour differ by provider, so read the official documentation for the service you use. Do not assume one provider's conventions apply to another.

Security sandboxes

In security, a sandbox is a restricted execution environment for code that you do not fully trust. A web browser is the most common example: each tab's rendering process runs with limited access to the operating system and to other tabs. Malware analysis uses the same idea in a dedicated system, where a suspicious file is run and its behaviour observed without it reaching the analyst's machine or network. The principle is the same as the developer kind. The purpose is containment rather than testing.

Sandbox vs dev, test, staging and production

Naming varies between teams, so treat the table as a common pattern rather than a standard. The useful column is the last one: how close the environment sits to real data and real users.

The difference between a sandbox and staging is intent. Staging is a rehearsal: it should match production closely, so that a release that passes there is expected to pass in production. A sandbox is a playground: it is allowed to differ from production, to be reset often and to hold experimental changes. Use staging to answer “will this release work” and a sandbox to answer “what happens if we try this”.

Per-pull-request preview environments

The most useful modern form of the developer sandbox is the ephemeral preview environment. Each pull request or commit gets its own deployment, reachable at its own URL, and it is removed when the work is merged or closed. Reviewers can click through a real build before anything reaches the main branch, and nothing about the preview is shared with production traffic.

SeaGit implements this as ephemeral deployments on Amazon EKS in your own AWS account. The behaviour below follows the product documentation and the preview environments feature page.

• A push or pull request triggers a webhook build. CI/CD targets only non-main deployment slots. A commit SHA that already has a slot re-triggers that slot.
• Each ephemeral deployment gets its own URL in the form dep-name.domain.com and ships as its own Helm release. It runs inside the same environment as the main deployment.
• The number of ephemeral slots is capped per environment by max_deployments_per_instance. At the limit, push to an existing slot or remove one before a new slot can be created.
• Once a preview has been validated, Promote copies its configuration and deploys it to the main slot, and Mark as main moves the main flag to that slot. Both are available in the UI and the API.

The isolation boundary here is the release and the URL, inside one environment. It is not a separate cluster per preview. Before you treat a preview as safe for experiments, check which add-ons and data stores it shares with main in your setup.

What makes a good sandbox

A sandbox is only useful if people trust it and use it. These six properties do most of the work.

• Isolation: no network path to production databases, queues or internal admin tools, and no credentials that work outside the sandbox.
• Prod-like configuration: the same runtime versions, manifests and service topology as production, so that a result here means something. Keep the secrets separate even when the shape matches.
• Synthetic or seeded data: generated records that look realistic, not copies of real customer data. Copying production personal data into a lower environment creates a compliance problem that is hard to undo.
• Scoped secrets: sandbox-only keys for every vendor integration, rotated like any other secret and never reused from production.
• Cost control: an owner, a time limit and automatic teardown. An abandoned environment is a cost leak and a stale attack surface.
• Reproducibility: the whole environment is defined as infrastructure as code, so it can be recreated from scratch in minutes rather than maintained by hand.

How to set up a sandbox on Kubernetes

On Kubernetes, the building blocks are a namespace, a quota, a network policy, and a Helm release or manifest set deployed into them. The namespace guide explains what a namespace scopes and what it does not isolate. The short version is that a namespace gives you a name scope, a quota target and a place to attach policy. It is not a security boundary on its own.

# One namespace per sandbox, named after the branch or PR
kubectl create namespace sandbox-pr-42

# Deploy the application stack into it with its own release name
helm upgrade --install my-app ./chart \
  --namespace sandbox-pr-42 \
  --set environment=sandbox

A ResourceQuota caps what the sandbox can consume, so one forgotten environment cannot starve the others on the cluster. Pair it with a default-deny NetworkPolicy so that traffic into the namespace is blocked until a policy allows it. The network policy example shows allow rules in detail.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: sandbox-quota
  namespace: sandbox-pr-42
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "20"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: sandbox-pr-42
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Keep the sandbox's Secrets in its own namespace, created from the sandbox's own vendor keys. Give the people who use it only the RBAC they need, usually edit rights in that namespace and no access to the production namespaces. Teardown is then one command. Deleting the namespace removes the objects inside it. If deletion hangs, see the namespace stuck in Terminating guide.

Common pitfalls

Most sandbox failures are not technical. They are drift, leakage and neglect.

• Drift. The sandbox runs a different database version or a missing service, so tests pass there and fail in production. Generate sandbox manifests from the same chart as production and override only what must differ.
• Accidental sharing. A sandbox points at the production database, the shared Redis or a real webhook endpoint because a connection string was copied. Check the resolved endpoints, not the template.
• Copied production secrets. A developer pastes live keys into a sandbox to make an integration work. Keep sandbox and live credentials in separate stores, and rotate anything that crossed the line.
• Public exposure without auth. A preview URL is reachable from the internet with no login and shows unreleased features. Put previews behind access control if they show anything confidential.
• Forgotten environments. Nobody deletes the sandbox after the PR merges, so cost and attack surface accumulate. Automatic teardown on merge or after a fixed idle time removes the need to remember.
• Treating a namespace as a security boundary. A namespace limits names and scopes policy. It does not stop a workload from reaching other namespaces unless network policy and RBAC say so.
• Unrealistic data. A sandbox seeded with five clean rows will never show the bug that appears with real-world shape and volume. Generate synthetic data with the same size, nulls and edge cases.

Frequently asked questions