Limits & quotas
Every number on this page is enforced server-side and reported live by GET /v1/sandboxes/limits (or Sandbox.limits() in the SDKs) for the calling token's tier. When in doubt, trust the API over this page - it is the same source the enforcement reads.
Per-tier limits
| Limit | Free | Pay as you go | Enterprise |
|---|---|---|---|
| Sandbox sizes | small only | small, medium, large | small, medium, large |
| Concurrent RAM budget | 2 GB (~2 small) | 32 GB | 128 GB |
| Timeout per call (countdown) | 30 minutes | 24 hours | 24 hours |
| Max continuous running time | 1 hour | unlimited | unlimited |
| Paused sandboxes held at once | 1 | 10 | 50 |
| Paused snapshot retention | 7 days | 30 days | no expiry |
| Custom templates | 1 | 15 | 50 |
| Persistent volumes | 1 | 10 | 50 |
| Total provisioned volume storage | 10 GB | 200 GB | 2 TB |
| Custom egress allowlist | yes | yes | yes |
| Public preview URLs | no | yes | yes |
Sandbox sizes
| Size | vCPU | Memory | Availability |
|---|---|---|---|
| small | 1 vCPU | 1 GB RAM | default size |
| medium | 2 vCPU | 4 GB RAM | paid tiers |
| large | 4 vCPU | 8 GB RAM | paid tiers |
The concurrent RAM budget is the real concurrency gate: a create is refused once the sum of your live (non-paused) sandboxes' memory plus the new one would exceed it. Paused sandboxes free their RAM, so parking sessions raises how many you can hold.
Fixed limits (all tiers)
- Sandbox lifetime: 10 seconds to 24 hours per create, capped by your tier's
max_timeout_seconds. Default 600 seconds. That value is only the countdown length of a single call, not a ceiling on total runtime. - Keep-alive & the running cap: calling
set_timeoutrestarts the countdown so an active sandbox is not reaped mid-task. On the free tier a single continuous running window is capped at 1 hour (max_running_lifetime_seconds) no matter how many times you extend; once it is used up, keep-alive is refused and you pause then resume to start a fresh window. Carded tiers are uncapped. - Per-exec timeout: 1 to 3600 seconds, default 60. A timed-out command leaves the sandbox alive.
- File transfers: 16 MiB per one-shot files-API request (base64 over HTTPS). Batch write moves up to 64 files / 48 MiB per call; pre-signed URLs move larger files directly over plain HTTP - uploads up to 512 MiB, downloads unbounded. See the REST API reference.
- Metadata: 16 keys per sandbox, 256 characters per value.
- Volume size: 10 GB default, 100 GB max per volume; billed on provisioned size as GB-month.
- List page size: 50 by default, 200 max.
- Lifecycle webhooks: 10 registrations per account. Deliveries are retried up to 3 attempts, 10 seconds apart; a webhook that fails 20 deliveries in a row is disabled until you re-enable it. See the REST API reference for registration and signature verification.
Compute trial and billing
Compute is not a monthly grant. Every account gets a one-time trial credit in EUR - the current amounts are shown on the product page and in trial_credit_eur from the limits API. Compute is metered per second at the public rates and drawn against the credit; it never resets. On the free tier the credit is also time-limited and ends in a hard wall; with a card on file, usage past the credit simply meters as pay as you go under your spend cap. Paused sandboxes stop the compute meter; snapshots, templates, and volumes meter as storage (GB-month).
Rate limiting
There are currently no per-request rate limits on the sandbox API. The enforced gates are the ones above - the concurrent RAM budget, the trial credit or spend cap, and the per-tier object caps. When a request is refused, the 429 or 409 response carries a machine-readable code (for example trial_exhausted, spend_cap_reached, snapshot_cap_reached) - dispatch on that rather than retrying blindly.
Need more?
The enterprise tier's envelope is a default, not a ceiling - dedicated capacity and custom limits are arranged per contract. Talk to us.