Self-driving (Beta)

Self-driving watches your running apps. When something breaks in production — a crash loop, an error spike, requests failing in the browser — it records the problem as a finding with the evidence and a likely cause. If the problem is critical or keeps coming back, it works on a copy of your connected repository in an isolated sandbox and opens a pull request with the fix.

You can also start a fix yourself on any open problem, with a note that tells the agent where to look. When a fix is ready, or a problem needs you, you get an email and a notification in the portal.

It never merges, never deploys and never touches your running instance. You review the pull request like any other, and nothing ships without you.

Self-driving is in beta and free on every plan while it is, within daily and monthly run limits. You turn it on in the portal or with the CLI; the rest of the setup happens in the portal.

Prerequisites

• A project with at least one deployed resource (Creating a Project)
• A GitHub repository with the resource’s source code
• For the CLI path: pbc installed and logged in (Installing the CLI)

What it watches

The browser findings need error collection switched on for the frontend (Step 3).

Step 1: Connect a repository

A fix is a pull request, so self-driving needs to know where the code lives.

Using the portal

1. Open the resource (PocketBase instance, frontend or backend) in the portal
2. Choose Connect a repository and pick the repository, branch and, for a monorepo, the directory

The CLI has no command for this — connecting installs the PocketBase Cloud GitHub App, which runs through GitHub in the browser. Connecting a repository also lets every push to that branch deploy the resource; see Deploying from GitHub.

If a project has findings on a resource with no repository, the Self-driving page shows a Connect a repository to enable fixes banner with a shortcut.

Step 2: Turn on self-driving

Nothing is dispatched for any of your projects until this is on. The setting covers every project on your account. To leave one project out, open it, choose Settings, and switch off Self-driving for this project.

Only the project owner can turn self-driving on. Other members of an organization see whether it is on, and can start fixes once it is.

Using the portal

1. Open Account in the portal and scroll to Self-driving
2. Switch on Self-driving

Using the CLI

pbc self-driving enable
pbc self-driving status      # shows whether it is allowed and whether the TypeSafe judge is on
pbc self-driving disable

Step 3: Collect browser errors from a frontend

Optional, and only for frontends. Server-side findings work without it.

Using the portal

1. Open the frontend in the portal and choose Turn On on the overview, or open its Settings page
2. Switch on Browser Errors
3. Deploy the frontend again — collection takes effect on the next deploy

To collect from every frontend in an organization, the organization owner can switch on Collect on all frontends under Browser Errors on the organization’s page instead. A frontend can still switch itself off on its own Settings page.

Frontends built from source get the collection script automatically. For an uploaded build, copy the snippet shown on the card into your HTML and deploy again.

The CLI has no switch for this; use the portal.

Step 4: Review the fix

You get an email and a portal notification when a pull request is ready, and when a problem needs you. Each links straight to the problem.

Using the portal

1. Open the project and click Self-driving in the sidebar
2. The tiles sort problems by outcome:
   • Ready to review: a fix pull request is waiting for you
   • Fixing now: a fix is queued, running, or merged and being checked
   • Needs you: a fix failed, its pull request was closed, or the agent decided a person should look
   • Resolved: the app is working again and the problem stopped happening
3. Open a problem to see what happened, the evidence and the suggested cause
4. When it says Fix ready, open the pull request from the problem, review it, and merge it on GitHub if it is right

If auto-deploy is on for the connected branch, merging the pull request deploys the fix. Until the fix is running, the problem says Fix merged, not deployed yet. Once it is running and the problem stays away, it shows Fixed by pull request. If the problem happens again after the fix is running, it moves to Needs you as Fix deployed, but it happened again, and you can try again with a note.

When a problem counts as resolved

A problem is resolved only when there is evidence the app works again, not just because it went quiet:

• A service that stopped or ran out of memory must be seen running again.
• An error in your app must stay away while the app is actually serving requests. A browser error must stay away while visitors use the page.

A quiet problem that can’t be confirmed yet stays open and says why, for example Quiet, but nothing has used it since. If code changed in the files where it failed since the problem started, the problem names those files. Self-driving checks this against the commit you have deployed, so it needs a connected repository; for uploaded deploys only the running app counts.

Below the tiles, Watching lists problems self-driving has not tried yet (ones that aren’t critical and haven’t come back), and Dismissed lists the ones you set aside. The same line shows how many of today’s and this month’s fixes you have used.

The CLI does not list problems; review them in the portal.

Start a fix yourself

Self-driving starts on its own for critical problems and ones that come back. For anything else, or to retry, do it yourself:

1. Open the problem
2. Choose Fix This, or Try Again after a failed or closed attempt
3. Optionally add a note, such as the file or route to look at, then start it

A fix you start counts toward the same daily and monthly limits. The button says why when a fix can’t start, for example when the app has no connected repository or the limit is used up.

Dismiss a problem

Choose Dismiss on a problem and pick Not Useful or False Alarm. Self-driving stops starting fixes for it on its own, and it moves to Dismissed. Undo Dismiss brings it back. You can still start a fix on a dismissed problem yourself.

Bring your own model keys

By default, runs use PocketBase Cloud’s model key. To pay your own providers instead:

1. Open Account → Self-driving in the portal
2. Switch on Pay with your own model keys
3. Enter a Model key and, if you use the judge, a TypeSafe key
4. Click Save Keys

This only changes who pays. The Self-driving switch still decides whether self-driving runs at all. Keys are stored encrypted, sent only to the run sandbox, and never shown back — to change one, enter a new key or click Remove. Keys are managed in the portal only.

Double-check fixes with TypeSafe

With Double-check fixes with TypeSafe on (Account → Self-driving), the finding and the proposed diff are checked by TypeSafe before a pull request opens, to confirm the change addresses the cause and is safe to propose. Turn it off to skip that check. pbc self-driving status shows whether it is on; the switch itself is in the portal.

What the platform does for you

• Isolated runs. Each run works on a copy of your repository in a sandbox on a separate machine from your apps. It cannot reach your running instance.
• Pull requests only. The output is a branch and a pull request. Merging and deploying stay with you.
• Bounded cost. Runs count toward daily and monthly limits on your account, so a noisy problem cannot run away.

Next steps

• Continuous backup
• Deploying a frontend
• Plans and billing
• Self-driving (Beta): Production Problems Arrive as Pull Requests