Prepare a repo
Clone a repository, inspect files, install dependencies, run tests, and return a concrete status without touching the user machine.
Cloud for Agents
A cloud built around agent work
Agents need more than a prompt and a model call. They need a place to run, a way to keep state, a boundary for approvals, and somewhere to publish what they produced.
Clanker Cloud sandboxes give agents a hosted workspace for commands, repo work, tool calls, workflow records, traces, handoff memory, and hosted outputs.
Current Clanker DevOps and Clanker Secretary /sites/{slug}/ documents are public and share a Worker hostname, but each document is forced into an opaque-origin CSP sandbox without allow-same-origin. It cannot use or read shared cookies, localStorage, IndexedDB, Cache Storage, or service workers, and cannot read another tenant's document or a same-origin API response through browser APIs.
A useful agent run needs a runtime, state, audit trail, approval gates, and an output. Clanker Cloud makes those pieces part of the sandbox.
Agent work
What agents can do in Clanker Cloud
Run a workflow
Create a workflow record, append traces, store handoff memory, and pause before side effects.
Publish a result
Use an active Clanker DevOps or Clanker Secretary plan to publish a public simple-static report, review page, compatibility-tested preview, or run status from the sandbox.
Hand off cleanly
Keep enough non-secret context in memory and traces for the next agent to continue without rereading the whole task.
Connect to DevOps
Use Clanker DevOps and MCP when the agent needs live infrastructure context or reviewed production action.
Automate repeat work
Turn stable agent runs into recurring workflows hosted on Clanker Cloud; private enterprise deployment requires a separately delivered and verified environment.
Sandbox runtime
Create hosted sandboxes for agents that need a shell, workspace, and clean execution boundary.
Workflow state
Record the job, steps, traces, approvals, memory, and artifacts with the sandbox instead of scattering state across prompts.
Human gates
Ask for approval before publishing, deleting, sending, installing, changing accounts, or touching production systems.
Hosted outputs
Active Clanker DevOps and Clanker Secretary accounts can publish public simple-static reports, compatibility-tested previews, and status pages from the sandbox.
Hosted-site limits
Classic scripts and forms remain allowed. ES modules and applications that depend on browser storage or readable same-origin APIs may fail. Use /sites for simple static reports, status pages, handoff documents, and compatibility-tested previews; do not publish secrets or confidential customer data or work around the isolation header.
Government hosting
Protected, sovereign, and government hosting is not currently available. Per-site tenant-isolated registrable origins and a separately contracted, verified environment are required before those workloads can use hosted sites.
Supported providers
Works across the environments teams already run
The current product positioning covers cloud providers, Kubernetes, GitHub, and bring-your-own AI keys from one local operating surface.
Supports ->GitHubKubernetesBYOK
Sandbox tiers
Where each sandbox type fits
| Caller | What it gets | Best for |
|---|---|---|
| Anonymous | One-hour sandbox with a sandbox token returned at create time. | Trying the API, short commands, demos, and quick agent tests. |
| Free account | Account-owned sandbox that lasts about eight hours. | Normal work sessions, repo checks, and agent experiments. |
| Clanker DevOps / Secretary | Larger Standard compute with no preset expiry, public opaque-origin static sites, and /explain. | Long-running workflows, team runs, simple reports, tested previews, and heavier agent environments. |
| Secretary Pro / contracted sovereign | Protected runtime blocked until activation. | No Standard fallback or self-service protected placement. |
Build with it
Start from the API or the product surface
FAQ
Common questions
Is this only for coding agents?
No. Coding agents are a common starting point, but the same sandbox model works for research workers, office automation workers, DevOps helpers, and custom internal agents.
Where should secrets live?
Do not put secrets in sandbox memory or trace records. Use the user account, Clanker Cloud settings, the desktop boundary, or the customer-controlled secret path for private deployments.
Next step
Create the first sandbox
Use the sandbox API for a hosted runtime, then add workflow records and approvals when the run becomes more than a one-off command.