# Plans and limits HOBBY vs SUPERAGENT limits for functions, frontends, databases, storage, realtime, and your account on Volcano. Volcano has two plans, **HOBBY** and **SUPERAGENT**. Metered allowances apply to your combined usage across every project you own. Allowances reset each month at your account's anniversary time. HOBBY accounts use their signup time. A new SUPERAGENT subscription uses its subscription billing anchor. Days 29–31 move to the last day of a short month and return to the original day when possible. Annual subscriptions still receive twelve monthly allowance windows. Deleting a project does not remove its usage from the account total. Concurrent function and frontend requests share the same allowance, including requests that are still completing. "Unavailable" means a feature is not offered on that plan. An allowance is one plan's worth of usage for the current cycle. Unused allowance is forfeited; it does not carry forward or stack. HOBBY accounts stop shortly after they reach the allowance, as described in [How HOBBY allowances are enforced](#how-hobby-allowances-are-enforced), and never incur overage debt. While a SUPERAGENT account is not in debt, traffic continues beyond the allowance: that usage is overage, and requests are not gated on the credit balance at request time. Overage is bought in whole blocks at the resource's own price for the current cycle. Unused capacity in a purchased block carries forward across allowance windows and plan changes. Purchased credits are spent on overage and can settle arrears. Unfunded overage is recorded as arrears, and Volcano requests `read_only` account status. After the cached traffic decision refreshes, `read_only` blocks new project traffic and connections across every project while the dashboard remains reachable. Existing sessions are force-disconnected; a session that was already establishing when status changed can escape that teardown and keep working, with no re-check on later requests, until the connection ends for an unrelated reason and the next reconnect is refused. The allowance still resets but does not restore access while the account is restricted. The next monthly grant or purchased credits settle arrears before any credits become spendable. Once sufficient credits clear the arrears, Volcano requests `active` status; the cached traffic decision refreshes eventually after the status change. A resource Volcano adds after your contract starts is not covered by it: your contract fixes the terms for what it prices, and a new resource has none. Start using one and it is served at the allowance and overage rate of the current offer, alongside everything your contract still fixes. ## How HOBBY allowances are enforced Usage is counted after the request it belongs to, so no request waits on a usage lookup. Volcano checks each HOBBY account against its allowances every few seconds, and blocks the resource across every project the account owns once it reaches one. Requests served in between are counted like any other, so a HOBBY account can end a cycle slightly over an allowance. The block lasts until the next allowance window, an upgrade, or, for storage, until you free enough space. Some usage is counted when the work finishes rather than when it starts: a build's minutes when the build ends, a durable execution's operations and compute when it finishes. Those allowances refuse the next build or start. ## Account | Limit | HOBBY | SUPERAGENT | Scope | | ------------------- | ------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Projects | Unlimited | Unlimited | No plan limit; usage allowances apply across all your projects. SUPERAGENT subscriptions that started before project limits were removed keep a 1,000-project cap, and deleted projects stop counting toward it. | | Bandwidth allowance | 10 GB / month | 20 GB / month | Aggregate ingress + egress across all your projects | Deleting a project does not remove its recorded usage: previously recorded usage still counts toward your account's monthly allowances. ## Sandboxes | Limit | HOBBY | SUPERAGENT | Scope | | ------------------- | ----------- | ------------------------------ | ------- | | Included runtime | 5 GBh/month | 20 GBh/month | Account | | Additional runtime | Unavailable | 25 credits per 5 GBh | Account | | Baseline memory | 1 GiB | 2 GiB | Session | | Maximum lifetime | 1 hour | 8 hours | Session | | Concurrent sessions | 5 | Unlimited (100 safety ceiling) | Account | Runtime uses configured baseline memory and confirmed running time. Snapshots are included, suspended time is free, and automatic expansion has no surcharge. HOBBY exhaustion suspends running sessions and refuses starts and resumes. See [Sandbox pricing and usage](https://docs.volcano.dev/platform/guides/sandboxes.md#pricing-and-usage) for retention, local-mode exclusions and the preview-to-billing boundary. ## Functions | Limit | HOBBY | SUPERAGENT | Scope | | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------ | | Timeout | 30 s | 180 s | Per invocation, including the whole of a [streamed response](https://docs.volcano.dev/platform/functions/invoking-functions.md#stream-a-response) | | Memory | 128 MB | 256 MB | Per runtime | | Ephemeral disk | 512 MB | 1 GB | Per runtime | | Functions per project | 10,000 | 10,000 | Absolute hard cap | | [Schedulers](https://docs.volcano.dev/platform/functions/scheduled-invocations.md) | Unavailable | 100 | Per project, counted across standard and durable functions together | | [Runtimes kept ready](https://docs.volcano.dev/platform/functions/overview.md#response-time-on-the-first-invocation) | 1 per region, for 2 days after each deploy and 1 day after the most recent invocation | Same | Not counted as invocations or bandwidth | ## Durable functions [Durable functions](https://docs.volcano.dev/platform/functions/durable-functions.md) are available on both plans and metered on their own allowances. Starting one does not spend the shared request allowance below. | Limit | HOBBY | SUPERAGENT | Scope | | ------------------------------------------------------------ | ------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Execution allowance | 5,000 / month | 10,000 / month | Combined across all your projects; every start, including a retry you start yourself | | Operation allowance | 100,000 / month | 200,000 / month | Combined across all your projects; the execution itself plus every step, retry, wait, condition poll, parallel branch and nested invocation it begins. An approval, a message wait or a callback is three operations, a publish one | | Compute allowance | 10,000 GB-s / month | 100,000 GB-s / month | Combined across all your projects; memory × time your code is actually running, summed over every resume. Time suspended in a wait is not charged | | Memory | 128 MB | 1 GB | Per execution, and the size its compute is charged at. Set by your plan, not per function | | Step timeout | 300 s | 900 s | One attempt between checkpoints, not the whole execution | | Execution timeout | 366 days | 366 days | A whole execution, including time suspended in a wait | | Result retention | 30 days | 30 days | After an execution finishes | | Concurrent executions | 10 | 100 | In flight at once, per project | | Durable functions per project | 10,000 | 10,000 | Absolute hard cap, counted separately from standard functions | | Schedulers | Unavailable | 100 | Per project, shared with standard function schedulers | | Runtimes kept ready | Not kept ready | Same | Durable functions are started, not called | | [Pending approvals](https://docs.volcano.dev/platform/functions/durable-approvals.md) | 100 | 100 | Per execution, waiting at once | | Approval requests | 600 / hour | 600 / hour | Per execution; also 6,000 refused requests / hour per sending address | | Approval history | 1 year | 1 year | From the request, independent of result retention; kept after the function is deleted, removed with the project | | [Durable message](https://docs.volcano.dev/platform/functions/durable-messages.md) data | 64 KiB | 64 KiB | Per message, sent or published | | Queued messages | 100 | 100 | Per execution, sent and not yet taken by a wait | | Published messages | 1,000 | 1,000 | Per execution, over its life | | Messages sessions | 1,000 | 1,000 | Per execution, over its life. One per context that publishes, each three operations and a resume; publish from the parent rather than every `ctx.map` item | | Open message waits | 100 | 100 | Per execution, waiting at once | | Message sends | 3,600 / hour | 3,600 / hour | Per execution for each kind of sender: the service key, signed-in users, anon key callers, and the project-scoped endpoints. See [durable message limits](https://docs.volcano.dev/platform/functions/durable-messages.md#limits-and-billing) | | Message history | Result retention | Result retention | Deleted with the execution | | [Durable callback](https://docs.volcano.dev/platform/functions/durable-callbacks.md) result | 64 KiB | 64 KiB | Per callback, succeeded with JSON other than `null` | | Open callback tokens | 1,000 | 1,000 | Per execution, waiting at once | | Callback tokens issued | 3,600 / hour | 3,600 / hour | Per execution, retries included | | Callback answers and heartbeats | 36,000 / hour | 36,000 / hour | Per project, succeed, fail, and heartbeat together | Execution timeout and retention are the same on both plans on purpose: they are fixed when the function is created, so a plan change never leaves an existing function configured for limits its plan no longer allows. The timeout is set as high as it goes for the same reason — what actually bounds an execution is its 3,000 operations and your concurrent-execution cap, not the clock. A durable function gets more memory than a standard one on SUPERAGENT because it orchestrates — it holds the state of a workflow across resumes, and on SUPERAGENT that is where agent and fan-out work runs. Memory comes from your plan, and it is applied on a function's next deploy, so a plan change reaches an existing function when you next deploy it. More memory also means proportionally more CPU, and it is the size your compute allowance is charged at: the same work costs 8× more compute on SUPERAGENT's 1 GB than on HOBBY's 128 MB, against an allowance 10× larger. Operations and compute are both counted from a finished execution, so those allowances are enforced on the next start rather than by stopping an execution already running: whatever is in flight finishes and is billed. On HOBBY that means an account can end a cycle over them, bounded by how many executions each of its projects may run at once. ## Functions and frontends (shared) Functions and frontends share these counters. | Limit | HOBBY | SUPERAGENT | Scope | | ------------------------- | --------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Request allowance | 100,000 / month | 1,000,000 / month | Combined across all your projects: every function invocation **and** proxied frontend request, including static assets and `/_next/image`. A request a frontend routes to a function counts once. Durable executions have their own allowances above. HOBBY enforcement is eventual | | Rate limit (per resource) | 100 requests / 10s | Unlimited | Each function or frontend | | Rate limit (per project) | 600 requests / 10s | Unlimited | Across all functions and frontends; a request a frontend routes to a function counts once | | Build timeout | 30 min | 60 min | Per build | | Build-minute allowance | 240 / month (4 hours) | 240 / month (4 hours) | Combined across all your projects; HOBBY blocks new builds once finished builds reach the allowance, SUPERAGENT bills overage | All accounts receive at least 240 included build minutes for monthly cycles that end after October 1, 2026, including accounts on older pricing revisions. Existing usage counts toward this allowance. Other subscription terms stay unchanged. Previously purchased overage blocks stay purchased; their unused capacity remains available. Cycles that ended on or before October 1 keep their recorded allowance. Build minutes count from when your build gets build capacity. Time spent waiting for capacity does not count, but preparing the build environment does, so the end of a deployment's [Queue phase](https://docs.volcano.dev/platform/guides/deployment-performance.md) can count toward your minutes. Installing dependencies and running your build command must finish at least five minutes before the build timeout, which leaves time to package the result. Each step can also run for at most 30 minutes. A step that runs out of time fails the build, and the build log names the step. ## Databases | Limit | HOBBY | SUPERAGENT | Scope | | -------------------------------------------------- | --------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Request allowance | 100,000 / month | 200,000 / month | Combined across all your projects; each completed statement counts once, and transaction control, an empty query such as a driver's connection ping, and the statements a [migration run](https://docs.volcano.dev/platform/guides/migrations.md) executes do not count. See [how requests are counted](https://docs.volcano.dev/platform/databases/overview.md#how-requests-are-counted). HOBBY enforcement is eventual | | Databases per project | 1 | 10,000 | Creation cap | | Database-storage allowance | 1 GB / month | 10 GB / month | Peak combined storage across every database you own; HOBBY makes all owned databases read-only at the allowance | | [Branches](https://docs.volcano.dev/platform/databases/branching.md) per database | 10 | 25 | Counts branches in every state | | [Backups](https://docs.volcano.dev/platform/databases/backups.md) per database | Not included | 50 | Backups you take; scheduled and migration ones do not count | | Backup retention | Not included | 30 days | Applied when the backup is taken; at most the 20 most recent migration backups are kept | | Point-in-time restore window | Not included | 7 days | How far back a restore can reach without a backup | Backup storage counts against the storage allowance — a backup you take is charged as a full copy of the database — and the point-in-time history window does not. Only a plan that includes backups is charged for them, so a downgrade never leaves a database paying for backups it can no longer reach. See [what backups cost](https://docs.volcano.dev/platform/databases/backups.md#what-backups-cost). ## Object storage | Limit | HOBBY | SUPERAGENT | Scope | | ---------------------- | -------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | File-storage allowance | 512 MB / month | 10 GB / month | Peak combined object bytes across all your projects; HOBBY blocks new uploads once the account holds the allowance. Deleting objects makes room again | | Max object size | 100 MB | 10 GB | Per uploaded file | | Buckets per project | 20 | Unlimited | Creation cap | ## Realtime | Limit | HOBBY | SUPERAGENT | Scope | | ----------------------- | --------------- | ----------------- | ---------------------------------------------------------------------------------------------------------- | | Concurrent connections | 200 | 100,000 | Per project | | Message allowance | 100,000 / month | 1,000,000 / month | Across all your projects; each direct message costs one publish plus one unit for each subscriber delivery | | Max message size | 256 KB | 1 MB | Per message | | Channels per connection | 100 | 500 | Per WebSocket connection | Postgres change notifications generated by Volcano do not count toward the message allowance. When a HOBBY account reaches its message allowance, Volcano closes its Realtime connections across all owned projects and rejects new connections, subscriptions, and publishes until the next allowance window. ## Frontends | Limit | HOBBY | SUPERAGENT | Scope | | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | | Frontend sites per project | Unlimited | Unlimited | Plan quota | | Absolute frontend hard cap | 10,000 | 10,000 | Safety hard cap | | Custom domains | 1 per frontend | 10 per frontend | Plan quota; redirecting domains count | | Managed TLS certificates | 1 | 100 | Across all projects owned by the account | | [Function](https://docs.volcano.dev/platform/frontends/function-routes.md) and [Frontend routes](https://docs.volcano.dev/platform/frontends/frontend-routes.md) | 64 per frontend, both kinds together | 64 per frontend, both kinds together | Safety hard cap | | [Runtimes kept ready](https://docs.volcano.dev/platform/frontends/overview.md#response-time-on-the-first-request) | 1 per region, for 2 days after each deploy and 1 day after the most recent request | 2 per region, same windows | Not counted as requests or bandwidth | | [Time to start a response](https://docs.volcano.dev/platform/frontends/overview.md#time-limits-for-server-rendered-routes) | 60 s | 60 s | Per server-rendered request; a route that has not started answering gets a `504` | | [Runtime timeout](https://docs.volcano.dev/platform/frontends/overview.md#time-limits-for-server-rendered-routes) | 30 s | 180 s | Per server-rendered request; a streamed response can run this long if it sends something at least every 60 s | | [Requests per visitor](https://docs.volcano.dev/platform/frontends/overview.md#platform-error-pages) | 600 / 10s | 600 / 10s | Server-rendered requests and function routes from one visitor to one frontend; a mounted frontend counts its own; static files do not count | The per-visitor limit keeps one client, such as a browser holding down refresh, from taking the capacity every other visitor shares. A visitor is one IPv4 address or one IPv6 `/64`, so visitors who share one, such as behind an office NAT or a CDN in front of a custom domain, share the limit. A visitor can send 600 such requests at once, then 60 per second. Static files, optimized images (`/_next/image`, or `/_next/image` under a `basePath`), and pages served from the edge cache do not count. Requests past the limit get `429` with `Retry-After` and are not counted toward your plan's request rate or allowance. Managed domains count toward the certificate limit until deletion finishes, including failed setups and domains awaiting cleanup. At the limit, creating another managed domain returns `403`. Delete an existing domain and wait for deletion to complete before creating its replacement. ## API access tokens | Limit | HOBBY | SUPERAGENT | Scope | | ---------------------------------------------------------------------- | ----- | ---------- | --------------------------------------------------------------- | | [Project access tokens](https://docs.volcano.dev/platform/api-reference/using-the-api.md) per project | 100 | 100 | Safety hard cap, counts only tokens that can still authenticate | Revoked and expired tokens do not count against it, so cycling short-lived tokens never fills the allowance. ## Variables | Limit | HOBBY | SUPERAGENT | Scope | | ---------------------------------------- | ----- | ---------- | -------------------------------------- | | Custom variable Environments per project | 100 | 100 | Safety hard cap; Global is not counted | ## Authentication | Limit | HOBBY | SUPERAGENT | Scope | | ----------------------------------------------------------------------------------- | ----------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------- | | [Email domain allowlist](https://docs.volcano.dev/platform/authentication/configuration/email-domain-allowlist.md) | Unavailable | Available | Per project; a downgrade parks the list — the domains are kept and stop being enforced — and an upgrade puts it back in force | | Custom email templates | Unavailable | Available | Per project; HOBBY projects send the default templates | | Custom managed auth pages | Unavailable | Available | Per project | ## LavaFlow LavaFlow is in preview. During the preview, it needs the SUPERAGENT plan. | Limit | HOBBY | SUPERAGENT | Scope | | ----------------------- | ----------- | ---------- | ----------- | | [LavaFlow](https://docs.volcano.dev/platform/guides/lavaflow.md) | Unavailable | Available | Per project | No plan includes [Code Quality](https://docs.volcano.dev/platform/guides/lavaflow.md#code-quality) yet. Where it is offered, the project's `lavaflow.code_quality` capability reads `unavailable` with code `plan_required`. Its allowances, findings per scan, new findings a day and open pull requests, are listed here once a plan includes them. ## Scheduling and logs | Limit | HOBBY | SUPERAGENT | Scope | | --------------------- | ----------- | ---------- | ------------------------- | | Scheduled functions | Unavailable | 100 | Per project | | Runtime log retention | 1 day | 30 days | Search / retention window | ## Enforcement How a limit is enforced depends on the limit — you may see an HTTP `403` (Forbidden), `413` (Payload Too Large), or `429` (Too Many Requests), a Realtime protocol error or disconnect, or a PostgreSQL error (SQLSTATE `53400`). ## Moving from SUPERAGENT to HOBBY A downgrade splits your account in two: settings are kept but stop applying, while resources have to be removed by you. Existing Sandbox sessions keep their original memory and expiry on downgrade. New sessions and resumes must fit HOBBY's baseline memory and concurrency limits. Running sessions are suspended when the HOBBY runtime allowance is exhausted; upgrading or a new cycle requires an explicit resume. ### Settings are parked, not deleted These stay in the database, stop taking effect on HOBBY, and take effect again the moment you upgrade. You do not have to set them up twice. | Setting | On HOBBY | | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Email domain allowlist](https://docs.volcano.dev/platform/authentication/configuration/email-domain-allowlist.md) | Kept, not enforced: anyone can sign up and sign in again | | Custom email templates | Kept; the default templates are sent | | Custom managed auth pages | Kept; the built-in pages are served, with Volcano branding | | Scheduled functions | Kept; they stop running, and their next run time keeps advancing | | Database query logs | Kept; new queries stop being recorded, and query insights stop being readable | | Database compute size | Shrunk to the HOBBY size, and restored when you upgrade. No downtime, no data loss | | [Custom domains](https://docs.volcano.dev/platform/frontends/overview.md#custom-domains) past one per frontend | Kept; only one serves | | [LavaFlow](https://docs.volcano.dev/platform/guides/lavaflow.md) settings | Kept; no run or Code Quality scan starts, and a fix waiting to merge stops and is left to you | A frontend with more custom domains than HOBBY allows keeps all of them, with their certificates and redirects. Its oldest active domain that serves the frontend keeps serving, and the others, redirects included, answer `404` until you upgrade. To choose which domain serves instead, remove the others; removing a domain is always allowed, while adding one past the limit returns `403`. Five things are not parked: - **Region selection.** A project pinned to a subset of regions keeps that subset, because widening it would copy your data into regions you excluded. Select all regions yourself before you downgrade. - **[Database backups](https://docs.volcano.dev/platform/databases/backups.md).** Backups are a SUPERAGENT capability. Downgrading deletes the backups you took, turns off any backup schedule, closes the point-in-time restore window, and stops backup storage counting toward your database's storage. Backups your schedule or a migration run already took are left to expire on their own retention, unreachable and uncharged, and migration runs on HOBBY skip the backup. Upgrading gives the capability straight back, but it starts from that moment: there is nothing to restore from until you take a backup, and the point-in-time window fills as the database writes. - **Function and frontend sizing.** Memory, timeout, and ephemeral disk change to the HOBBY values on the resource's next deploy. A [durable function](https://docs.volcano.dev/platform/functions/durable-functions.md)'s own sizing is part of this: its step timeout drops from 900 seconds to 300 and its memory from 1 GB to 128 MB on its next deploy, so a step that ran close to the SUPERAGENT limits has to fit in the HOBBY ones afterwards. Until you deploy it, it keeps running at the SUPERAGENT size and its compute is charged at that size. - **Log history.** Log search and streaming immediately narrow to HOBBY's retention window, so logs older than that stop being readable even if they were written while you were on SUPERAGENT. Nothing is deleted, and upgrading brings the window back. - **[Runtimes kept ready](https://docs.volcano.dev/platform/frontends/overview.md#response-time-on-the-first-request).** Each frontend goes from two ready runtimes per region to one, within minutes and without a redeploy, so two visitors arriving at once may see one startup between them. Functions keep one on both plans, and both windows are the same on both plans, so neither changes. Rate limits, monthly quotas, and realtime limits switch to the HOBBY values right away. Requests already served and usage already recorded are kept, so an account that has passed a HOBBY quota is over it until its next allowance window starts. Durable executions already running are the same: nothing stops them. The concurrent-execution cap drops to the HOBBY value immediately, so a project that was running more than that keeps them to completion and cannot start another until enough have finished. Executions are not cancelled and no work is lost — ending one early to fit a new cap would throw away a job midway rather than merely delay it. An execution can run for a long time, so use `stop` on the ones you no longer need if you want slots back sooner. Database compute is the one thing Volcano resizes for you, because it bills by the hour whether or not anything connects. Each database drops to the HOBBY compute size shortly after the downgrade, and goes back to the size you were on when you upgrade — you do not have to resize anything by hand. Neither change interrupts connections or touches your data. ### Resources have to fit first Nothing can park a project, a database, a frontend, a bucket, or the bytes inside them, so bring the account under HOBBY's limits before you downgrade: 1. Delete databases down to 1 per project, and reclaim space until all your databases together are under 1 GB on disk. 2. Delete buckets down to 20 per project, and files until your projects together store under 512 MB. 3. Select all regions for every project. Database size is measured as on-disk size, so use `DROP`, `TRUNCATE`, or `VACUUM FULL` to reclaim it: ```sql -- Drop what you no longer need, or empty a table outright. DROP TABLE old_events; TRUNCATE audit_log; -- After deleting rows, return the pages to the operating system. VACUUM FULL events; ``` A `DELETE` on its own does not shrink a database — the rows go, but the pages stay until autovacuum reuses them — so deleting rows and nothing else will not lift a hold. `VACUUM FULL` takes an exclusive lock on the table and needs room for a second copy of it while it runs. A downgrade you ask for is refused until the account fits, and the refusal lists exactly what to delete or reset. Nothing changes in the meantime — you stay on SUPERAGENT until the cleanup is done. If a downgrade happens without that cleanup — a subscription that lapses, for example — it still goes through, and the account is held **read-only** until it fits. Reads keep working, creating and updating anything returns `403`, and **deleting is always allowed**, so you can shrink your way back. Git pushes deploy nothing while the account is held; their runs fail with [`owner_not_active`](https://docs.volcano.dev/platform/projects/git-deploy.md). The account returns to normal on its own once it is under the limits. A hold is not an outage: your deployed apps keep serving, and your own users keep signing up, signing in, and using them throughout. It is your account's administrative writes that stop, not your project's traffic.