Isolated Runtimes
How per-tenant isolation works under the hood, and why we made it the default.
Every customer of yours gets their own runtime. Not a shared process with namespaces. An actual separate container with its own filesystem, env vars, network identity, and resource budget.
Why we don't share runtimes by default
Shared AI runtimes break in ways that are hard to recover from once you've got real traffic.
Prompt injection: one tenant's malicious input can leak data from another's session. State leakage: caches, vector stores, scratch files bleed across tenants if they share a process. Resource starvation: one tenant's runaway loop slows everyone down. Compliance: a lot of enterprise contracts require dedicated infra and shared runtimes don't qualify.
So we just don't share. One container per tenant. No noisy neighbors, no shared state, no shared memory.
How it works
When a tenant signs up, the control plane (PakClaw) gets a provision request. A Docker container starts with the tenant's slug as its identity. Env vars and secrets get injected at boot. Skills authorize against the tenant's own credentials, never against global ones. A subdomain routes to the container.
When you deploy a new blueprint version, every tenant's runtime updates in parallel.
What's per-tenant
| Resource | Per-tenant |
|---|---|
| Container and process | Yes |
| Filesystem | Yes |
| Env vars | Yes |
| Skill credentials (Gmail, Slack, etc) | Yes |
| Conversation state | Yes |
| Vector and cache stores | Yes |
| CPU and memory budget | Yes |
| Public URL | Yes (<tenant>.<your-domain>) |
What's shared
The blueprint code, the skill catalog, and the platform observability layer. None of those expose tenant data.
Failure containment
If a tenant's runtime crashes or OOMs, ShipClaw restarts that container. Other tenants don't see anything. You'll get the incident in Monitoring.
What it costs
Each runtime uses real compute. We charge per active runtime per month, with auto-pause for idle bots. See Billing.