What shipped, and when.

Continuous backup changed in two ways.

It is off by default. New paid instances no longer start replication on their own. Turn it on from the instance’s Continuous Backup page when you want every database change copied off-site, or from the CLI:

pbc pocketbase continuous-backup enable --name my-app

Turning it off deletes the restore points. Turning continuous backup off stops replication and permanently deletes every restore point already copied off-site, so nothing of the old backup is left behind. The instance’s own database is untouched. The portal’s confirmation dialog and the pbc pocketbase continuous-backup disable output both say this before the delete happens. If you want to keep the restore points, leave continuous backup on.

See Continuous Backup.

Frontends now have a build environment: variables the platform sets while it builds your frontend from source, such as a GitHub push or a template deploy. Use it for values like VITE_POCKETBASE_URL that your framework reads at build time.

Add variables under Build Environment on the frontend’s page in the portal, or from the CLI:

pbc env set VITE_POCKETBASE_URL=https://my-db.example.com --target frontend --name my-site
pbc env import .env.production --target frontend --name my-site

Any variable name works except a few the build platform sets itself, such as HOME and PATH. Values are stored unencrypted and visible to anyone with access to the frontend, and variables your framework exposes to the browser (such as VITE_ or NEXT_PUBLIC_) end up in the public bundle. The install step sees them too, so a private-registry token like NPM_TOKEN works. They are limited to 10 KB in total, and values of 8 or more characters are masked in build logs. pbc frontend deploy and ZIP uploads build on your own machine, so they keep using your shell’s environment.

Browser error collection moved to the frontend’s Settings page.

See Deploying a Frontend.

Three things that used to need a person on call now happen on their own.

Deploy from GitHub. Connect a repository to a PocketBase instance, a frontend or a backend, pick the branch and, for a monorepo, the directory. Every push to that branch builds and deploys. You can turn auto-deploy off and deploy a commit by hand from the resource page instead. The CLI and GitHub Actions keep working alongside it. See Deploying from GitHub.

Continuous backup. On Starter and Pro, every change to your database is copied off-site as it happens by Litestream. You can restore the instance to any point in the last 7 days from its Continuous Backup page in the portal, and check or switch it with pbc pocketbase continuous-backup. It is on by default for new paid instances. It covers the database, not uploaded files, so keep taking the standard PocketBase backup from Settings → Backups for those. See Continuous Backup.

Self-driving (beta). When production records a real problem, such as a crash loop, an error spike or failing requests, the finding explains the cause with evidence. Turn on self-driving and it works on a copy of your connected repository in an isolated sandbox and opens a pull request with the fix. It never merges or deploys; you review the PR like any other, and merging it deploys through the push above. It is free on every plan during the beta, within daily and monthly run limits. Turn it on with pbc self-driving enable. Runs use our model key by default. To use your own, turn on Bring your own model keys in your account settings; keys are stored encrypted and sent only to the run sandbox. See Self-driving.

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.