Deploys & limits
Every deploy runs as its own isolated app on *.cloudbed.app, with its own SQLite database and live-query hub. There are two modes.
Anonymous deploys
cloudbed deploy with no account gives you a live URL immediately. Anonymous deploys are sandboxed:
- No outbound
fetch— the capsule server cannot reach the network at all. - No server env —
.env.cloudbed.serveris ignored (with a warning) until the deploy is claimed. - They expire 7 days after the last update. Re-deploying resets the clock; claiming removes it.
The CLI stores the deploy's one-time claim token in .cloudbed/deploy.json (gitignored — treat that file as a secret; it's also shown once as a claim: link at deploy time).
Claiming
cloudbed login # device-flow auth in your browser
cloudbed claim # in the app directory
Claiming attaches the deploy to your account: it becomes permanent, outbound fetch is enabled, and .env.cloudbed.server syncs on each deploy. The claim token is invalidated, and a cloudbed.json binding is written that you can commit — anyone with owner access who deploys from that directory updates the same app.
If you log in before the first deploy, you skip the anonymous stage entirely and get an owned deploy from the start.
Your claimed apps are listed at dashboard.cloudbed.dev.
Server env
Claimed deploys read .env.cloudbed.server (KEY=VALUE lines) and expose it as ctx.env — server-side only, never shipped to the client. Up to 64 keys, 16 KB per value, 64 KB total.
API tokens
cloudbed token create mints a bearer token for scripting the platform API — personal (acts as you) or, with --deploy, scoped to a single deploy. Tokens are shown once at creation; list and revoke them with cloudbed token list / cloudbed token revoke <id>.
Extra subdomains
cloudbed domains add <name>.cloudbed.app reserves an additional cloudbed.app subdomain for a deploy (owner or claim-token holder only). Labels are [a-z0-9-], 3–63 characters, and a few are reserved. Auth stays audience-pinned to whichever origin the app is served from.
Limits
Storage and handler caps apply to every deploy; the daily counters apply to anonymous deploys only and disappear on claim.
| Limit | Value |
|---|---|
| Deploy payload (bundled server + client) | 4 MB |
| State size | 1 MB |
| State rows | 16,384 |
| Serialized row size | 64 KB |
| Rows returned per query | 1,000 |
| HTTP endpoint request body | 2 MB |
| Handler wall-clock time | 10 s |
| Log retention | 1,000 entries / 256 KB |
| Endpoint requests / day (anonymous only) | 10,000 |
| Mutations / day (anonymous only) | 1,000 |
| Anonymous deploys per IP / day | 50 |
Hitting a quota returns a machine-readable error code, so agents can react programmatically.
Inspecting a deploy
cloudbed inspect (from the app directory, or with an explicit deploy id) reports the deploy's URL, name, mode, and expiry, and — when you hold the deploy's inspect token — the list of deployed queries and mutations. Logs written via ctx.log are retrievable the same way. All of it supports --json.