What shipped, and when.

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.

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 off by default: turn it on per instance from that page or with pbc pocketbase continuous-backup enable. 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.

If you left the portal open in a tab while we deployed a new version, clicking through to a page the tab had not loaded yet could fail with Something went wrong — the page’s code had been replaced by the deploy, so the tab was asking for a file that no longer existed.

The portal already reloads itself onto the new version when that happens, but Browser engines report a missing page chunk to the app through more than one channel, and one of them reached the error screen without ever triggering the reload. That path is now covered: a missing page chunk reloads the portal onto the current version instead of showing an error, whichever way the browser reports it.

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.