The hall comes first, in the shape of wizwar's landing

The home page is a centred card: title and pitch, your name, play the
bot or continue the duel under way, create or join a duel by code, a
sample ledger, the duels this browser holds with whose move it is, and
the story of the game. The single-player board lives at /play. The
droplet gains the duel server as a systemd service behind Caddy.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

deploy/README.md

@@ -1,16 +1,18 @@
 # 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.
+The single-player game runs entirely in the browser. Duels between people
+go through a small Node process that keeps each room as an append-only
+ledger of moves in /var/lib/waving-hands/rooms. Production is one
+DigitalOcean droplet: Caddy terminates TLS with automatic certificates,
+serves the static build from /opt/waving-hands/build, and proxies /api and
+/ws to the duel server on port 8788, which runs as the `waving-hands` user
+under systemd from /opt/waving-hands/app.
 
 ## 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 smallest droplet, `s-1vcpu-512mb-10gb` ($4 a month), carries both Caddy
+and the duel server comfortably: the server is one small Node process capped
+at 300 MB by its unit file, and a room is a few kilobytes of ledger.
 
 The zero-cost alternative is a second site block in an existing Caddy
 server's configuration pointing at a second directory; the deploy script
@@ -34,7 +36,8 @@ uptime and upgrades independent of anything else.
 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>`
+3. `scp deploy/setup-server.sh root@<ip>:/root/ && ssh root@<ip> "bash /root/setup-server.sh"`
+4. `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
@@ -45,13 +48,18 @@ fetches the certificate on first request.
 
     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.
+Runs the type-checks, the tests and the build locally, rsyncs `build/` to
+the droplet keeping the previous week's hashed assets, rsyncs the server and
+engine sources, installs dependencies, and restarts the duel server. A
+single-player game is in the player's own browser and loses nothing. A room
+is replayed from its ledger when the server comes back, which takes a few
+seconds; Caddy holds requests that land in the gap.
 
 ## 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.
+- Logs: `ssh root@<ip> journalctl -u waving-hands -f` for the duel server,
+  `journalctl -u caddy -f` and /var/lib/caddy/access.log for the web side.
+- Restart: `ssh root@<ip> systemctl restart waving-hands`
+- Rooms: `/var/lib/waving-hands/rooms/<CODE>.jsonl`, one ledger per duel.
+  Copy that directory to back them up; single-player games are in players'
+  browsers.