5.2 KiB
5.2 KiB
title, description, source, reviewed
| title | description | source | reviewed |
|---|---|---|---|
| ⬆️ Install, upgrade, backup | Bring-up, status, logs, the pinned-image upgrade procedure, and the postgres backup and restore commands for the Coder stack in /home/loca/dev/coder. | verified deployment on the loca operator host, 2026-08-19 | 2026-08-19 |
⬆️ Install, upgrade, backup
🔑 Ground rules
- every docker command needs
sudo -n; userlocais not in thedockergroup, which is intentional because docker group membership grants root-level privileges on the host - always run compose from the project root so the project name,
.envand volume scoping resolve:cd /home/loca/dev/coder .envholdsCODER_PG_PASSWORDat mode 600 and is git-ignored; never echo it, copy it into a template, or paste it into a ticket- the deployed version is pinned twice on purpose: the image tag in
docker-compose.ymland the plain-text pin inconfig/runtime-version.txt(currentlyv2.35.3). Both change together or neither changes
🚀 Bring-up
cd /home/loca/dev/coder
sudo -n docker compose up -d
sudo -n docker compose ps
curl -sf http://127.0.0.1:52226/healthz
databasestarts first andcoderwaits on its healthcheck (pg_isready -U coder -d coder), so a cold start can take a few seconds before/healthzanswers- expected steady state: container
coderrunning, containercoder-databaserunning and healthy, one published socket127.0.0.1:52226 - full proof sequence: operations/verification
📋 Status, logs, stop
cd /home/loca/dev/coder
sudo -n docker compose ps # both containers, database health
sudo -n docker compose logs -f coder # server log stream
sudo -n docker compose logs --tail 200 database
sudo -n docker compose restart coder # server only, database untouched
sudo -n docker compose stop # keep containers, stop processes
sudo -n docker compose down # remove containers, keep named volumes
downnever removescoder_pgdataorcoder_home; only an explicitdown -vwould, and that destroys every user, template and workspace record- restarting
coderalone is safe and is the normal way to pick up an environment change indocker-compose.yml
⬆️ Upgrade the pinned image
Upstream states plainly that Coder does not support rollbacks, so the database snapshot is step one, not an optional extra.
cd /home/loca/dev/coder
# 1. snapshot the database first
sudo -n docker compose exec -T database pg_dump -U coder coder | gzip > /home/loca/dev/coder/backup-$(date +%F).sql.gz
# 2. edit the tag in docker-compose.yml, for example ghcr.io/coder/coder:v2.36.0
# and write the same value into config/runtime-version.txt
# 3. pull and recreate only the server
sudo -n docker compose pull coder
sudo -n docker compose up -d coder
# 4. verify the running build matches the new pin
curl -sf http://127.0.0.1:52226/api/v2/buildinfo
curl -sf http://127.0.0.1:52226/healthz
curl -sSI https://code.loca.zone/
- upstream's docker-compose upgrade path is exactly
pullthenup -dfor thecoderservice; the database service is left alone unless the postgres major version itself is being changed buildinfois the authority on what is actually running: it reports the semantic version plus commit, the advertiseddashboard_url, and whether telemetry is enabled- if
buildinfostill shows the old version, the tag edit did not land orpullfetched a cached digest; re-checkdocker-compose.ymlbefore restarting anything else - a postgres major-version bump is a separate operation: dump with the old image,
down, change the image, bring up a fresh volume, restore the dump
💾 Backup and restore
# backup
cd /home/loca/dev/coder && sudo -n docker compose exec -T database pg_dump -U coder coder | gzip > /home/loca/dev/coder/backup-$(date +%F).sql.gz
# restore
gunzip -c /home/loca/dev/coder/backup-2026-08-19.sql.gz | sudo -n docker compose exec -T database psql -U coder -d coder
-Tis required; without it compose allocates a TTY and the dump stream is corrupted by terminal translation- the dump carries everything Coder persists: users, templates, template versions, workspace records and Terraform state
- restore into a running database that is otherwise idle; stop the
coderservice first withsudo -n docker compose stop coderso no writes race the restore, then start it again - keep at least the snapshot taken immediately before the last upgrade; store it outside the repo tree if it must be retained long-term
🔁 If an upgrade goes wrong
- there is no supported downgrade path, so recovery is:
sudo -n docker compose stop coder, restore the pre-upgrade dump, set the old tag back indocker-compose.ymlandconfig/runtime-version.txt, thensudo -n docker compose up -d coder - verify with
buildinfothat the old version is live before letting any workspace agent reconnect - if only the proxy is broken, nothing about the image needs touching:
sudo -n nginx -tand the debug order in operations/index cover that case