Waters ChurchandClaude Opus 5
00c2ad15a7
Deploy web to NAS / deploy (push) Failing after 3s
Until now a server change reached the NAS only when someone ran ./release.sh --web from a machine on the church network. That made the deploy depend on which laptop was awake and where it was, which is the same fragility that let the nightly Drive backup go stale unnoticed. An act_runner now runs in Docker on the NAS itself and picks up this workflow, so a push to main rebuilds the container regardless of where the push came from. The workflow keeps the protections the old remote deploy script had, because they are the ones that matter: server/data and server/.env are excluded from the copy and then explicitly checked for afterwards, and the container is recreated with 'up -d --build' rather than 'down' first, so an interrupted deploy leaves the old container serving instead of tearing the stack down. rsync runs without --delete, matching the tarball deploy it replaces — a stale file is survivable, a wiped data/ is not. This covers the web app only. The iOS and Android apps bundle a copy of the UI at build time, so they still need ./release.sh and a store release; server-side changes reach them immediately, since they call this same server live. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>