Plans and limits
Check usage limits when choosing a plan or when you can no longer add or update an app. For prices, see the pricing page. For plan changes, cancellation, and invoices, see Billing and Subscription Management.
Start with these three questions when choosing a plan:
- How many apps need to run at once? This is the number of web apps in use at the same time, not the total number of apps you have saved.
- How many people will build or manage apps (Developers)? This allowance covers Owners, Admins, and Developers. App Users, who only use apps, do not count.
- How much storage do you need? This covers saved files and other stored content. Database size is accounted for separately.
Limits by plan
Section titled “Limits by plan”| Starter | Plus | Team | |
|---|---|---|---|
| Apps running at once | 1 | 2 | 4 |
| Developers (Owner / Admin / Developer seats) | 1 | 2 | 3 |
| Background Jobs runs per month | 500 | 2,500 | 5,000 |
| Background Jobs runtime per month | 300 minutes | 1,500 minutes | 5,000 minutes |
| Scheduled job definitions per app | 3 | 5 | 10 |
| Minimum interval between scheduled runs | 60 minutes | 15 minutes | 5 minutes |
| Background task definitions per app | 10 | 10 | 10 |
| Maximum duration per run (scheduled run or background task attempt) | 3 minutes | 5 minutes | 10 minutes |
| Builds per month | 100 | 300 | 1,000 |
| Build time per month | 500 minutes | 1,500 minutes | 5,000 minutes |
| Concurrent builds | 1 | 1 | 2 |
| Daily backups retained | 1 | 3 | 7 |
| Point-in-time recovery (PITR) window | 24 hours | 7 days | 14 days |
| Storage (workspace total) | 10 GB | 20 GB | 50 GB |
| Database size (per database) | No fixed limit | No fixed limit | No fixed limit |
| Email recipients per month | 500 | 2,000 | 10,000 |
| Priority start (paid subscriptions) | — | Yes | Yes |
| Custom domains | — | — | Up to 10 |
| Custom email sending domains | — | — | Up to 10 (20 allowed sender addresses each) |
| Access log history | 30 days | 90 days | 180 days |
| App log history | 7 days | 14 days | 30 days |
The Enterprise plan is in preparation. Contact us if your requirements exceed these limits.
A build prepares an app to run. A scheduled job runs a task at specified times or intervals, configured using cron. A background task runs a command declared in tasks in a separate instance when the app enqueues it with the SDK; each started attempt, including a retry, counts as one Background Jobs run. Each retained daily backup is one saved backup version.
For email sent with the Email SDK, each To, CC, or BCC address counts as one recipient. The limit applies both to the workspace total and to each app’s total; sending stops when either is reached.
Included in every plan
Section titled “Included in every plan”- Unlimited App Users.
- Unlimited saved apps on paid plans. Only the number that can run at once is capped. Trials have separate limits on owned apps and apps running at once; see Trial limits.
- Authentication, access control, and IP restrictions.
- Daily backups, manual snapshots (5 per app per day), PITR, and backup downloads.
- Managed SQLite, with databases isolated by app or workspace.
- A 14-day free trial, once per account. Starter and Plus can start without a card.
Trial limits
Section titled “Trial limits”- You can create up to 3 apps, excluding apps already deployed as static sites. Apps that have not been deployed and apps that use a server count toward this limit. Creating a fourth is rejected.
- Up to 3 apps can run at once, regardless of plan. During the trial, this replaces the plan’s active-app allowance, and extra-app add-ons do not increase it. For Team, this reduces the allowance from 4 to 3.
- You can run up to 7 builds in a rolling 24-hour period. This allowance does not reset all at once at midnight.
- You can run up to 30 builds over the entire trial. This total does not reset at the start of a new month.
- Build time and concurrent build limits remain those of your selected plan.
- When you move to a paid subscription, the owned-app limit is removed, and your active-app allowance becomes the plan allowance plus any extra-app add-ons.
What happens when you reach a limit
Section titled “What happens when you reach a limit”| Limit | Behavior |
|---|---|
| Apps running at once | Apps that need a free slot cannot start or deploy. Running apps are unaffected. Opening a sleeping app when no slot is available shows an explanatory page (HTTP 503). An app without priority start releases its slot about 5 minutes after the last request |
| Developers | Invitations that reserve a Developers seat and role changes that use an additional seat are blocked. You can still invite App Users and make role changes that do not increase seat usage |
| Background Jobs runs | Remaining scheduled runs for the month are skipped, and new background tasks are rejected (TASK_MONTHLY_QUOTA_EXCEEDED). The allowance resets next month |
| Background Jobs runtime | Remaining scheduled runs for the month are skipped, and new background tasks are rejected (TASK_MONTHLY_QUOTA_EXCEEDED). A run or attempt that has already started is allowed to finish. The allowance resets next month |
| Scheduled job definitions, intervals, and duration; background task definitions and duration | Deployment is blocked if keelson.yaml exceeds your plan’s limits. Ask your AI agent to adjust the settings to the limit shown |
| Monthly builds / build time | New builds are rejected. Both allowances reset next month. The trial’s 30-build lifetime limit does not reset; moving to a paid plan is required to continue |
| Concurrent builds | New builds are rejected until a running build finishes and capacity becomes available |
| Email recipients | Further sends for the month are rejected (MONTHLY_QUOTA_EXCEEDED). The allowance resets next month |
| Custom email sending domains | Adding another domain or allowed sender address is rejected. Remove one you no longer use first |
| Storage | Apps do not stop immediately. Support will contact you about the overage |
| Database size | There is no fixed per-plan limit, but underlying technical limits still apply. App execution may be restricted or suspended if usage significantly exceeds normal business workloads or affects platform stability, other customers, or our reasonable operating costs. Emergency restrictions may be applied without prior notice |
Add-ons (Team and above)
Section titled “Add-ons (Team and above)”During a paid subscription, you can add capacity as needed. See Billing and Subscription Management for how to make changes and how they are billed. Add-ons are not available during the trial.
| Add-on | Unit |
|---|---|
| Extra storage | +50 GB |
| Extra app running at once | +1 slot |
| Extra Developer | +1 seat |
Apps running at once
Section titled “Apps running at once”This is the number of slots web apps reserve to start and run. An ordinary app automatically releases its slot about 5 minutes after the last request. It keeps using the slot while requests continue.
- Sleeping and suspended apps do not use a slot.
- Apps with only scheduled jobs do not use a slot; jobs run separately from web apps.
- Static sites do not use slots, and there is no limit on how many you can create.
- Apps with priority start reserve a slot even without traffic. On paid subscriptions, this is available on Plus and above, for up to one fewer app than the total app-slot allowance. During the trial, all plans can enable it for up to 2 apps.
See When Apps Run for how apps start and stop.
Developers
Section titled “Developers”Developers seats are the allowance for people who build and manage apps. Each Owner, Admin, or Developer uses one seat. App Users do not count.
An unexpired invitation for an Owner, Admin, or Developer reserves one seat and counts toward usage even before acceptance. Revoke invitations you no longer need to release those reservations.
How seat counting differs by operation
When sending a new Owner, Admin, or Developer invitation, the limit is checked against existing members with these roles plus unexpired, unaccepted invitations. When accepting an invitation or changing a role to use an additional Developers seat, only existing members with these roles are counted. Changes that do not increase seat usage, such as changing the role of someone already using a seat, are not blocked by this limit.
Storage
Section titled “Storage”Storage is the combined size of saved deployment files (artifacts), Files / Media SDK files, and snapshots. It is measured across the workspace and excludes logs. Managed SQLite size is accounted for separately and has no fixed per-plan limit.
HTTP time limits
Section titled “HTTP time limits”Each request to your app, such as loading a page or saving data, has a time limit. If your app needs to do lengthy processing, ask your AI agent how to complete it within these limits.
| Item | Limit |
|---|---|
| Time until the response starts (first response headers) | 120 seconds; exceeding this returns a timeout (HTTP 504) |
| Total time for one request, including streaming responses | 300 seconds |
| Time between chunks in a streaming response | 120 seconds |
Even if a timeout appears, the app may have completed an operation such as saving data. Ask your AI agent: “Make sure repeating the same action does not create duplicate requests or orders.”
Technically, an HTTP 504 does not necessarily mean the app’s processing was canceled. Keelson does not automatically retry POST requests, but users or clients may retry them. Your implementation therefore needs to avoid duplicate results when the same request is repeated.
For scheduled run and background task duration limits, see the plan table above. For build time limits, see the keelson.yaml Reference.