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.

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. An archive is verified after it is written,VOIDBASE_BACKUP_KEEP says how many scheduled ones to keep, and VOIDBASE_BACKUP_S3_* copies each one to a bucket outside the account. voidbase update --backup zips the directory before the executable replaces itself. A restore reads the archive as one stream and loads it in batches, so an archive larger than the instance's memory still goes back in.

To bring a deployed instance's data onto your machine, or send yours up, migrate takes a backup on one side and restores it on the other; the target becomes the source:

voidbase migrate https://blog-api.example.workers.dev http://127.0.0.1:8090 \
  --from-email you@example.com --from-password ... --to-email you@example.com --to-password ...

For a copy on disk rather than a running target, export writes the database, the collections and the files into a directory, reading only through the API:

voidbase export ./snapshot --url https://blog-api.example.workers.dev --admin you@example.com:your-password

On Cloudflare it is not used

A deployed instance has no filesystem. The database is a D1 database, or with --database durable a SQLite-backed Durable Object of its own, the uploaded files are in an R2 bucket, and the backups are in that bucket under __backups__/, all created for the instance on its first deploy and all belonging to your account. The same code reaches them the same way, which is why a hook that works locally works deployed.