What shipped, and when.

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 pocketbase deploy uses this path on every redeploy, so the CLI workflow is now the same on the first deploy and the hundredth.