What shipped, and when.

pbc ci init writes the GitHub Actions workflow that deploys the current directory, wired to a new official action:

$ pbc ci init
Wrote .github/workflows/deploy.yml — deploys this frontend on every push to main.

Two things left, both one-time:
  1. Copy your token: portal → Account → CLI access token → Copy.
  2. Add it as a repository secret named PBC_TOKEN:
     Settings → Secrets and variables → Actions → New repository secret.

Then commit both files:
  git add .github/workflows/deploy.yml pbc.json
  git commit -m "Deploy on push"

The generated file:

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - uses: pocketbasecloud/cli/action@v0.5.0
        with:
          token: ${{ secrets.PBC_TOKEN }}
          kind: frontend

pocketbasecloud/cli/action installs pbc, checks the token before touching anything, and deploys — the same --no-input --json call the CLI has always supported. What it adds: a PocketBase deploy’s record carries adminUsername/adminPassword, and GitHub only masks values it has been told are secret. The action masks both before it reads anything else in the record, and only ever publishes six fields (url, id, name, status, kind, environment) as step outputs — the raw JSON never reaches the log.

Existing hand-written workflows keep working unchanged; pbc ci init generates the same thing you’d otherwise write by hand, including concurrency and timeout-minutes, which are easy to forget and expensive to miss. See Deploying from GitHub Actions and the CI/CD reference.

PocketBase instances can now serve a domain you own, the same way frontends and backends already can. The instance’s detail page gets a Domains section, and the CLI grows a matching command:

$ pbc pocketbase domain add api.example.com --name my-app
OK: add api.example.com.
$ pbc pocketbase domain verify api.example.com --name my-app

The platform writes the serving configuration the moment you add the domain, so the instance answers on it as soon as your DNS points here — a CNAME to {instance-id}.pocketbasecloud.com for subdomains, an A record for root domains, or a _pbc-verify TXT record when you proxy through Cloudflare. The TLS certificate arrives automatically on the first request.

Verification also makes the domain exclusively yours: no other deployment can verify the same name while you hold it, and developers you share the project with through an organization can manage it too. Custom domains require the Starter or Pro plan.

Free-plan PocketBase instances now carry a fair-use guard rail: 500 API requests per hour, applied to /api paths only.

When an instance exceeds the hour’s budget, its API answers 429 until the counter resets at the top of the next hour. Nothing else changes — the instance keeps running, the admin panel stays reachable, and no data is ever deleted. Upgrading to Starter or Pro lifts the limit immediately (those plans have no request limit), and the instance page in the dashboard now shows a live hourly-usage bar for Free-plan instances.

pbc locations answers the question --location used to leave open: which regions can a new deployment actually land in.

$ pbc locations
Deployable regions (plan: starter):
CODE  REGION
hil   Hillsboro, OR
sin   Singapore
Omit --location and the platform picks the least-loaded one.

The list comes from the platform’s own placement rules, not the provider catalog — a provider sells many regions where we run no servers at all, and picking one of those made a deploy fail with noServerAvailable seconds after it started. The command shows the region code, a city name (never a bare code), and the plan the answer is for.

--project <id> answers for that project’s owner, which is what matters for a project shared with an organization; without it the answer is about you. --json prints the machine-readable form:

{"ownerPlan":"starter","locations":["hil","sin"]}

The same list now guards the flag itself: pbc pocketbase create --location fsn1 (and pbc frontend deploy --location fsn1) fails before anything is created, naming the regions that are actually available instead of leaving you to read a provisioning error afterwards.

pbc pocketbase create gives you a running PocketBase instance with nothing deployed to it:

$ pbc pocketbase create my-app-db
✓ Creating my-app-db — my-app-db is running
  https://my-app-db.pocketbasecloud.com
  https://my-app-db.pocketbasecloud.com/_/ (admin)
Admin login: you@example.com / xxxxxxxxxxxxxxxxxxxx
Recorded in pbc.json as environment "production" — `pbc pocketbase deploy` here needs no --name.

Until now the only way to create one from the CLI was pbc pocketbase deploy, which is a directory command — it infers a build config, packages pb_public / pb_hooks / pb_migrations, and asks which dotenv file the environment uses, all before it creates anything. That is right for “ship this directory” and beside the point for “give me a database”, which is what a script, a CI step, or a first day on a project actually wants.

create skips all of it: nothing is built, packaged, or uploaded. What it does keep is the binding — the instance is recorded in the directory’s pbc.json under its environment, exactly as a deploy would record it, so shipping files to it later takes no flags:

pbc pocketbase create my-app-db   # in the directory the project will live in
# …add pb_hooks/, pb_migrations/, pb_public/
pbc pocketbase deploy             # no --name: the binding is already there

