What shipped, and when.

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

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

$ pbc 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 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 pocketbase domain add api.example.com --name my-app
OK: add api.example.com.
$ pbc pocketbase 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.