pb_public

Static files served at / by the same instance that serves the API. A single-page app, a landing page, a documentation build: anything that is files. It is optional, and an instance without it is simply an API.

What goes in it

An index.html here is the site. Requests that match a file get that file; requests that match nothing get 404.html, or a copy of index.html when the build did not make one, which is what a single-page app wants so its own router can handle the path. /api and /_/ are never affected.

Getting a build in there

There is no bundler here on purpose: build your frontend with whatever it already uses, and copy the output in. A line in your deploy script is usually the whole integration.

# build your frontend wherever it lives, then put the output here
cd ../web && bun run build
rm -rf ../blog-api/pb_public && cp -r dist ../blog-api/pb_public

A frontend served this way is same-origin with its API, which means the SDK needs no address at all: new PocketBase("/") and no CORS to think about.

Redirects

A _redirects file in the directory is read on deploy, in the syntax Netlify and Cloudflare Pages use: source, destination, optional status.

/old-post/:slug   /posts/:slug        301
/download         https://example.com/dl  302

Path-only rules are served at the edge, before the Worker runs. A rule whose source names a host becomes a redirect rule on the zone instead, which is how one instance behind several domains can answer differently per hostname. That second kind needs the deploy token to carry the zone's redirect permission, and the deploy says so if it cannot write them.

Somewhere else, if you prefer

--public-dir <path> on serve and deploy points at another directory, so a frontend build can stay where it is built rather than being copied. The directory has to contain an index.html, and the deploy refuses before touching anything if it does not.