Private
Public Access
ksmithandClaude Sonnet 5
7f579bb508
Deployment artifacts for the two-server architecture from ARCHITECTURE.md §9, grounded in verified Debian 13 (trixie) package facts (Python 3.13, PostgreSQL 17, Node.js 20, redis-server 8.0, certbot 4.0, ufw -- confirmed rather than guessed) rather than a generic "modern Linux" guide: deploy/systemd/chatapp.service, deploy/chatapp.env.example, deploy/backup-postgres.sh, deploy/upgrade.sh, and DEPLOYMENT.md as the actual numbered runbook. Revised mid-implementation once the user clarified the app sits behind an existing, separate Nginx Proxy Manager rather than local Nginx+certbot: dropped the local Nginx config entirely, gunicorn now binds a TCP port instead of a Unix socket, and app/main.py gained a static-file mount + SPA fallback route so gunicorn alone serves the built frontend, /api, and /ws on one port -- what lets NPM's simple one-upstream-per-domain mode work with zero custom path routing. Path-traversal-guarded (full_path comes straight from the URL) and cache-header-differentiated (far-future immutable on Vite's content-hashed assets, no-cache on index.html/sw.js/ manifest so a deploy actually propagates instead of leaving clients on a stale service worker) -- verified locally against a real gunicorn process serving a real frontend build, not just eyeballed. Two real gaps found and fixed alongside the docs, not just noted: gunicorn wasn't a dependency anywhere despite being the whole app-server design, and there was no WebSocket reconnect logic on the client -- a reverse proxy's idle-connection timeout (NPM's or otherwise) would have silently killed a quiet chat connection with nothing to recover it. Added exponential-backoff reconnect to useChatSocket.ts, verified by hand (killed and restarted the local dev backend mid-session, confirmed auto-reconnect and that a message sends successfully afterward with no page reload). Every command in DEPLOYMENT.md that could be verified locally, was: the exact systemd ExecStart line run against local dev Postgres/Redis with clean SIGTERM shutdown, the static-file serving behavior against a real build, both shell scripts syntax-checked. What couldn't be verified from this sandbox (actual Debian 13 hardware, Nginx Proxy Manager itself) is flagged explicitly in the plan rather than claimed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
49 lines
1.9 KiB
Bash
Executable File
49 lines
1.9 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Nightly Postgres backup for the KeepItTalking data server.
|
|
#
|
|
# Install (as root, on the data server):
|
|
# sudo cp deploy/backup-postgres.sh /usr/local/bin/chatapp-backup-postgres.sh
|
|
# sudo chmod 0700 /usr/local/bin/chatapp-backup-postgres.sh
|
|
# sudo crontab -e
|
|
# # add:
|
|
# 0 3 * * * /usr/local/bin/chatapp-backup-postgres.sh
|
|
#
|
|
# See ../DEPLOYMENT.md for the full data-server setup this fits into.
|
|
|
|
set -euo pipefail
|
|
|
|
DB_NAME="chatapp"
|
|
DB_USER="chatapp"
|
|
BACKUP_DIR="/var/backups/chatapp"
|
|
RETENTION_DAYS=14
|
|
TIMESTAMP="$(date +%F-%H%M%S)"
|
|
DEST="${BACKUP_DIR}/chatapp-${TIMESTAMP}.sql.gz"
|
|
|
|
mkdir -p "$BACKUP_DIR"
|
|
|
|
# Runs as the postgres OS user (peer auth) so no password handling here --
|
|
# see DEPLOYMENT.md for why the crontab entry above is on root's crontab
|
|
# calling `sudo -u postgres` implicitly via pg_dump's own permission model.
|
|
sudo -u postgres pg_dump --format=plain --no-owner --dbname="$DB_NAME" \
|
|
| gzip > "$DEST"
|
|
|
|
echo "Backed up ${DB_NAME} to ${DEST}"
|
|
|
|
# Local rotation -- keep RETENTION_DAYS days on this box regardless of
|
|
# whether off-box shipping (below) is configured yet.
|
|
find "$BACKUP_DIR" -name 'chatapp-*.sql.gz' -mtime "+${RETENTION_DAYS}" -delete
|
|
|
|
# --- Off-box shipping -------------------------------------------------
|
|
# Not configured yet -- destination wasn't decided as of this script being
|
|
# written. Uncomment and fill in ONE of these once you have somewhere to
|
|
# send it; a local-only backup doesn't survive losing this machine.
|
|
#
|
|
# rsync (to a second host reachable by the data server, e.g. over the same
|
|
# private network / a WireGuard tunnel used for anything else):
|
|
# rsync -a "$DEST" backup-user@backup-host:/path/to/chatapp-backups/
|
|
#
|
|
# S3-compatible object storage (needs `aws configure` or rclone set up
|
|
# separately first):
|
|
# aws s3 cp "$DEST" s3://your-bucket/chatapp-backups/
|
|
# # or: rclone copy "$DEST" remote:chatapp-backups/
|