Limits & defaults
The numbers a buyer needs before choosing CreateOS Sandbox for a workload, on one page, each with the API field it comes from. Everything here was read back from the live control plane (https://api.sb.createos.sh) on 2026-09-07 and re-verified on 2026-09-08; where a value is per-account it says so and tells you which call returns yours.
Sizes (shapes)
GET /v1/shapes is public and is the source of truth. As of 2026-09-07:
| Shape | vCPU | Memory | Default disk |
|---|---|---|---|
s-0.25vcpu-512mb | 1 (25% quota) | 512 MiB | 10 GiB |
s-0.5vcpu-1gb | 1 (50% quota) | 1 GiB | 10 GiB |
s-1vcpu-256mb | 1 | 256 MiB | 10 GiB |
s-1vcpu-1gb | 1 | 1 GiB | 10 GiB |
s-1vcpu-2gb | 1 | 2 GiB | 10 GiB |
s-2vcpu-2gb | 2 | 2 GiB | 10 GiB |
s-2vcpu-4gb | 2 | 4 GiB | 10 GiB |
s-4vcpu-4gb | 4 | 4 GiB | 10 GiB |
s-4vcpu-8gb | 4 | 8 GiB | 10 GiB |
Disk can be raised per sandbox with disk_mib at create time, up to the plan's maximum disk (see below). The largest shapes (4 vCPU / 8 GB and 8 vCPU / 8 GB on Pro, 8 vCPU / 16 GB on Enterprise) unlock with the plan. No GPU shapes are offered.
Images (rootfs)
GET /v1/rootfs is public. Five first-party images are kept warm on every host:
| Image | What is in it |
|---|---|
devbox:1 | Ubuntu 24.04 LTS · Python 3.12 with pip and uv and the common data and AI packages preinstalled (verified by exec on 2026-09-08: pandas 2.3, numpy 2.4, scipy 1.17, matplotlib 3.10, pyarrow 21, openpyxl, scikit-learn 1.8, plus openai, anthropic, langchain, llama-index, transformers, requests; 374 packages in total) · Node.js 24 · Bun 1.4 · Go 1.26 · Rust 1.83 · Docker 29 · SSH. PyPI is reachable under the default egress policy for anything else. |
desktop:1 | Graphical desktop with XFCE, Google Chrome, remote desktop and computer-use APIs. |
ubuntu:26.04 | Ubuntu 26.04 LTS, minimal. |
debian:13 | Debian 13, minimal. |
alpine:3.20 | Alpine 3.20, minimal. This is the catalog default when rootfs is omitted; pass devbox:1 explicitly for a development toolchain. |
Need a package set beyond what devbox:1 ships, or a pinned one? Build it once from a Dockerfile with Templates and boot every sandbox from it.
Lifetime, idle and cleanup
| Behaviour | Value | Field |
|---|---|---|
| Maximum session length | None. A sandbox runs until you destroy it, pause it, or it auto-pauses. There is no lifetime cap to fit a job inside. | — |
| Auto-pause on idle | Off by default. Set auto_pause_after_seconds (60–86,400) to pause after that long with no exec, file transfer or tunnel activity. | auto_pause_after_seconds |
| What "pause" means | A Firecracker snapshot to durable storage: memory, registers and device state. Compute billing stops; the sandbox is not destroyed and keeps its disk. | Pause, Resume & Fork |
| Destroy | Explicit DELETE /v1/sandboxes/{id}. Idempotent on an already-terminal sandbox. For one-sandbox-per-run workloads, call it in a finally block; do not rely on idle pause as cleanup. | DELETE /v1/sandboxes/{id} |
| Time to interactive | ~210 ms median, ~250 ms p95 (create plus first command). | Sandboxes |
Concurrency and plan limits
Caps are set by plan (source: the control plane's plan table, 2026-09-08). GET /v1/whoami returns your running count, which is what the concurrent cap is measured against; a create that would exceed it fails rather than queueing. There is no queue and no burst pool: size the plan to your peak.
| Plan | Concurrent sandboxes | Sandboxes per day | Networks (concurrent / day) | Disks (concurrent / day) | Templates (concurrent / day) | Max disk | Largest shape |
|---|---|---|---|---|---|---|---|
| Free | 1 | 10 | 1 / 10 | 0 / 0 | 0 / 0 | 10 GiB | 1 vCPU / 1 GB |
| Beginner | 5 | 50 | 5 / 50 | 5 / 50 | 5 / 50 | 30 GiB | 4 vCPU / 4 GB |
| Pro | 20 | 200 | 20 / 200 | 20 / 200 | 20 / 200 | 50 GiB | 8 vCPU / 8 GB |
| Enterprise | 30 | 300 | 30 / 300 | 30 / 300 | 30 / 300 | 60 GiB | 8 vCPU / 16 GB |
Sizing rule of thumb: a workload of ten concurrent five-minute runs needs Pro. Free is for trying the API (one sandbox at a time, no disks or templates); Beginner covers a small service; Enterprise caps are the starting point for a negotiated limit, not a ceiling. Plan prices are on the pricing page.
Network
| Behaviour | Default | Field |
|---|---|---|
| Inbound (ingress) | Closed. Nothing reaches a sandbox unless ingress_enabled: true, which exposes one HTTPS URL per sandbox. | ingress_enabled |
| Outbound (egress) | Open when the rule list is empty: the sandbox can reach any external host. Set an allowlist before running untrusted or model-generated code. Once any rule is present, only listed destinations pass; everything else is dropped in-kernel on the host, outside the VM, and cannot be changed from inside it. Rules take host, host:port, *.host, ip, ip:port and cidr[:port], and apply live. | egress on create, Egress |
| Sandbox-to-sandbox | Private overlay networks, opt-in per sandbox. | networks |
| Bandwidth budget | 5 GiB per sandbox by default; grow it with POST /v1/sandboxes/{id}/bandwidth/recharge. | bandwidth_quota_bytes |
A deny-by-default Python job needs exactly two rules:
JSON
Secrets and environment
envs at create time: up to 64 keys, 4 KiB per value, 64 KiB total. Values are write-only (GET returns key names). Per-exec overrides may change a declared key's value but cannot introduce new keys, so a sandbox can never receive a secret you did not declare when you created it. Keep production credentials on the caller's side; the sandbox only needs the data file and non-secret configuration.
Regions and residency
region at create time: eu or us, and it must match the control plane you are talking to. For data that must not leave your boundary, run on your own infrastructure and bring your own storage.
Billing
Per-second, while running: $0.0504 per vCPU-hour plus $0.0162 per GiB-RAM-hour, no egress fees, no charge while paused. New accounts start with 500 free credits. Full rate card: pricing.
Status and compliance
CreateOS Sandbox is in alpha: APIs may change and it is not yet covered by an SLA. Certifications are in progress; ask for the current letter before committing regulated workloads, and use self-hosting as the interim control. Reliability behaviour under OOM, CPU spin and runaway processes is documented in Reliability.