The isolation is the same on every plan.
Free
Outbound network included. Ask for access to start.
- 1 concurrent VM
- 3 tasks · 10 secrets
- 5 min max run
- Outbound network — 5 GB/month
- No webhooks, no retries
- std.micro
Starter
For jobs that need to be called back, and to stop paying the boot cost every time.
- 3 concurrent VMs · 3 warm
- 15 tasks · 25 secrets
- 30 min max run
- Webhooks — trigger runs and get called back
- Warm reuse · automatic retries
- Free +
- std.small
Team
More room to run, and the first taste of a public inbound endpoint.
- 6 concurrent VMs · 5 warm
- 40 tasks · 50 secrets
- 1 h max run · 2.5 GiB image storage
- Inbound — a public HTTPS hostname
- No pinning
- Starter +
- std.medium
Pro
Pinned VMs, continuous workloads, runs up to six hours and the memory-heavy presets.
- 12 concurrent VMs · 10 warm
- 100 tasks · 100 secrets
- 6 h max run · 5 GiB image storage
- 4 pinned VMs — kept alive, never idle-reaped
- Continuous workloads
- Team +
- std.large
- mem.large
- mem.xlarge
Enterprise
Scale, and the highest egress ceiling on the ladder.
- 24 concurrent VMs · 12 pinned
- Unlimited tasks, secrets, keys
- 12 h max run · 20 GiB image storage
- Outbound network — 10 TB/month
- Pro +
- std.xlarge
Compare everything
Every row is read straight from the published plan definitions. A dash means the capability is not granted — not that the limit is zero.
| Limit | Free | Starter | Team | Pro | Enterprise |
|---|---|---|---|---|---|
| Concurrency | |||||
| Concurrent runs | 1 | 3 | 6 | 12 | 24 |
| Pinned VMs | Not included | Not included | Not included | 4 | 12 |
| Warm VMs | Not included | 3 | 5 | 10 | 20 |
| What you can create | |||||
| Tasks | 3 | 15 | 40 | 100 | Unlimited |
| Deployments | 2 | 10 | 25 | 50 | Unlimited |
| Secrets | 10 | 25 | 50 | 100 | Unlimited |
| API keys | 1 | 3 | 5 | 10 | Unlimited |
| Webhooks | Not included | 3 | 8 | 20 | Unlimited |
| Rate | |||||
| Runs / minute | 10 | 60 | 150 | 300 | 1,200 |
| Runs / hour | 120 | 1,000 | 4,000 | 10,000 | 50,000 |
| Runs / day | 500 | 10,000 | 40,000 | 100,000 | Unlimited |
| Deployments / minute | 3 | 5 | 10 | 15 | 60 |
| API requests / sec | 5 | 25 | 50 | 100 | 500 |
| Size & time | |||||
| Max run duration | 5 min | 30 min | 1 h | 6 h | 12 h |
| Monthly compute | 20 h | No cap | No cap | No cap | No cap |
| Idle warm VM lifetime | 10 min | 1 h | 2 h | 12 h | 24 h |
| Scratch storage | 128 MiB | 512 MiB | 2 GiB | 8 GiB | 32 GiB |
| Deployment image | 256 MiB | 256 MiB | 256 MiB | 256 MiB | 256 MiB |
| Image storage | 256 MiB | 1 GiB | 2.5 GiB | 5 GiB | 20 GiB |
| Network | |||||
| Egress bandwidth | 50 Mbit | 50 Mbit | 100 Mbit | 100 Mbit | 100 Mbit |
| Monthly egress | 5 GB | 100 GB | 300 GB | 1 TB | 10 TB |
| Connections per VM | 32 | 32 | 128 | 128 | 128 |
| DNS queries / sec | 25 | 25 | 25 | 100 | 100 |
| Inbound endpoint (per route) | Not included | Not included | 50 rps | 100 rps | 1,000 rps |
| Inbound concurrent (per vCPU) | Not included | Not included | 10 | 25 | 64 |
| Capabilities | |||||
| Pin a VM | No | No | No | Yes | Yes |
| Outbound network | Yes | Yes | Yes | Yes | Yes |
| Public inbound | No | No | Yes | Yes | Yes |
| Secrets | Yes | Yes | Yes | Yes | Yes |
| Webhooks | No | Yes | Yes | Yes | Yes |
| Automatic retries | No | Yes | Yes | Yes | Yes |
| Long duration | Yes | Yes | Yes | Yes | Yes |
| Continuous workloads | No | No | No | Yes | Yes |
| Warm reuse | No | Yes | Yes | Yes | Yes |
| Retry attempts | 1 | 2 | 3 | 3 | 3 |
| VM sizes |
|
|
|
|
|
What happens when you hit a limit
Going over a quota gives a 429 with the reason, the limit, and what you actually used — and upgrading fixes it. Using something your plan does not include gives a 400 at deploy or a 403 at run, naming the capability.
What you won’t get is a 429 because the host is busy. That case returns 503, or the run is simply queued and dispatched when a slot frees. A transient full host is never reported as a plan problem, so you’re never told to upgrade when all you needed was to wait.
Changing plans
Your plan is pinned at the version you were granted. Plans are never edited in place — a price or limit change publishes a new version, and existing customers stay on theirs. We move a whole plan only to correct an error, or with notice.
Grandfathering isn’t a policy anyone has to remember here; it’s how the tier system is built.