Eric WagonerandClaude Fable 5
f0a264147f
The server code learns to distrust strangers: a 64KB WebSocket payload cap (the ws default is 100MB — an easy OOM on a 1GB droplet), a per-connection token-bucket rate limit, caps on concurrent sockets, total rooms, rooms per connection, pending transfer codes, and seats per myGames query. Player names are stripped of control characters and bounded at 24 chars, room codes at 8, serialized commands at 16KB before they touch the append-only log. Catch-up replays — a full game rebuild per request — get a 3-second cooldown. Unexpected exceptions now log server-side and send strangers a bare "internal error" instead of the exception text. One real bug found by the sweep: myGames compared the client's raw seat token against the stored hash, so the lobby ledger silently matched nothing since tokens were hashed at rest — and the comparison wasn't timing-safe either. It now goes through the same timingSafeEqual path as every other seat check, via a new exported seatTokenValid. The droplet tightens too: the game server binds loopback (HOST env) so port 8787 no longer answers the internet — it was reachable directly, plaintext, bypassing Caddy — and ufw now allows only ssh, 80, and 443. The systemd unit gains a sandbox (ProtectSystem=strict, ProtectHome, NoNewPrivileges, PrivateTmp, MemoryMax=700M so a runaway process is killed and restarted before it takes the box down) and execs tsx directly instead of through npx. Caddy adds HSTS, nosniff, frame-denial, and no-referrer headers; setup-droplet.sh records all of it for future rebuilds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Deploying Wiz-War
The game runs on a single DigitalOcean droplet: one Node process serves the built client and the websocket on port 8787; Caddy in front terminates TLS with automatic certificates. Room files persist in /var/lib/wizwar/rooms and survive deploys and reboots.
Current production
- Droplet:
wizwar(nyc3, s-1vcpu-1gb, tagwizwar), IP 104.236.96.198 - URLs: https://wizwar.kestrelsnest.social (once the Hover A record lands) and https://wizwar.104.236.96.198.sslip.io (always works, zero DNS). Caddy serves both; NOTE: kestrelsnest.social's authoritative DNS is at HOVER (ns1/ns2.hover.com), not DigitalOcean — records must be added there. A matching record also sits in the DO zone in case nameservers ever move.
Everyday deploys
deploy/deploy.sh 104.236.96.198
Builds the client locally, rsyncs the repo (minus node_modules, /data, .git, research), installs dependencies on the droplet, and restarts the service. Games in progress survive: state lives in room files, and clients reconnect automatically.
New droplet from scratch
doctl compute droplet create wizwar --region nyc3 --size s-1vcpu-1gb \ --image ubuntu-24-04-x64 --ssh-keys <your-key-ids> --tag-name wizwar --waitscp deploy/setup-droplet.sh root@<ip>:/root/ && ssh root@<ip> \ "bash /root/setup-droplet.sh wizwar.<ip>.sslip.io"deploy/deploy.sh <ip>
Operations
- Logs:
ssh root@<ip> journalctl -u wizwar -f - Restart:
ssh root@<ip> systemctl restart wizwar - Backup games:
scp -r root@<ip>:/var/lib/wizwar/rooms ./rooms-backup