Way back

Goes back to the previous images after an upgrade. Placeholders are as in Install.

Verified on dev on 2026-10-05, right after the upgrade upgrade.md describes: the schema diff and its reading below, then “Previous images”, steps 1 to 3 as written here. The older images ran on the newer database: sign-in, Settings and the data, including what was changed after the upgrade, all worked. The restore of step 4 was run as Backup and restore describes.

Is the database safe for the older images?

Database changes only go forward. The code has no down migrations and no schema version; each image applies its own schema lists when it opens the database (Upgrade). So what the older images do with the newer database depends on what changed between the two commits.

1. Compare the schema code of the two commits (the image tags are the commits):

   git -C <checkout> diff <previous commit> <new commit> -- src/db/schema.ts src/db/chat-schema.ts src/db/entities.ts src/db/chat-entities.ts src/worker/chats.ts

2. Read the result as follows.

   Safe to run the older images on the newer database:

   • New tables or indexes. The older code doesn’t use them, and its own CREATE … IF NOT EXISTS leaves them alone.
   • New columns that have a default or allow NULL. Every column in ADDED_COLUMNS and CHAT_ADDED_COLUMNS today is one of those. The older code doesn’t read them, and rows it writes get the default.

   Not safe:

   • A column added to DROPPED_COLUMNS. The newer image dropped it with its data. When the older code still lists it in its own ADDED_COLUMNS, the older worker adds it back, empty (NULL or its default), as it opens the database: the older code then runs, without the values the column held. That is safe only when the older code copes with the column empty; read what the older code says of the column. On dev, a column the older worker fills again at its start came back this way, and the older images worked.
   • A table added to DROPPED, or data moved to another place. Older code that reads the old place finds nothing there.
   • A column that changed meaning or format, or any other change you can’t place in the safe list.

3. If the change is safe, go back to the previous images (below) and keep the data.

4. If it is not safe, do steps 1 and 2 below, then restore the backup set taken before the upgrade as Backup and restore says. Its last step starts the previous images. Everything written since that backup is lost: chats, operations, settings.

Previous images

1. Point :latest back at the previous release in the registry (from the build machine, not the host): for each of projectstart, projectstart-worker and projectstart-controller, tag <registry>/<name>:<previous YYYY.MM.DD-HHMM> as <registry>/<name>:latest and push it.

2. On the host, as for any deploy (Upgrade):

   docker compose -f /opt/ProjectStart/deploy/compose.yaml pull
   docker compose -f /opt/ProjectStart/deploy/compose.yaml up -d