Limits

Every app runs with resource limits. This page lists each one, its default, the error you get when you cross it, and what to change in your capsule. Limits apply the same way in fuast dev and on hosted apps, except where a row says otherwise. Self-hosted platforms can change some defaults with environment variables, listed at the end.

Handler limits

These apply to every query, mutation, action, endpoint, and schedule call. Crossing one fails the call, and a mutation, writable endpoint, or schedule rolls back its whole transaction.

Hosted CPU, wall-clock, memory, and write-lock limits come from the isolate runtime. fuast dev runs handlers in Bun workers. It enforces the database budgets, database time, the 10 s wall-clock limit, and the action limits, but not the separate CPU and memory limits, so a CPU-heavy handler that works locally can still fail once deployed.

Outbound fetch

Fetch time also counts toward the handler's wall-clock limit and holds the app's write lock in a mutation.

Action limits

Pass an id and read the data inside the action instead of passing the data. Return only the fields the client needs. A failed action does not undo its outbound effects, so do not assume it is safe to retry.

Endpoint and connection limits

App limits

Stored row limits fail the write that crosses them. They have no reset: delete data to get under them again.

Email limits

fuast dev logs emails instead of sending them. See email.

Storage limits

See storage.

Team table limits

See teams.

Server env limits

.env.fuast.server travels with the deploy, so it is limited to 1 MiB like any source file.

Deploy limits

Deploys upload source, not build output, so these limits are generous for a capsule. Large data belongs in storage or the database, not in source files.

Unclaimed previews

An app deployed without an account is an unclaimed preview until a person claims it. It runs with the limits below instead of the app limits above. Claiming lifts the quotas at once. Email, team tables, the member list, schedules, and jobs stay off after the claim until the owner trusts the app. See restricted apps.

fuast inspect <preview-slug> --usage shows these limits beside the current counts, and the response of the deploy lists them under limits.

Rate limits

The platform limits some routes per client IP in a sliding window. Crossing one returns HTTP 429.

WebSocket calls from the app's own client are covered by the daily quotas, not by these per-minute limits.

Reading a quota error

Daily quota errors on HTTP routes return status 429 with this body:

{
  "code": "fuast_quota_exceeded",
  "error": "requests quota exceeded. Limit: 100000.",
  "bucket": "requests",
  "current": 100001,
  "limit": 100000,
  "resetAt": "2026-11-11T00:00:00.000Z",
  "retryAfterSeconds": 41230,
  "suggestion": "Retry after the reset, or reduce request frequency.",
  "command": "fuast inspect my-app --usage"
}

The response also carries Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. Do not retry in a tight loop. Wait retryAfterSeconds.

Over the WebSocket, the error arrives as { op: "error", error, code: "fuast_quota_exceeded", quota: { ...same body } }. Mutation and action promises reject with an error whose code is fuast_quota_exceeded.

Owners and workspace admins can still read usage, logs, and data exports after an app runs out of quota. Those reads do not spend the app's budget.

Checking usage

fuast inspect my-app --usage          # hosted app, by slug
fuast inspect my-app --usage --json
fuast inspect --port 3000 --usage     # local

Usage shows stored rows and bytes and today's request, mutation, and email counts beside their limits. fuast dev counts the same way but never rejects on daily quotas. Handler, action, and stored-row limits do apply locally, so local testing catches them.

fuast inspect also prints per-read database metrics:

  read by_owner: returned=20 read=20 bytes=4096
  read by_creation: returned=50 read=4800 bytes=1900334 full-scan

returned, read, and bytes are the counters behind the handler limits. full-scan marks a read that walked by_creation on a large table without a range. It is the usual cause of a rowsRead failure: add an index that matches the filter. To see the metrics of one query with your own arguments, run it with fuast inspect --query. See test and debug.

Self-hosted overrides

Operators running their own platform can change these defaults. Every limit uses one variable family, FUAST_LIMIT_*, and the platform, the runtime, and fuast dev all read it the same way, so set the same values for every process (the platform sends the database budgets with each call, the runtime enforces the isolate limits). Values must be positive integers; anything else is ignored.

fuast inspect and /__fuast/manifest show the limits in effect under limits, so you can check what a process picked up.

Older names still work but print a deprecation warning once: FUAST_DB_ROWS_RETURNED, FUAST_DB_ROWS_READ, FUAST_DB_BYTES_READ, FUAST_DB_DIRECT_GETS, FUAST_DB_SCAN_CALLS, FUAST_DB_WRITES, FUAST_DB_VALUE_BYTES (and FUAST_LIMIT_VALUE_BYTES), FUAST_DB_INDEX_KEY_BYTES, FUAST_DB_TRANSACTION_MS, FUAST_STATE_ROWS, FUAST_STATE_BYTES, FUAST_QUOTA_REQUESTS, FUAST_QUOTA_MUTATIONS, FUAST_QUOTA_EMAIL, FUAST_CPU_MS, FUAST_WALL_MS and FUAST_HANDLER_TIMEOUT_MS, FUAST_MEM_MB, FUAST_ACTION_TIMEOUT_MS, FUAST_WRITE_LOCK_WAIT_MS. When both an old and a new name are set, the FUAST_LIMIT_* name wins.

Unclaimed previews have their own family, read by the platform. Values must be positive whole numbers:

Other operator settings are not limits on what a handler may do, so they keep their own names:

The endpoint body size, log sizes, email sizes, team table sizes, and the per-IP rate limits are fixed. A per-IP limit counts an IPv4 address, or a whole IPv6 /64, as one client. See reference for the rest of the platform environment.