On-premises: backups and updates

What to back up on an on-premises Crunu server, how to copy the database without the repository, and how to move to a new bundle with the same data and keys.

Last updated October 30, 2026

On this page

An on-premises server keeps everything on your host: the database, the settings with the server key, and the key of the internal certificate authority. You back them up, and you update by carrying in the next bundle.

Available from Crunu 6.3.0. For backups in general, see Backups and restore.

Three things, kept apart

What	Where it is
the database	the Docker volume `crunu_data` (SQLite, `/data/crunu.db` in the server container), or `crunu_pgdata` (Postgres)
the settings with the server key	`deploy/.env` of the bundle
the key of the internal certificate authority (`--tls internal`)	the Docker volume `crunu_caddy_data`

Keep them in different places, as Backups and restore explains for the database and the server key. The database holds only ciphertext. Whoever has the certificate authority's key can issue certificates your machines accept for any name, so protect that volume like the server key.

The volume names start with crunu, the Compose project of the bundle. If you started the installer with COMPOSE_PROJECT_NAME, the volumes start with that name instead.

Copy the database without the repository

The export described in Backups and restore needs the Crunu repository, which the bundle doesn't carry. Without it, copy the SQLite database with the server stopped:

Shell

docker compose --env-file deploy/.env -f deploy/compose.yml stop server
mkdir -p backups
docker run --rm --user root -v crunu_data:/data:ro -v "$PWD/backups:/backup" \
  crunu-server:6.3.0 sh -c 'cp -a /data/. /backup/'
docker compose --env-file deploy/.env -f deploy/compose.yml start server

For Postgres, use the backup tools of Postgres. Copy deploy/.env into your password manager after every change, and back up the crunu_caddy_data volume the same way as the database.

Update to a new bundle

Check the new archive as in Install Crunu in your own network: its SHA-256 against the one you received.
Extract it next to the current one and run its installer with the settings of the current install:
Shell
```
tar -xf crunu-onprem-6.3.1-amd64.tar
sh crunu-onprem-6.3.1-amd64/install.sh --env-file crunu-onprem-6.3.0-amd64/deploy/.env
```
The installer copies the settings into the new directory and sets the image, the releases and the agent version of the new bundle. It loads the new images and starts the server with the same data and keys; the server updates its database itself. The root certificate stays the same: it lives in the volume, and the installer exports it into the new directory.
Update the agents: sudo crunu self-update and sudo systemctl restart crunu-agent on each machine, or dpkg for a .deb install. People reload the open tabs of the web app.

Keep the old directory until the new install runs well. After that, only its deploy/.env is worth keeping, as a copy.

The web app in the browser

The web app is cached in each browser as an installable app. After you update the server, a page that's already open shows “A new version of the web app is available.” with a Reload button. The cache holds the app only, never data or keys, and when the server is reachable the network decides what runs.

Check after every change

Shell

node server/tools.mjs doctor https://vault.kiteline.example

Run it in the directory of the current bundle. If the server uses the internal certificate authority, add the root first: NODE_EXTRA_CA_CERTS=deploy/crunu-root.crt node server/tools.mjs doctor …. The summary ends with a line such as Summary: OK — 12, warnings — 0, failures — 0, skipped — 5. See Monitoring and doctor for what each line checks.