Quotas
Per-workspace limits, checked before anything is created.
View as MarkdownA quota is a per-workspace limit. Creating endpoints check the relevant quota first, so a refused call creates nothing.
Quotas bound how much of the product a workspace uses. Retention bounds how much data it keeps. They are different things and both matter.
Reading them
sctl workspace currentOr directly, which returns limits and current usage in one call:
curl -fsS "https://api.saved.sh/v1/workspaces/$WID/quotas" \
-H "Authorization: Bearer $TOKEN"The response is the complete set with defaults filled in, so you never have to know which limits exist. Read it rather than hard-coding the table below.
A limit of 0 means unlimited, not zero. Treating it as a ceiling would make every paid
workspace look exhausted.
The limits
| Resource | Trial | Paid |
|---|---|---|
| Workers per workspace | 1 | 10 |
| Backups per workspace | 5 | 100 |
| API keys per workspace | 2 | 20 |
| Members per workspace | 1 | 25 |
| Destinations per workspace | 1 | 25 |
| Connections per workspace | 1 | 25 |
| Total stored | 20 GiB | unlimited |
| One artifact | 5 GiB | unlimited |
| Retention window | 7 days | unlimited |
| Workspaces per user | 5 | 5 |
Two kinds of limit
They fail in different places, which is worth knowing before you design around them.
Counting limits are checked when you create something, and fail immediately:
{ "error": { "code": "quota_exceeded", "message": "this workspace already has 5 backups" } }Size limits cannot be checked in advance, because nothing about a request knows how large a dump will turn out to be. They bind during a run and fail the run, not the API call.
A trial workspace with a database larger than 5 GiB compressed will see backups configured successfully and then fail at 02:00. Watch usage against the limit rather than waiting to find out.
The retention cap is the sharp one
Trial caps the retention window at 7 days, and retention is write-once.
A backup created on trial keeps its ≤7-day policy even after you upgrade. Upgrading does not loosen it, because the policy cannot be edited at all. If you intend a 90-day retention, set it on a paid plan, or plan to create the backup again.
This catches people who evaluate on trial and then keep the backups they made.
What is not limited
| Not limited | |
|---|---|
| Runs per day | Trigger as often as the schedule and your source allow |
| Concurrent runs | Bounded by your own worker and source, not by us |
| Schedule frequency | No minimum interval is enforced |
| Downloads and reads | Never gated, in any billing state |
That last row is worth stating plainly: quotas restrict what you can create, never what you can retrieve.
Checking before a bulk change
Worth doing before applying a manifest that creates many backups, which otherwise fails partway through with some created and some not.
curl -fsS "https://api.saved.sh/v1/workspaces/$WID/quotas" -H "Authorization: Bearer $TOKEN" \
| jq -r '.quotas[] | select(.limit != 0 and .used != null and .used >= .limit)
| "at limit: \(.resource) \(.used)/\(.limit)"'Raising them
Upgrading from trial lifts every counting limit and removes the storage and retention caps. Beyond the paid defaults, ask.