What shipped, and when.

Uploading an archive containing pb_hooks installed the files and restarted the instance correctly — they were live and running. The Hooks editor disagreed: it showed those same files as Draft, the same badge a file gets when you save it in the portal without deploying.

The database record for a hook written this way was never told it was active, so it fell back to the field’s default. The file on disk was never wrong; only the badge was.

Hooks installed by pbc pocketbase deploy, a portal deployment upload, or any other archive-based install are now recorded as Live immediately, matching what’s actually running on the instance.

pb_hooks used to accept exactly three things: .pb.js, .js, and .json, all sitting flat in one directory. A hook that wanted an email template, a static HTML fragment, or a CSV of seed data had nowhere to put it — and a lib/ folder to organize a growing set of hooks was refused outright, on the portal, the CLI, and a full archive deploy alike.

The extension list is now much longer. Alongside .pb.js, .js, .mjs, .cjs, and .json, you can push .html, .htm, .css, .txt, .md, .csv, .xml, .svg, .yml, and .yaml. PocketBase’s hook loader still only executes *.pb.js — everything else is there for your hook code to require() or read, the same way a helper module always was.

Subdirectories are allowed, up to five levels deep. pb_hooks/emails/welcome.html now uploads and installs exactly where you’d expect, whether you push it from the portal’s Hooks editor, pbc pocketbase hooks push, or a full pbc pocketbase deploy. The portal editor also picks the right syntax highlighting for whatever you’re editing, instead of always assuming JavaScript.

The file-count ceiling went from 30/50 to 500, consistently across the CLI’s own guard rail and the platform’s limit — there’s no longer a gap where the CLI refuses a push the portal or a direct API call would have accepted.

Real binary files — images, PDFs, anything that isn’t text — still aren’t supported in pb_hooks; that’s what pb_public is for, and it already accepts any file type through a full deploy.

See Extending with Hooks for the full list of supported extensions and how pushing works from the CLI and the portal.

Every PocketBase instance detail page now carries a collapsible Admin Dashboard card. Expand it and the instance’s own admin UI loads inline — collections, records, settings, logs — with reload, fullscreen, and open-in-new-tab controls above the frame. Auth still happens inside the frame with your Admin Email and Admin Password; the platform never sees them.

The embed only works because PocketBase vhosts stopped sending a blanket X-Frame-Options: DENY. They now send a CSP frame-ancestors scoped to the portal origin instead, so only the portal can frame the dashboard and every other site is still refused. Frontend and backend vhosts keep the old headers. Instances provisioned before today pick this up on the next agent start — no redeploy.

If the dashboard refuses to load in the frame, the card’s Open in new tab control is the fallback.

The CLI used to hold one PocketBase instance at a time: pbc admin use <url>, then pbc admin login, and every pbc admin command acted on it. A second instance meant switching back and forth.

pbc admin login now takes the URL directly, so adding an instance is one step:

$ pbc admin login --url https://my-app-db.pocketbasecloud.com --name prod
Superuser email: [email protected]
Superuser password:
Logged in to https://my-app-db.pocketbasecloud.com (prod).

The profile is named after the URL unless --name gives it something shorter. Profiles are keyed by name, so several logins can point at the same instance — one for you, one for CI — and the saved superuser email tells them apart.

pbc admin profiles lists what’s saved, the active one starred:

ACTIVE  NAME  URL                                     ACCOUNT          STATUS
*       prod  https://my-app-db.pocketbasecloud.com    [email protected]  authenticated
        ci    https://my-app-db.pocketbasecloud.com    [email protected]   authenticated

pbc admin use --name <profile> switches the default to a saved profile, --profile <name> picks one for a single command, and pbc admin logout --profile <name> --remove forgets one.

pbc deploy detects what is in a directory and hands off to pbc pocketbase deploy, pbc frontend deploy, or pbc backend deploy — but flags are checked before that handoff happens, against the shorter command’s own list, which declared none. Anything beyond a bare pbc deploy failed outright:

$ pbc deploy --env qa
Error: unknown flag --env.
       pbc deploy --help lists every flag.

pbc deploy now declares every flag its three targets accept, so --env, --new, --zip, --compute, and the rest work the same whether you call the short form or the kind-specific command directly.

The new Templates page collects starter apps you can clone and deploy instead of wiring the same pieces up again. Each one is a working app, not a scaffold: its database, its frontend, and the steps that put them live are already in the repository.

Two ship today:

• Aura — a React storefront with a product catalogue, cart and checkout, and an admin dashboard for products, journal articles, and orders. It runs on bundled demo data until the setup wizard points it at your own PocketBase instance.
• Syntro — an Astro SaaS landing page with a newsletter sign-up, a contact form, and a changelog that reads from PocketBase, so publishing an entry in the dashboard needs no redeploy.

Both deploy with pbc: clone one, create a project, then deploy its database and frontend. Each template page lists the exact commands and links to the repo and a live demo.

Templates carry their own licenses — check the repo before you build on one.

Starter ($10/month) and Pro ($25/month) can now be billed yearly at two months free — $100/year and $250/year.

Subscribe monthly first, then use Switch to Yearly on the Plan page to open the Stripe billing portal and pick the yearly price. Your plan, add-ons, and deployments carry over untouched — add-ons switch to their yearly rate too, since everything on one Stripe subscription shares a billing interval. Switching back to monthly later is done in the same portal.

If you’re on an older price we’ve grandfathered, don’t switch yourself — the billing portal only lists yearly at today’s price, so switching there would cost you more than your current rate. The Plan page gives you an Email Support button instead; email us and we’ll set your yearly subscription up at your existing rate.

See Yearly billing for the full details.

Starter is now $10/month and Pro is now $25/month, up from $5 and $20. The plans themselves are unchanged — same instances, same frontends, same dedicated compute on Pro.

If you’re already subscribed, you keep the rate you signed up at. We don’t touch an existing subscription, so there is nothing to do and nothing to accept; your invoices carry on at your current price for as long as you stay on that plan.

One thing to know before you change plans: your rate protects the plan you’re on, not every plan. Moving from Starter to Pro prices Pro at today’s rate, so an upgrade is the point where a grandfathered price is given up. If that matters for a plan change you’re weighing, email us first.

See Plans & Billing for what each plan includes, or the pricing page for the full comparison.

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.