pb_data
Everything a running instance owns, in one directory. It is created on the first run, it is git-ignored, and it is the thing to copy when you want to copy an instance.
Inside pb_data/:
data.db: the database, meaning your collections and their recordsstorage/: uploaded files, by collection and recordtypes.d.ts: generated, and what makes hook editing autocomplete.superuser-credentials: only when a password was generated for you
The generated typings
types.d.ts is written on startup and describes every global a hook can use. The reference comment at the top of a hook file points at it:
/// <reference path="../pb_data/types.d.ts" />That single line is what turns pb_hooks from untyped scripting into something an editor can complete and check. Run the server once before writing hooks so the file exists.
Backing it up
Locally, it is a directory:
# locally: stop the server, copy the directory
cp -r pb_data pb_data.backup-$(date +%F)The admin panel's Backups screen does the same thing properly, on demand or on a schedule, and can restore one. That is the one to use for an instance anyone depends on.
To take a copy of a deployed instance onto your machine, database, collections and files together:
voidbase export ./snapshot --url https://blog-api.example.workers.dev --admin you@example.com:your-passwordOn Cloudflare it is not used
A deployed instance has no filesystem. The database is Cloudflare's own SQL database and the uploaded files are in object storage, both created for the instance on its first deploy and both belonging to your account. The same code reaches them the same way, which is why a hook that works locally works deployed.
Do not commit pb_data/. It holds real data, and on a shared repository it holds someone else's. voidbase init ignores it for you.
Fix it yourself. The link below opens this file in GitHub's editor and forks the repository for you if you need one, and your change becomes a pull request without leaving the browser.