What shipped, and when.

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.