What shipped, and when.

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

$ pb 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: pb create --location fsn1 (and pb 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.

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

$ pb 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 pb.json as environment "production" — `pb cloud pb deploy` here needs no --name.

Until now the only way to create one from the CLI was pb 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 pb.json under its environment, exactly as a deploy would record it, so shipping files to it later takes no flags:

pb cloud pb create my-app-db   # in the directory the project will live in
# …add pb_hooks/, pb_migrations/, pb_public/
pb 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 pb cloud pb deploy --name <name> as the way to redeploy that one.

pb 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 pb 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.

pb 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 pb cloud pb deploy, pb cloud frontend deploy, or pb cloud backend deploy accordingly:

$ pb cloud deploy
Detected a frontend (vite.config.ts) — running `pb 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 pb.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 — pb 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.

pb 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. pb 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.

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