What shipped, and when.

pbc backend deploy picks the project from pbc.json or pbc project use before it does anything else. If that project happened to be a personal one on the free or starter plan, the deploy ran all the way to the end and then failed with “Backend deployments require a Pro plan” — even when you belong to an organization whose Pro owner has a project that would have accepted the backend.

Now the CLI checks the resolved project first. When it can’t host a backend, an interactive deploy lists your other projects so you can send the backend to one that qualifies; under --no-input or --json it tells you to pass --project. Backends still run on the project owner’s Pro compute, so a developer in a shared organization project never has to see or pay for it.

pbc self upgrade used to print one line at the end: upgraded or switched, old version to new. It now narrates the steps as it takes them:

$ pbc self upgrade
==> Updating pbc from 0.8.2 to 0.8.3
==> Detected platform: macOS arm64
==> Resolved version: 0.8.3
==> Downloading pbc
==> Installing standalone package to /usr/local/bin/pbc
==> /usr/local/bin is already on PATH
pbc 0.8.3 installed successfully.

🎉 Update ran successfully! Please restart your terminal session.

npm installs are deprecated. 0.8.3 is the last version published to npm. From here, install with:

curl -fsSL https://raw.githubusercontent.com/pocketbasecloud/cli/main/scripts/install.sh | sh

If you installed with npm, pbc self upgrade will tell you to reinstall once from the command above — after that, upgrades work in place like any other install.

The CLI now tells you plainly when it’s too old for something, instead of a generic error:

pbc 0.8.1 is too old (minimum: 0.8.3). Run pbc self upgrade.

Run that command and you’re back in business.

Pro’s dedicated 2 vCPU / 4GB compute was available in seven regions: Gravelines, Limburg, Erith, Warsaw, Beauharnois, Singapore, and Sydney. Five more are now selectable at checkout and on the plan page:

Japan
India
US Central
US East
US West

Same spec, same price as every other Pro region. The five new locations may take a little longer to come online than the original seven, since they’re set up individually rather than instantly — everything else about picking one is identical.

Pro has no cap on PocketBase or Frontend slots, but the create pages could still show a confusing raw -1 in the usage count instead of saying so plainly. Both pages now read Unlimited slots on Pro, matching what the plan page and sidebar already showed.

The status page’s “degraded” state used the same amber for its text badge and its uptime bar segment. Against the bar’s lighter background, that shade read closer to brown than amber, and stood out less clearly than the up/down states next to it.

Degraded now uses a darker amber for text and badges, and a separate, brighter amber for the bar itself — clearer at a glance in both places.

A long organization or project name — the kind an institution or a backfilled account can end up with — was cut off in the header breadcrumb with no way to read the rest.

Mobile. The breadcrumb strip already scrolls sideways; now each segment shows its full name instead of stopping at an ellipsis, so scrolling reveals the whole trail.

Desktop. Header space is still limited, so a long name stays truncated, but hovering the organization picker, the project picker, or any trail segment now shows the full name. The switcher dropdowns do the same for long entries in their lists.

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 you@example.com --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 self 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 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 self upgrade for the standalone binary, npm i -g @pocketbasecloud/cli@latest for npm. See Installing the CLI.