What shipped, and when.

Creating a preview with a copy of your data could fail with “the instance failed to restart”, even though nothing was wrong with your hooks or migrations. Each step of setting up the preview restarted it, and on a fast server those restarts came too close together.

A new preview is now started once, after its hooks, migrations, public files and environment variables are all in place. Creating one is faster, and the restart error is gone. A preview that cannot be started is reported as failed rather than ready.

Deleting a hook from your project used to leave it running on the instance: an uploaded archive merged pb_hooks, so old hooks piled up until you removed them by hand.

Now a deploy that carries pb_hooks replaces it, the way pb_public already was. Hooks that are not in the upload are removed, whether you deploy from the dashboard, pbc pocketbase deploy or GitHub. An upload without pb_hooks leaves your hooks alone, and pb_migrations is still merged.

The deploy is one revision in History, so a hook you did not mean to remove is one restore away. If the instance does not start after the deploy, the previous files are put back and the failing line is named.

A frontend or backend can now be private. Turn on Private in its Settings and list who may open it, one email per line, or @company.com for a whole team. Visitors sign in with their PocketBase Cloud account first; anyone not on the list is kept out. Project members always have access.

Available on the Starter and Pro plans. See Private Apps.

PocketBase instances on Starter and Pro can now send email without an email provider. Open the instance’s new Email page and switch on Managed email: verification, password reset and sign-in code emails work straight away. New apps start at 100 emails a day and move up to the plan’s limits after a week of healthy sending. Every email includes an unsubscribe link, and sending pauses automatically if something looks like spam. Read the guide.

A deploy that breaks your site or API is now one click from undone. Every earlier successful deployment in a frontend’s or backend’s Deployments list has a Roll back button: its build goes live again as a new deployment, so you can roll forward the same way. For apps connected to GitHub, the confirmation links the comparison of what the rollback undoes.

From the terminal, pbc frontend rollback and pbc backend rollback go back to the deployment before the live one, or to any other with --to <id>; pbc frontend deployments and pbc backend deployments list them. AI assistants connected through the MCP server use rollback_deployment.

The last 20 successful builds of each app are kept. A backend keeps its current environment variables; only the code goes back. See Rolling back.

Every change to a PocketBase instance’s pb_hooks, pb_migrations and pb_public is now saved as a numbered revision: from the portal, pbc, an AI assistant, a GitHub push, or the instance itself when it writes a migration after a schema change. History in the instance’s sidebar shows who changed what, and lets you read any file as it was.

Restore any revision in one step. Files only puts hooks and public files back; Files and schema also reverts the migrations added since with their down parts, with the database copied aside first. Every restore is a revision too, so it can be undone the same way.

From the terminal: pbc pocketbase revisions ls, revisions diff, revisions restore [--schema], and pbc pocketbase pull to download the files into a directory. AI assistants connected through the MCP server use list_revisions, preview_restore_revision and restore_revision. See Version History.

Free-plan PocketBase instances can now serve 5,000 API requests per hour, up from 500. The limit behaves exactly as before: only /api paths count, the admin panel and static files never do, you get an email at 80%, and past the limit the API answers 429 until the top of the hour while your data stays untouched. Starter and Pro remain unlimited.

Signing up used to end on the Plan page: nothing could be deployed until you finished a $0 Stripe checkout for the Free plan. Now every new account is on Free from the first second — one PocketBase instance and five frontends — and the first deploy is one click away.

The card comes later. You have 7 days to try the platform with nothing on file. To keep the Free plan after that, add a card from the Plan page; it creates the same $0 subscription as before and you are never charged. We mail a reminder on days 4 and 6 if an instance is running.

If the trial ends with no card, new deploys are refused and a running instance is paused. Nothing is deleted, exporting still works, and subscribing starts it again automatically. Accounts that signed up earlier and never subscribed get the same 7 days, counted from their next sign-in.

pbc whoami now shows the days left on the trial.

Creating a PocketBase instance can rarely fail part way, leaving the instance marked as errored before it has a running unit. If you deployed to it anyway, the deploy could report that a pb_hooks file could not be installed — even though the file was written and the real problem was that the instance was not running.

A deploy to an instance that never finished setting up is now refused up front. The message says the instance did not finish setting up, that nothing was changed, and to contact support so we can finish it. Instances that are already running are unaffected: a failed deploy can still be fixed and deployed again.

The server also starts and waits for the instance’s systemd user manager before finishing setup, so the race that produced the half-created instance is far less likely to happen at all.

A ZIP whose project sits inside a folder inside another folder, such as My App/my-app/pb_hooks, now deploys. Earlier, only one wrapper folder was removed, so a PocketBase archive like that had “nothing to deploy” and a backend had no runtime. System files such as .DS_Store, __MACOSX, Thumbs.db and desktop.ini are now left out of every upload, from the portal and from pbc --zip, so they no longer get in the way either.

If you deploy a project to the wrong kind of resource, you’re now told what it is and where it goes. For example, PocketBase source dropped on a backend used to fail with “We could not tell which runtime this backend needs”. The portal now says it’s PocketBase source and offers Create PocketBase Instance. pbc backend deploy stops before uploading and prints the pbc pocketbase deploy command to run instead.

This only happens when the deploy would fail anyway. A project that deploys today deploys exactly as before, and an explicit --runtime or pbc.json build block is always respected.