Rakazo backup before upgrading, and how to roll back

Rakazo is still in beta, and upgrades can change config formats. So the order is always: back up first, upgrade second, roll back if the checks fail. This procedure was run end-to-end on a real server: the whole database was dropped and restored, and the account, memory, and sandbox files all came back, in about two minutes.

Step 1: Take two backups before upgrading

Database backup (same command as step 4 of the install guide):

docker exec rakazo-postgres-1 sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB"' | gzip > backup-with-bot.sql.gz

In our test: an empty-database backup was about 40 KB, a backup with one bot about 54 KB, and the dump took under 5 seconds. Confirm the file exists and is not zero bytes before you upgrade.

Also save .env separately: a database backup does not contain the ENCRYPTION_KEY in .env, and that key cannot be recovered if lost. Copy .env to your password manager or an offline location, and never send it to anyone.

Step 2: Upgrade

Re-run the official installer (only the script from the official elie222/rakazo repository, no third-party variants). Do not stop at "the login page loads" — run the smoke tests in step 3.

Step 3: Smoke tests (after upgrade, and again after any rollback)

  1. The owner account logs in normally;
  2. The bot answers something it previously remembered (in our test, the code word BANANA-42: after rollback, asking What was my code word? got the right answer, which is what proves memory really came back);
  3. The bot does one small computer task (for example, listing files or creating a test file), proving tool use and the sandbox work;
  4. The public https address loads normally.

If any check fails, roll back — do not keep patching a broken state.

Step 4: Roll back (the tested order)

  1. Stop web / api / worker / supervisor and the bot computer services;
  2. Recreate the database with dropdb / createdb;
  3. Restore the pre-upgrade backup into the database;
  4. Re-run the official installer and restart the services;
  5. Repeat the step 3 smoke tests.

Our rollback result: the account count was back to 1, the code word was still in the restored database, the sandbox test file was intact, and both local and public https access returned normally.

The easy trap: a database backup is not a sandbox-file backup

In our test, the bot's test file survived because it lives in a separate appdata volume, and rollback did not delete that volume. A database backup restores accounts, conversations, and memory — not sandbox files. So on rollback: recreate only the database, do not delete data volumes. If you are migrating to another machine, back up the appdata volume separately.

Do not drop the database, delete volumes, or reinstall before backing up: deleted volumes cannot be recovered, and without .env, encrypted data may be unreadable after a reinstall.

Update (25 October 2026): a true cross-version upgrade is now verified

When new official builds landed on 25 October 2026, we ran the real thing on the same server: a full backup first (55 KB, 84 tables, taken with the procedure on this page), then pulled the new images and rebuilt the services. It passed in one go — account, bot and message counts were identical before and after, public access stayed up, and the bot still remembered the code word it had learned before the upgrade. The backup → upgrade → smoke-test flow above has now survived a genuine version jump; individual beta releases can still bite, which is exactly why the backup step is not optional.

Prefer to skip this procedure: our deployment service includes pre-upgrade backups and smoke tests, and uses the same rollback flow if an upgrade fails.

Based on the real-server test of 24 October 2026. The project moves fast — if commands or UI differ, the official docs win.