The whole server is one data directory. Back that up and you’ve backed up everything; restore it and the server is whole again.
The data directory holds users, tokens, channels, groups, invites, the license, the signing key, and — for Cargo channels — the builds themselves. Back it up and you’ve captured the server. For Tide channels, the build chunks live in your object storage bucket, so include that in your backup plan (or rely on the bucket provider’s own durability and versioning).
nightshipd backup pushes the data directory to a bucket you own
as an encrypted snapshot. Every file is chunked,
compressed and sealed on the server before it leaves (XChaCha20-Poly1305);
the bucket never sees plaintext, not even the chunk names. Snapshots share
unchanged chunks, so a daily backup costs only what changed. Backups are
opt-in: nothing is written anywhere until you set them up.
As an admin, open Admin → Storage and click Set up
backups…. You choose between the same bucket Tide already
uses (snapshots go under a backups/ prefix, no second credential
to manage — the server’s storage key must be allowed to write)
and a separate bucket with its own credential. The server generates
the encryption key and shows it once.
nightship backup init --shared # same bucket, under backups/
nightship backup init --endpoint https://<account>.r2.cloudflarestorage.com \
--region auto --bucket my-nightship-backups --access-key <KEY> --secret-key <SECRET>
nightship backup forget # stop backing up (snapshots stay in the bucket)
Store the printed key in your password manager. Every snapshot is encrypted with it; without it a backup cannot be restored — not by you, not by us. On Nightship Cloud this is the whole setup: we run the daily backup and, should you ever need it, the restore — but only with the key you kept.
The same, offline. The key is written outside the data directory and shown a single time:
nightshipd backup init --data-dir /var/lib/nightship \
--endpoint https://<account>.r2.cloudflarestorage.com --region auto \
--bucket my-nightship-backups --access-key <KEY> --secret-key <SECRET>
Then, whenever you like (the server can keep running):
nightshipd backup --data-dir /var/lib/nightship
nightshipd backup list --data-dir /var/lib/nightship
nightshipd backup prune --keep 14 --data-dir /var/lib/nightship
In Docker, prefix with docker compose exec nightshipd; the
Drydock demo configures this for you against
its local Garage.
On a fresh machine, restore a snapshot into an empty data directory with the key and the bucket details, then start the server on it. Tokens, channels, license and storage credentials return exactly as they were.
nightshipd restore snap-20260904-133448 --data-dir /var/lib/nightship \
--key /root/nightshipd-backup.key \
--endpoint https://<account>.r2.cloudflarestorage.com --region auto \
--bucket my-nightship-backups --access-key <KEY> --secret-key <SECRET>
If the backups live in the shared build bucket, add --prefix backups/
and use the build-storage bucket and its credentials. (On the old machine
--from backup.json works too; it carries the prefix.) The
restored backup.json still names the key file’s old
path — check it before the next backup.
A file copy of the data directory is equally valid:
nightship-data)./var/lib/nightship.--data-dir folder.Keep such copies owner-only — unlike the encrypted snapshots they contain the license, the signing key and the bucket credentials in the clear.
The server has a built-in schedule. Set it once and it backs itself up every day at that time (server local) and keeps the newest N snapshots — from the client (Admin → Storage), from the CLI, or on the box:
nightship backup schedule 03:00 --keep 14 # via the API (admin)
nightshipd backup schedule 03:00 --keep 14 --data-dir /var/lib/nightship
Admin → Storage also shows the last result and every snapshot,
and has a Back up now button; nightship backup and
nightship backups do the same from a terminal. keep
applies after every run, manual ones included, so the bucket stays bounded.
One bucket per server: pruning goes by snapshot name, so two servers
sharing a backup bucket would prune each other’s snapshots.
Prefer your own scheduler? A cron line works too:
0 3 * * * nightshipd backup --data-dir /var/lib/nightship \
&& nightshipd backup prune --keep 14 --data-dir /var/lib/nightship
Where you can, use a separate credential for backups so the key your CI
holds for pushing builds can’t touch them (with the same-bucket
setup, restrict the CI key from the backups/ prefix if your
provider supports prefix policies). Where your provider
supports it, add object versioning or a deny-delete policy on the backup
bucket: a credential that can write can usually also delete, and that is the
one thing encryption doesn’t protect against. See
Security and hardening.