--env <name> records it under another environment (default: production, or the file’s own default). A directory bound to frontends or backends is refused, and so is an environment that already names an instance — repointing it would leave the old one with nothing pointing at it.

It takes the same --location, --compute, --admin-email, --admin-password and --pb-version flags as a deploy, picks the compute the same way, and prints the same JSON under --json. A name already used by an instance in the project is refused rather than duplicated, and the refusal names pbc pocketbase deploy --name <name> as the way to redeploy that one.

pbc pocketbase deploy is unchanged, including its own way of creating an empty instance: a directory holding none of the three PocketBase directories still deploys, sends no archive at all, and says so rather than reporting a silent success.

Deploying a PocketBase instance from a directory with no pb_public, pb_hooks or pb_migrations is a supported way to get a bare instance — but pbc pocketbase deploy was still attaching an archive to it, one describing zero files. The platform’s unzip refuses an archive like that outright, so the instance failed to come up. The CLI now sends no archive at all in that case, and says plainly that it found nothing to deploy, rather than reporting a successful deploy of an empty instance. The same applied to a redeploy whose configured pb_public happened to be empty.

Separately, uploading an archive with neither pb_migrations nor pb_public at its root — a built site zipped from the inside, most often — was reported as “the files could not be written to the running instance … try the upload again.” Nothing had been written and nothing was wrong with the instance: the archive was the wrong shape, and retrying it could never work. That failure now has its own message in both the dashboard and the CLI, naming the directories it expected and confirming your instance is untouched and still running.

pbc deploy now works in any deployable directory. It reads what is there, decides whether it holds a PocketBase instance, a static site, or a backend, and runs pbc pocketbase deploy, pbc frontend deploy, or pbc backend deploy accordingly:

$ pbc deploy
Detected a frontend (vite.config.ts) — running `pbc frontend deploy`.

The deploy itself is unchanged — same flags, same steps, same output. Only the choice is automatic, and the line above names both the kind and the file that decided it.

The strongest signal is the kind already recorded in pbc.json, so a directory you have deployed before is never re-guessed. After that it reads pb_hooks/pb_migrations/pb_public, next.config.* (output: "export" is a frontend, anything else a backend), the usual bundler configs, deno.json, then package.json dependencies and scripts, and finally an index.html.

Naming a kind still wins outright — pbc deploy backend — which is also how you deploy a directory the rules do not recognise. Under --no-input or --json an unrecognised directory fails with the three explicit commands rather than waiting on a prompt, so nothing in CI can hang on this.

Uploading a new archive to a running PocketBase instance installed pb_migrations and pb_public and ignored pb_hooks entirely. Hooks had to travel separately, which made the first deploy and every one after it two different operations.

Now an archive can carry all three. pb_hooks is merged — files you don’t include are left alone — and lands in the Hooks editor and on the instance at the same moment, so the two can never show different code. pb_migrations is still merged and pb_public still replaced, and pb_data and the PocketBase binary remain unreachable from an upload.

pbc pocketbase deploy no longer pushes hooks as a separate step: they ride in the archive, so a redeploy is one upload and one restart instead of two of each. pbc pocketbase hooks push is unchanged for pushing hooks on their own.

Failures now name the file. Hooks have to be flat files directly under pb_hooks/ — the platform cannot create a subdirectory for them — so an archive containing pb_hooks/lib/helpers.js is refused rather than quietly dropping the file, which used to surface much later as a require error inside the running instance. The dashboard and the CLI now show which file was the problem, instead of a general “the deployment failed”. Nothing is written when a deploy is refused: your instance keeps running exactly as it was.

status.pocketbasecloud.com is now live, tracking the database, dashboard, compute, control plane, DNS, and billing as six independent components with 90 days of uptime history.

It runs entirely outside PocketBase Cloud’s own infrastructure — the page, its data, and the process that checks the platform all live on Cloudflare’s edge — so a platform outage can’t also take down the page reporting it. Each check gets three attempts before counting as failed, and a component has to fail two checks in a row before it’s shown as anything worse than operational.

Incidents that affect availability will be posted here going forward.

Three things a developer checks before trusting a host with a database, none of which existed here until now.

About answers who builds this, how the business makes money, and what the platform commits to — including the trade-offs of picking a small operation over a large one.

Security & data covers where your data physically sits, how instances are isolated from each other, how secrets are stored, and the full list of third parties that see any part of the service. It also has a section on what has not been certified, because a procurement checklist is easier to fail early than late.

Account deletion is now self-service from the portal’s new Account page. It cancels your Stripe subscription in the same step, so closing an account ends the billing relationship rather than starting an email thread. The page also shows exactly what still has to be removed first, with a link to each one, and points at the PocketBase backup that gets your whole pb_data directory out in one zip.

This changelog is new too. It exists so that “is this thing still being worked on” has an answer that is not a guess.