Limits

Each plan

Compute, at once, in all projects of the account

How fast things are made

Cube

An app’s instances in a region are all it has there, awake, paused or asleep. Keyed instances are sandboxes: they count among the sandboxes awake and kept asleep, and the sandboxes made a minute and an hour, and there is no number of keys apart from those. The requests a second are counted at each edge on its own, before a request reaches an instance: past them the edge answers 429 app_rate_limited with Retry-After: 1, and the request is not counted or billed. A request with a key counts the same.

Drives and volumes, of one project

A fork of a Drive counts as a new Drive of its size. A Drive’s snapshots are not counted: a Drive may have any number, each billed for what it keeps alone. See Drive snapshots and forks.

Secrets, of one project

Logs

Connections out, on each machine

A sandbox whose network rules name hosts sends each of its TCP connections out, over IPv4 and IPv6 alike, through its machine’s egress proxy; one with no rules, or rules of addresses alone, does not. On each machine, the account’s sandboxes there share the number above, together, however many projects they are of. Past it, their new connections are refused, in words that say to try again (the first request of a plain HTTP connection is answered 503 egress_connections_full, retryable; a TLS handshake ends with an alert; any other connection is reset), and every other account’s go on. One sandbox has at most 2,048 such connections at once, and a connection that carries nothing either way for 15 minutes is closed.

• New connections are taken in at up to 2,000 a second for the account’s sandboxes together, 4,000 at once. Those past it wait, and are taken in at that pace: none is refused for it.
• When the plan changes, Paid’s share holds on each machine within seconds; Free’s from the next month, as the bill’s terms do. Connections already open past a smaller share are not cut: they end by themselves.

How the plan’s limits work

• They are quotas, not reservations. A call within them can still be refused when the machines are full (503 no_capacity).
• Reaching one refuses only new things. What is awake keeps running. A call that would go past a limit of what is awake or made answers 403 plan_cap_reached, with param naming the limit and a message that says what the limit is, what is used, and how to get more: Paid, or asking us to raise it for your account. The rates (made a minute, made an hour) are retryable, with Retry-After.
• Wakes count, however they come. A call that wakes a sleeping sandbox (a command, its files, a restart, a snapshot, a restore) is held to the limits of what is awake, and so is a request at a sandbox’s link or at a keyed instance’s address that would wake one, over HTTP/1.1, HTTP/2 or HTTP/3: past them, its machine refuses the request with 403 plan_cap_reached, and nothing wakes. So is a connection to a sleeping sandbox’s own IPv6 address, or to its address on the project’s network: past them, it is refused (reset). A timer that comes due in a sleeping sandbox (its processes’ timers, the time of day it names in wake_daily_at, a database’s pg_cron jobs) wakes it only within them too: past them, the wake waits, and is tried again every few seconds until the account has room. An app’s sleeping instances are woken for its requests only while the account has room for them; past it, the requests go to its instances that are awake. Each machine with something of the account asleep is told its part of the account’s room every few seconds, and the parts together are the room, so sandboxes woken on several machines at once never go past a limit together. An app’s instances are woken within the app’s own share of the room: what the account has left for them is shared between the app’s regions every few seconds, by how much each one used it lately, so its instances in all regions together stay within the limits too; a region that needs more than its share is given what the other regions do not use within seconds. A wake on one machine may be refused for a few seconds while the account has room left on another (in another region, as a rule); its message says so, and the parts are shared out again within seconds. A burst of requests to one sleeping sandbox wakes it once, and none of them is refused for it.
• Never refused by them: putting a sandbox to sleep, and deleting.
• Moving back to Free keeps what you have: sandboxes larger than Free allows sleep with their data, and Drives and secrets past its numbers stay. Only the next new one is refused.
• What a project keeps: a Drive past the plan’s numbers is refused with 403 drive_limit_reached, a volume with 403 volume_limit_reached, a secret with 403 secret_limit_reached. What an account keeps, in all its projects: an app past the plan’s number with 403 app_limit_reached; an app with more environment variables and secrets than the plan allows with 403 env_limit_reached, an instance larger than its largest with 403 plan_size_exceeded.
• Raised on request: what an account may have at once and how fast it makes things, the number of Drives on Paid (a soft limit), and Drives of up to 16 TiB for an enterprise account. The account asks with POST /v1/limits/requests, and is told the answer by an event and by mail: see raising a limit.

GET /v1/account (caps) shows each limit of the account with what is used now; GET /v1/billing shows the plan’s.

When a limit is reached

Every refusal of a limit has a section on the errors page, where its docs_url leads: what it refuses, and what lifts it. Those marked on request we raise for one account: raising a limit.

Limits of the API