What shipped, and when.

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.

You no longer have to wait for self-driving to pick a problem. Open any open problem and choose Fix This, or Try Again after a failed or closed attempt. Add a note such as “the bug is in pb_hooks/orders.pb.js” and the agent starts there. Fixes still arrive as pull requests; nothing merges or deploys without you.

• You hear about it. When a pull request is ready, or a problem needs you, you get one email and a notification in the portal with a link straight to it.
• Dismiss noise. Mark a problem Not Useful or False Alarm and self-driving stops trying to fix it. Undo Dismiss brings it back.
• Per-project switch. Turn self-driving off for a single project under Project Settings, and leave it on everywhere else.
• See your limit. The Self-driving page shows how many of today’s and this month’s fixes you’ve used.
• Know it worked. A problem that stops after its fix is merged shows Fixed by pull request.

A Service Stopped problem showed Resolved half an hour after the service went down, while it was still down. Errors on a page or route nobody visited did the same, then came back as new problems on the next visit.

A problem now resolves only when the app shows it’s working: a stopped service has to be seen running again, and an error has to stay away while the app is actually serving requests or visitors. Until then it stays open and says why, such as Quiet, but nothing has used it since.

If you connected a repository, self-driving also checks your deployed code:

• A merged fix says Fix merged, not deployed yet until the commit is running, and Fixed by pull request only after that.
• A quiet problem names the files that changed where it failed, so you can tell a real fix from a quiet afternoon.

If you closed a self-driving pull request without merging it, the problem kept showing Fix ready under Ready to review. It now shows Pull request closed under Needs you, with Try Again on its page.

Needs you also listed every problem self-driving had never attempted, labelled as “couldn’t be fixed automatically”. Those now sit under Watching, below the tiles, and Needs you holds only problems where a fix failed, was declined, or needs a person.

A problem waiting for a fix that can’t start, because self-driving is off or the app has no connected repository, now says Waiting on setup instead of Fix queued.

You can now deploy Python backends: Flask, Django, FastAPI, Streamlit, Gradio and most other Python frameworks, or a plain script such as a bot or a scheduled job.

pbc deploy --name my-api

You don’t need a Dockerfile or a start command. On every deploy, PocketBase Cloud reads your project and:

• starts it the right way for its framework, listening on your backend’s address. A Procfile web: line overrides this.
• uses the Python version you pinned in .python-version, runtime.txt, pyproject.toml or Pipfile. Python 3.10 to 3.14 are supported, and 3.12 is the default. Python 2 and versions older than 3.10 are refused with a clear message.
• installs your dependencies with the tool you already use: uv, Poetry, pipenv or pip.

In the portal, drop your project folder into New Backend. The detected Python version and start command are shown before you create it.

Backends are on the Pro plan. See Deploying a Python App and Run a Python Script on a Schedule.

The Plan page showed yearly prices when you picked Yearly above the plan cards, but Subscribe still opened Stripe checkout at the monthly price. Checkout now uses the period you picked: Starter is $100/year and Pro is $250/year, billed on the day you subscribe.

Already on monthly? Switch to Yearly on the same page now switches you in one click instead of sending you to the Stripe billing portal. You’re charged the yearly price, minus a credit for the unused part of the month, and any add-ons move to yearly with your plan. If the payment doesn’t go through, nothing changes.

Grandfathered rates are unchanged: the Plan page still offers Email Support, and we set yearly up at your existing rate.

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.