Upgrades

A deploy is three steps:

git pull
scripts/pre-deploy.sh
docker compose up -d --build --wait

scripts/pre-deploy.sh snapshots the database to /data/backups/pre-deploy-<UTC>.db.gz and keeps the newest 3. --wait makes Compose wait until every service is healthy, so the command fails if the new version doesn't come up.

The app runs database migrations on start. The runtime waits for the app to be healthy and refuses to run on a schema it doesn't know.

Nothing is lost during a deployCopy Anchor Link

Both services restart on every deploy, so the channel sockets drop for a moment. Messages and reminders survive anyway:

• Durable inbox: every inbound message is written to the database before the channel handler returns. Messages that arrive while the runtime restarts are replayed when it comes back.
• Durable outbox: replies and reminders are rows that stay pending until the channel acknowledges them. A row stuck in sending for more than 5 minutes goes back to pending.
• SIGTERM drain: with stop_grace_period: 60s, the runtime stops taking new turns, finishes the current step and releases its outbox claims before it exits.
• Overdue reminders fire once on start, marked "(telat, harusnya 09.00)" (late, it was due at 09.00).
• Pending approvals are saved, so you can answer one after the restart.

Docs-only changes don't touch the image (the site isn't part of it), so they don't restart the containers.

Rolling backCopy Anchor Link

Go back to the previous version and run the same command:

git checkout <previous-commit>
docker compose up -d --build --wait

If the new version had already migrated the database, the old code finds a schema newer than itself. /health fails on purpose in that case, so a bad rollback shows as failed instead of half-working. To fix it, restore the pre-deploy snapshot taken just before the upgrade (see Restore), then start the old version again.