auto-deploy.sh only ever worked because someone chmod +x'd it directly
on the server after cloning, outside git - a fix that lived nowhere
git could see. A `git checkout --` to that file (recovering from an
unrelated direct edit) silently restored the tracked 644 mode,
breaking the deploy timer with "Permission denied" until caught via
journalctl. bootstrap-env.sh had the identical latent bug, just never
triggered since it's only ever run manually.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
nginx resolves the api/web service names to a container IP once, at
its own worker-process startup. docker compose up -d only recreates
containers whose image/config changed, so nginx keeps proxying to the
old, now-dead IP after a deploy rebuilds those containers - every
request 502s, which shows up in the browser as a misleading CORS
error since the bare 502 carries no Access-Control-Allow-Origin
header. Confirmed live: this caused a real multi-hour production
outage after the last two deploys.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
scripts/auto-deploy.sh + a systemd timer (2min interval) that fetches
origin/master and, if ahead, pulls/rebuilds/migrates/restarts - same
sequence as the manual update steps in DEPLOYMENT.md, just scheduled.
Polling instead of a Gitea webhook deliberately: no extra exposed
service, no Docker socket mounted into a container, no shared secret
to manage - it's the same trust boundary as a manual SSH deploy.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
sakshamandClaude Sonnet 5