DEPLOY.md covers standing the stack up from nothing and ends with a two-line
"Updating" section, which is the operation actually performed every time and
the one where the irreversible mistakes live. Redeploying has a required
order — back up before pulling, because a backup taken after a bad deploy is
a backup of the damage — and three traps that are invisible until they cost
data:
- The store runs in WAL mode, so copying bookmarks.db alone while the
container is up can silently drop the newest bookmarks. VACUUM INTO folds
the WAL in; the cold-copy fallback has to take the sidecar files.
- That backup needs the source volume mounted read-write, which looks wrong.
Opening a WAL database creates the -shm file, so :ro fails outright.
- A restored file lands root-owned while the container runs as uid 65532.
Reads succeed and writes do not, so the restore looks like it worked.
Backups go to ../mangabm-backups/, a sibling of the checkout rather than a
directory inside it, so no git operation or careless rm in the project dir
can take the backups along with it. Names carry a UTC timestamp so they sort
chronologically as plain text and cannot collide across a DST shift.
Also documents that a rebuild is mandatory for any UI change now that the
templates, CSS and fonts are //go:embed-ed, and ends at the phone smoke test:
no curl can tell you the panel works on the device.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
