Caddy on the droplet now answers for both the sslip.io hostname and wizwar.kestrelsnest.social, fetching the latter's certificate automatically the moment DNS resolves. The domain's authoritative nameservers are Hover's, so the required A record must be added there; a matching record was also placed in the (currently inert) DigitalOcean zone for future-proofing. README updated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
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