Platform · Agents

KERNSTACK Agent sandboxes

Agent Sandboxes are where coding agents work on KERNSTACK: each sandbox is an agent/<id> branch in hosted git, deployed to its own agent-<id> environment that runs the branch’s full stack. The project’s @agent builds demos there from conversation mentions; external harnesses (Cursor, Claude Code, Codex, Pi) produce the same branch-shaped work. Main is never the sandbox’s business.

Agent Sandboxes

Talk to us Read Agent sandboxes Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK Agent sandboxes

Teams otherwise hand an agent a laptop checkout and production credentials, then review prose about what it did. On KERNSTACK the agent’s work is a running environment and a readable plan, and its blast radius is a branch that can be discarded whole.

How a sandbox runs

Enable Agents under Settings (code mode needs hosted git), then mention @agent in a project conversation: it builds on a fresh agent branch, deploys the agent- environment, and replies with the link. Anyone can open the demo, check out the branch locally (kernstack git checkout agent/), and read kernstack plan for the platform-level summary of what the change would do.

Boundaries that are enforced, not requested

Deploying an agent branch outside its own environment demands confirmation. Production deploys can require review-approved source through the stack’s deploy gate. Destructive plan entries refuse without a human’s --confirm-destructive. Promoting sandbox work is a deliberate branch move (feature/, offered at the switch); discarding retires branch and environment together.

Sandbox environments carry their own seeded data — agents never practise on production rows
Sandbox compute spends from the project balance, visibly, and idles at storage cost
Every harness produces the same artifacts: branch, environment, plan — one review culture for all agents

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call Agent sandboxes without external credentials:

Go SDK: kernstack CLI and console (no SDK client)
Node.js SDK: kernstack-sdk
Python SDK: kernstack_sdk
PHP SDK: kernstack/sdk (Composer)

Agent sandboxes in the Project Graph

Declarestack.jsonagent-sandboxes

RunAgent sandboxesintelligence

MeterOne credit balanceEU zone

stack.json — agent-sandboxes configuration plan · deploy

{
  "stack": { "target": "shop.agent-f16b48f8", "min_source_assurance": "review_approved" },
  "resources": {
    "functions": [{ "name": "api" }],
    "tables": [{ "name": "orders", "key_name": "order_id", "key_type": "S", "indexes": [] }]
  }
}

Metering · compute, storage, or network 1 Shared Balance

Usage draws from the same credit balance as compute (0.01 credits/GiB-s), storage (0.04 credits/GB-hour), and egress (9.00 credits/GiB).

Replaces: no direct equivalent · no direct equivalent · no direct equivalent

FAQ

Frequently asked questions

Which agents can use the sandboxes?

The project’s @agent and any external coding harness that works in a repository — Cursor, Claude Code, Codex, Pi. The sandbox is a branch-and-environment contract, not a model integration, so new harnesses qualify by producing branches.

Can a sandbox reach production data?

Its environment is its own target with its own tables, buckets, and keys, seeded from the repository. Reaching production would require deploying there, which is exactly the gated, confirmed step the sandbox exists to separate from experimentation.

What does a sandbox cost?

Its environment’s storage (0.04 credits per GB-hour) plus compute while it runs or is clicked. Idle sandboxes trend to pocket change, and discarding one ends the meter with the environment.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →