What shipped, and when.

Creating a resource and watching it come up got smoother across all three kinds:

Files first. Frontend and backend create forms now open with the upload area: drop project files, folders, or a ready-made ZIP and the first deploy ships with creation. Local junk (node_modules, .git, .env*, logs) is stripped before upload, a single wrapper folder is unwrapped, and the dialog previews what will go up. The backend’s detected runtime and start command are shown, not asked for.

Names suggest themselves. Every create form starts with a generated name; dropping a backup ZIP or staging files re-suggests from the file name until you type your own.

One provisioning card. PocketBase, frontend, and backend provisioning pages share the same status card, so progress reads identically whichever kind is coming up.

URLs, split properly. Detail pages now list the platform URL separately from a verified custom domain (still marked as verifying while it is). PocketBase splits further into admin and API URLs per host, so there is no more guessing which address goes into the SDK and which into the browser.

Free-tier create forms also name what an upgrade buys: how many Starter-pool regions and Pro dedicated-compute regions exist, with a link to plans.

Three PocketBase operations that used to need the instance’s own admin panel now live on the platform surface — the portal and the pbc CLI:

Restore at creation. pbc pocketbase create --backup backup.zip provisions an instance with a backup ZIP already restored into it — schema, records, uploaded files, and superusers arrive as they were:

$ pbc pocketbase create restored-db --backup backup.zip
Admin login: preserved from backup; credentials are not available to PocketBase Cloud.

Log in with the same superuser the backup was taken with. The backup rides a presigned upload (max 150 MB), and because the superusers are preserved, --backup cannot be combined with --admin-email / --admin-password. The portal’s create form has the same thing: switch Admin Credentials & Mode to Restore Backup and drop the file — the name is suggested from it.

Runtime flags. Dev mode, the hooks pool (1–100), and the query timeout (1–3600 s) are settable at creation and editable afterwards. A running instance restarts when they change:

pbc pocketbase create my-app-db --dev true --hooks-pool 20
pbc pocketbase config get --name my-app-db
pbc pocketbase config set --name my-app-db --query-timeout 60

Managed superuser. The platform-owned superuser can be rotated without the old password, and without touching the other superusers:

pbc pocketbase superuser sync --email [email protected] --password 'new-password-here' --name my-app-db

The instance detail page carries both under Advanced Configuration — Admin Credentials and Runtime Flags. See Deploying PocketBase and Managing Your Instance.

Every PocketBase instance, frontend, and backend now keeps its deploy history on its own detail page. Each entry records when it shipped, what went up, and whether it succeeded — so “did that deploy land?” is answered by looking, not by re-running.

The deploy dialog changed with it. Dropping files no longer uploads blindly: it shows the file list, the archive size, and how many junk files were stripped (node_modules, .git, .env*, logs) before anything leaves the browser. For backends it also names the detected runtime and start command. A ZIP picked through Add files routes to the ZIP path automatically, and an oversized archive reports what was removed and which kept files are the largest — usually the hint needed to add an exclude glob.

Deploy from the detail page’s Deploy button — or from the empty state itself when nothing has shipped yet. The CLI path is unchanged: pbc pocketbase deploy, pbc frontend deploy, and pbc backend deploy record the same rows.

The CLI’s command is now pbc, and the names around it moved with it:

Was	Is
pb	pbc
pb.json	pbc.json
PB_TOKEN, PB_ENV, PB_INSTALL_DIR, …	PBC_TOKEN, PBC_ENV, PBC_INSTALL_DIR, …
~/.config/pb/config.json	~/.config/pbc/config.json

$ pbc --version
pbc 0.6.0

Every old name still works, so nothing you already wrote has to change.

• pb is installed alongside pbc and runs the same binary — npm i -g @pocketbasecloud/cli links both names, the curl | sh installer writes pbc and links pb beside it, and pbc upgrade moves the pair together.
• A directory holding a pb.json is read from it and written back to it, so a repository you already committed never grows a second file and its diffs stay about the binding. New directories get pbc.json.
• A PB_* variable is read whenever its PBC_* twin is unset, so an existing CI job keeps authenticating.
• Your saved login is carried over: the old config is read until the first time the CLI writes one, which lands in the new location and leaves the old file untouched.

The one thing to do by hand is a repository secret. Workflows written by pbc cloud ci init now read secrets.PBC_TOKEN. Workflows you already have keep working — the secret name is yours, and the action passes whatever you give its token: input — so change it only when you want to. If you regenerate a workflow with --force, the command tells you when the one it replaced named the old secret.

Upgrade the way you installed it — pbc upgrade for the standalone binary, npm i -g @pocketbasecloud/cli@latest for npm. See Installing the CLI.

pbc cloud ci init writes the GitHub Actions workflow that deploys the current directory, wired to a new official action:

$ pbc cloud ci init
Wrote .github/workflows/deploy.yml — deploys this frontend on every push to main.

Two things left, both one-time:
  1. Copy your token: portal → Account → CLI access token → Copy.
  2. Add it as a repository secret named PBC_TOKEN:
     Settings → Secrets and variables → Actions → New repository secret.

Then commit both files:
  git add .github/workflows/deploy.yml pbc.json
  git commit -m "Deploy on push"

The generated file:

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - uses: pocketbasecloud/cli/[email protected]
        with:
          token: ${{ secrets.PBC_TOKEN }}
          kind: frontend

pocketbasecloud/cli/action installs pbc, checks the token before touching anything, and deploys — the same --no-input --json call the CLI has always supported. What it adds: a PocketBase deploy’s record carries adminUsername/adminPassword, and GitHub only masks values it has been told are secret. The action masks both before it reads anything else in the record, and only ever publishes six fields (url, id, name, status, kind, environment) as step outputs — the raw JSON never reaches the log.

Existing hand-written workflows keep working unchanged; pbc cloud ci init generates the same thing you’d otherwise write by hand, including concurrency and timeout-minutes, which are easy to forget and expensive to miss. See Deploying from GitHub Actions and the CI/CD reference.

PocketBase instances can now serve a domain you own, the same way frontends and backends already can. The instance’s detail page gets a Domains section, and the CLI grows a matching command:

$ pbc cloud pb domain add api.example.com --name my-app
OK: add api.example.com.
$ pbc cloud pb domain verify api.example.com --name my-app

The platform writes the serving configuration the moment you add the domain, so the instance answers on it as soon as your DNS points here — a CNAME to {instance-id}.pocketbasecloud.com for subdomains, an A record for root domains, or a _pbc-verify TXT record when you proxy through Cloudflare. The TLS certificate arrives automatically on the first request.

Verification also makes the domain exclusively yours: no other deployment can verify the same name while you hold it, and developers you share the project with through an organization can manage it too. Custom domains require the Starter or Pro plan.

Free-plan PocketBase instances now carry a fair-use guard rail: 500 API requests per hour, applied to /api paths only.

When an instance exceeds the hour’s budget, its API answers 429 until the counter resets at the top of the next hour. Nothing else changes — the instance keeps running, the admin panel stays reachable, and no data is ever deleted. Upgrading to Starter or Pro lifts the limit immediately (those plans have no request limit), and the instance page in the dashboard now shows a live hourly-usage bar for Free-plan instances.

pbc cloud locations answers the question --location used to leave open: which regions can a new deployment actually land in.

$ pbc cloud locations
Deployable regions (plan: starter):
CODE  REGION
hil   Hillsboro, OR
sin   Singapore
Omit --location and the platform picks the least-loaded one.

The list comes from the platform’s own placement rules, not the provider catalog — a provider sells many regions where we run no servers at all, and picking one of those made a deploy fail with noServerAvailable seconds after it started. The command shows the region code, a city name (never a bare code), and the plan the answer is for.

--project <id> answers for that project’s owner, which is what matters for a project shared with an organization; without it the answer is about you. --json prints the machine-readable form:

{"ownerPlan":"starter","locations":["hil","sin"]}

The same list now guards the flag itself: pbc cloud pb create --location fsn1 (and pbc cloud frontend deploy --location fsn1) fails before anything is created, naming the regions that are actually available instead of leaving you to read a provisioning error afterwards.

pbc cloud pb create gives you a running PocketBase instance with nothing deployed to it:

$ pbc cloud pb create my-app-db
✓ Creating my-app-db — my-app-db is running
  https://my-app-db.pocketbasecloud.com
  https://my-app-db.pocketbasecloud.com/_/ (admin)
Admin login: [email protected] / xxxxxxxxxxxxxxxxxxxx
Recorded in pbc.json as environment "production" — `pbc cloud pb deploy` here needs no --name.

Until now the only way to create one from the CLI was pbc cloud pb deploy, which is a directory command — it infers a build config, packages pb_public / pb_hooks / pb_migrations, and asks which dotenv file the environment uses, all before it creates anything. That is right for “ship this directory” and beside the point for “give me a database”, which is what a script, a CI step, or a first day on a project actually wants.

create skips all of it: nothing is built, packaged, or uploaded. What it does keep is the binding — the instance is recorded in the directory’s pbc.json under its environment, exactly as a deploy would record it, so shipping files to it later takes no flags:

pbc cloud pb create my-app-db   # in the directory the project will live in
# …add pb_hooks/, pb_migrations/, pb_public/
pbc cloud pb deploy             # no --name: the binding is already there

--env <name> records it under another environment (default: production, or the file’s own default). A directory bound to frontends or backends is refused, and so is an environment that already names an instance — repointing it would leave the old one with nothing pointing at it.

It takes the same --location, --compute, --admin-email, --admin-password and --pb-version flags as a deploy, picks the compute the same way, and prints the same JSON under --json. A name already used by an instance in the project is refused rather than duplicated, and the refusal names pbc cloud pb deploy --name <name> as the way to redeploy that one.

pbc cloud pb deploy is unchanged, including its own way of creating an empty instance: a directory holding none of the three PocketBase directories still deploys, sends no archive at all, and says so rather than reporting a silent success.

Deploying a PocketBase instance from a directory with no pb_public, pb_hooks or pb_migrations is a supported way to get a bare instance — but pbc cloud pb deploy was still attaching an archive to it, one describing zero files. The platform’s unzip refuses an archive like that outright, so the instance failed to come up. The CLI now sends no archive at all in that case, and says plainly that it found nothing to deploy, rather than reporting a successful deploy of an empty instance. The same applied to a redeploy whose configured pb_public happened to be empty.

Separately, uploading an archive with neither pb_migrations nor pb_public at its root — a built site zipped from the inside, most often — was reported as “the files could not be written to the running instance … try the upload again.” Nothing had been written and nothing was wrong with the instance: the archive was the wrong shape, and retrying it could never work. That failure now has its own message in both the dashboard and the CLI, naming the directories it expected and confirming your instance is untouched and still running.

pbc cloud deploy now works in any deployable directory. It reads what is there, decides whether it holds a PocketBase instance, a static site, or a backend, and runs pbc cloud pb deploy, pbc cloud frontend deploy, or pbc cloud backend deploy accordingly:

$ pbc cloud deploy
Detected a frontend (vite.config.ts) — running `pbc cloud frontend deploy`.

The deploy itself is unchanged — same flags, same steps, same output. Only the choice is automatic, and the line above names both the kind and the file that decided it.

The strongest signal is the kind already recorded in pbc.json, so a directory you have deployed before is never re-guessed. After that it reads pb_hooks/pb_migrations/pb_public, next.config.* (output: "export" is a frontend, anything else a backend), the usual bundler configs, deno.json, then package.json dependencies and scripts, and finally an index.html.

Naming a kind still wins outright — pbc cloud deploy backend — which is also how you deploy a directory the rules do not recognise. Under --no-input or --json an unrecognised directory fails with the three explicit commands rather than waiting on a prompt, so nothing in CI can hang on this.

Uploading a new archive to a running PocketBase instance installed pb_migrations and pb_public and ignored pb_hooks entirely. Hooks had to travel separately, which made the first deploy and every one after it two different operations.

