Choose where sandboxes run
Docker, Kubernetes, Daytona or your own machines: what each needs, how it isolates, and what it costs.
Every session runs its commands in a sandbox: a machine of its own that Pistis can throw away. The session itself lives on your Pistis server, so wherever sandboxes run, the work survives a lost sandbox: a new one starts with the files as they were at the end of the last turn. What changes is what you run, how strongly sandboxes are kept apart, what they can reach and what you pay for.
| Docker | Kubernetes | Daytona | Your own machines | |
|---|---|---|---|---|
| Needs | Docker on the Pistis server. Nothing else. | A cluster and a namespace for sandboxes; the Helm chart sets it up. A network plugin that enforces NetworkPolicy. | A Daytona account (their cloud or your own install) and its API key. The sandboxes must reach your Pistis server's public address. | Machines you run, each with Pistis's sandbox program joined to a pool with a pool token. |
| Isolation | A container per sandbox, sharing the server's kernel. CPU, memory and process limits per sandbox. | A pod per sandbox: no service account token, no privilege escalation, the default seccomp profile, and a stronger runtime such as gVisor or Kata when the cluster has one. | Daytona's own sandboxes, on their machines or yours. | Yours to choose: Pistis doesn't start, stop or fence these machines. |
| What it may reach | Nothing by default; an allow list of hosts through a proxy that logs each request; or the internet but not other sandboxes. | Nothing but Pistis by default; or the internet, never private address ranges. | Daytona's settings: block everything, or an allow list of address ranges. | Whatever your network allows. |
| Pause when idle | Yes, with its memory: a paused sandbox resumes where it was. | No: an idle sandbox is deleted and comes back with its files on the next command. | If you turn it on; otherwise it stops and restarts with its files. | No: the machine stays as you run it. |
| Cost | Your server's CPU and memory; sandboxes add up on one machine. | Your cluster's nodes, which can grow and shrink with the load. | Daytona's price for the time sandboxes run, or your own install's machines. | Machines you already have. |
| Good for | One team on one server, and trying Pistis. | Many sessions at once, and teams that already run a cluster. | Not running sandbox machines yourself. | Hardware or networks the agent must use, such as a GPU or a build farm. |
How to choose
- Start with Docker. It is the default, needs nothing beyond the server, and pauses idle sandboxes so a session picks up in a moment.
- Move to Kubernetes when one server is too small, or when you want a stronger wall between sandboxes than a shared kernel: give the chart a runtime class such as gVisor.
- Use Daytona when you'd rather not run sandbox machines at all. Its sandboxes dial out to your server, so nothing needs to reach into them.
- Add your own machines for work that needs something special. Since Pistis doesn't fence them, use them for trusted work, and keep keys out of them as you would anywhere.
What stays the same everywhere
Pistis's own keys never enter a sandbox, a command the agent ran is never run twice, and the workspace is saved after each turn. Approvals, the record of what happened and who decided what live on your server, whichever you choose.
Set it up
- Docker: Run it for a team.
- Kubernetes: Run it on Kubernetes.
- Daytona: Sandboxes.
- Your own machines: Use your own machines.
- Whatever the place, give the sandbox your toolchain: Give the sandbox what it needs.
The pistis command includes the Docker, Kubernetes and Daytona providers. To use one in your own server, embed the engine and install it from npm:
npm i @pistishq/sdk # @pistishq/sdk/sandbox-docker, /sandbox-kubernetes, /sandbox-daytona