waving-hands/deploy/README.md

Deploying Waving Hands

The game runs entirely in the browser: the duel state lives in local storage and nothing is rendered or stored on a server. Production is therefore a single DigitalOcean droplet running only Caddy, which terminates TLS with automatic certificates and serves the static build from /opt/waving-hands/build. No Node, no service, no database.

Sizing

The smallest droplet is enough: s-1vcpu-512mb-10gb ($4 a month). The build is under half a megabyte and Caddy idles in about 30 MB of memory. Move up to s-1vcpu-1gb only if the site ever gains a server side.

The zero-cost alternative is a second site block in the wizwar droplet's Caddyfile pointing at a second directory; the deploy script works unchanged against that host. A separate droplet keeps the two games' uptime and upgrades independent.

Current production

• Droplet: waving-hands (nyc3, s-1vcpu-512mb-10gb, tag waving-hands), IP 159.203.98.71
• URLs: https://hands.kestrelsnest.social (A record at Hover, where kestrelsnest.social's DNS lives) and https://waving-hands.159.203.98.71.sslip.io (always works, zero DNS). Caddy serves both from the first line of /etc/caddy/Caddyfile.
• Everyday deploy: deploy/deploy.sh 159.203.98.71

New droplet from scratch

1. doctl compute droplet create waving-hands --region nyc3 \ --size s-1vcpu-512mb-10gb --image ubuntu-24-04-x64 \ --ssh-keys <your-key-ids> --tag-name waving-hands --wait
2. scp deploy/setup-droplet.sh root@<ip>:/root/ && ssh root@<ip> \ "bash /root/setup-droplet.sh 'hands.kestrelsnest.social, waving-hands.<ip>.sslip.io'" (point the A record at the new IP first, or leave the real name out until it is).
3. deploy/deploy.sh <ip>

The sslip.io hostname works with no DNS at all. To add a real name, point an A record at the droplet and add the name to the first line of /etc/caddy/Caddyfile (space separated), then systemctl reload caddy; Caddy fetches the certificate on first request.

Everyday deploys

deploy/deploy.sh <ip>

Runs the type-check, the tests and the build locally, rsyncs build/ to the droplet keeping the previous week's hashed assets, and reloads Caddy. A player mid-duel loses nothing: their game is in their own browser, and the next page load picks up the new build.

Operations

• Logs: ssh root@<ip> journalctl -u caddy -f, access log in /var/lib/caddy/access.log
• Nothing to back up on the server. Player duels are in their browsers.