Now an archive can carry all three. pb_hooks is merged — files you don’t include are left alone — and lands in the Hooks editor and on the instance at the same moment, so the two can never show different code. pb_migrations is still merged and pb_public still replaced, and pb_data and the PocketBase binary remain unreachable from an upload.

pbc cloud pb deploy no longer pushes hooks as a separate step: they ride in the archive, so a redeploy is one upload and one restart instead of two of each. pbc cloud hooks push is unchanged for pushing hooks on their own.

Failures now name the file. Hooks have to be flat files directly under pb_hooks/ — the platform cannot create a subdirectory for them — so an archive containing pb_hooks/lib/helpers.js is refused rather than quietly dropping the file, which used to surface much later as a require error inside the running instance. The dashboard and the CLI now show which file was the problem, instead of a general “the deployment failed”. Nothing is written when a deploy is refused: your instance keeps running exactly as it was.

status.pocketbasecloud.com is now live, tracking the database, dashboard, compute, control plane, DNS, and billing as six independent components with 90 days of uptime history.

It runs entirely outside PocketBase Cloud’s own infrastructure — the page, its data, and the process that checks the platform all live on Cloudflare’s edge — so a platform outage can’t also take down the page reporting it. Each check gets three attempts before counting as failed, and a component has to fail two checks in a row before it’s shown as anything worse than operational.

Incidents that affect availability will be posted here going forward.

Three things a developer checks before trusting a host with a database, none of which existed here until now.

About answers who builds this, how the business makes money, and what the platform commits to — including the trade-offs of picking a small operation over a large one.

Security & data covers where your data physically sits, how instances are isolated from each other, how secrets are stored, and the full list of third parties that see any part of the service. It also has a section on what has not been certified, because a procurement checklist is easier to fail early than late.

Account deletion is now self-service from the portal’s new Account page. It cancels your Stripe subscription in the same step, so closing an account ends the billing relationship rather than starting an email thread. The page also shows exactly what still has to be removed first, with a link to each one, and points at the PocketBase backup that gets your whole pb_data directory out in one zip.

This changelog is new too. It exists so that “is this thing still being worked on” has an answer that is not a guess.

If you are on Pro, or deploying into a project shared with an organization, you now choose which compute a PocketBase instance, backend or frontend runs on instead of having one picked for you. One compute is used without asking; several are offered as a menu.

The CLI takes --compute <id> for the same choice. Computes are named the way you would describe them — Compute 2 — Frankfurt — rather than by an internal server name.

Redeploying never re-picks: a resource stays where it was first placed.

Every PocketBase instance, backend and frontend now has its own Usage & performance page in the portal: storage on disk, requests over time, median and p95 response times, and CPU/memory for its container.

Traffic is reported as a delta over a known window rather than a running counter, so an agent restart cannot produce a phantom spike. Disk usage is measured hourly — walking every file in an instance is expensive enough that doing it more often would show up in your response times — and carried on the five-minute rows in between.

A gap in the chart means collection failed and says so, rather than quietly drawing zero traffic.

Two fixes worth naming rather than burying.

The Stripe webhook now verifies signatures over the exact bytes Stripe sent, instead of over a re-serialized copy of the parsed body — re-serializing reorders keys and changes whitespace, which is enough to make a valid signature check pass on payloads it should not have.

Authorization checks on the portal-facing routes were tightened so that membership of an organization is verified per resource rather than inferred.

No user action is needed; both were shipped server-side.

The portal’s per-page “← Back” links have been replaced with full breadcrumb trails derived from the URL, so a page five levels deep shows Projects › Acme Storefront › PocketBase › storefront-db › Environment variables with every step clickable.

Record names resolve from the cache the pages already populate, so the trail never flashes a raw record id while it loads.

The archive you upload when creating a PocketBase instance is read once, which used to mean later changes to pb_migrations or pb_public had nowhere to go.

Now uploading a new zip on an existing instance installs both: migrations are merged so the instance’s own generated files survive, pb_public is replaced, and the instance restarts only when migrations actually changed. pb_data and the PocketBase binary are never writable from an upload.

pbc cloud pb deploy uses this path on every redeploy, so the CLI workflow is now the same on the first deploy and the hundredth.