A pipeline for a directory the binary serves

There is no Cloudflare in this one, so nothing external does the deploy. A push checks the directory, and moving it to your server is a step you own.

What CI can check

The useful check is that a fresh start works: the executable, an empty data directory and your migrations, with nothing carried over from your machine. A migration that only applies to your laptop's database is the failure this catches, and it is the common one.

# in the checkout, on any CI runner
VERSION=1.0.0
curl -sLO https://github.com/voidbase-cloud/voidbase/releases/download/v${VERSION}/voidbase_${VERSION}_linux_amd64.zip
unzip -q voidbase_${VERSION}_linux_amd64.zip && chmod +x voidbase

# the migrations apply to an empty database
./voidbase serve --dir /tmp/check &
sleep 3
curl -fsS http://127.0.0.1:8090/api/health

The archive is named voidbase_<version>_<os>_<arch>.zip, with darwin and windows beside linux, arm64 beside amd64, and a _musl suffix for Alpine. Pin the version rather than tracking the latest release, so a new voidbase does not change what a green build means, and let a check tell you when it is time to move it:

./voidbase update --check            # exits 1 when a newer release is out, 2 when it could not find out

The common pipeline page makes the same argument for the other shapes. The runner is yours to pick; the executable needs nothing installed beside it.

What goes to the server

The three tracked directories and an executable for the server's platform. Not your database, not your configuration values, and not the executable from your own machine unless the platforms match.

pb_data/
pb_secrets/secrets.json
voidbase

How it gets there is yours: rsync over ssh, a container image, a package. voidbase has no opinion and this page will not pretend to, because a transport we have not tested is worse than none. What matters is the order on the far side: put the new directory in place, then restart the service, so the server never reads half of one version and half of another.

Configuration on the far side

The values live on the server, never in the repository. pb_secrets declares which keys exist and who may read them, and the file holding the values is git-ignored. On the server that file is written once, by hand or by whatever holds your secrets.

./voidbase secrets                   # what is declared, and what has a value here

Run that on the server after a deploy and it prints what is declared and what is missing, which is the cheapest way to catch a key that was added in the repository and never given a value.

Backups are not the pipeline's job, but nothing else is doing them

The database is a file in pb_data/ on that one machine. Nothing in this shape replicates it, which is the cost of having no vendor in the loop. The scheduled backup from Settings > Backups writes an archive that is verified after it is written, and with VOIDBASE_BACKUP_S3_ENDPOINT, VOIDBASE_BACKUP_S3_BUCKET, VOIDBASE_BACKUP_S3_ACCESS_KEY_ID and VOIDBASE_BACKUP_S3_SECRET_ACCESS_KEY set, every archive is also copied to that bucket, off the box: another R2 account, Backblaze B2, AWS S3 or anything S3-compatible. A failed copy is reported and never fails the backup.

If that sentence is the one that changes your mind, a voidbase project puts the database on Cloudflare's D1 and the files in R2, and the pipeline becomes theirs to run.