← all epics

Server instance

repo: land-of-lor · depends on: server-architecture

Where this stands (2026-09-13)

The droplet has been live since 2026-08-02, behind HTTPS since 2026-08-04, and serving spellgrove.com since 2026-09-03. Decided (Q001, 2026-08-02): the credentials Kris supplies for provisioning, with its two scope gaps worked around. Reshaped by the 2026-09-13 security audit — two sandboxed service users, the DigitalOcean cloud firewall, daily database dumps, quiet-hours updates: ops/droplet/README.md is the box’s current shape, deliverable #4 the 2026-08 original. hello@spellgrove.com forwards to Kris through Namecheap; the box sends no mail yet. Open issues: epic:server-instance — #1 send-only mail from the box, for verification and password-reset emails from spellgrove.com. Past task files (to 2026-09-13): workshop/historic-docs/epics/server-instance/tasks/. The question file: workshop/historic-docs/epics/server-instance/questions/.

What this is

Getting an actual instance of the game server running somewhere reachable: hosting choice, deployment process, and environment separation (at minimum, a dev/staging environment distinct from whatever eventually serves real players).

Why it exists

server-architecture designs what the server is; this epic makes one exist and run. Given the December 2026 release target, there needs to be a real, iterable server environment well before launch — not just a local dev loop — so that client work (whichever engine is chosen) has something live to talk to.

Scope

• Hosting provider/platform choice — decided, see below.
• Deployment pipeline (how a change to the server code gets from commit to running instance) — a manual git pull + systemctl restart workflow exists (deliverable #4 §7); automating provisioning itself is this epic’s live task.
• Environment strategy (dev/staging/production, or some collapsed version of that appropriate to project size) — still genuinely a single environment; not revisited by this pass.
• Basic operability: logs, restarts, how Kris (or an agent) checks if it’s up — covered in deliverable #4 §9.

Decided (2026-08-02 architecture conversation, written up as deliverable #4)

Hosting is chosen: a single DigitalOcean droplet. Ubuntu 24.04 LTS, Sydney region (syd1 — nearest DO region to Brisbane), 2 GB RAM / 1 vCPU regular droplet. Godot 4 headless world-server processes and a director service run on it under systemd, Postgres alongside, Caddy in front for TLS and WebSocket reverse-proxying. The complete, exact-commands runbook is deliverables/004-server-setup-guide.md — that document is this epic’s hosting decision, not a separate summary of it.

What’s not yet decided: the director service’s own runtime (Go vs. Node/TS, leaning Node) — tracked as server-architecture’s one remaining open question, not this epic’s. This epic can provision the box and run everything deliverable #4 describes regardless of which way that lands.

Done: provisioned via the DigitalOcean API (2026-08-02)

Kris wanted the droplet stood up by an agent calling the DO API directly — not by hand — using deliverable #4 as the executable spec. server-instance/001 did exactly that: lor-game-server-01 (209.38.29.22, syd1, 2 GB/1 vCPU) is live, hardened, and running Postgres, Godot 4.7.1 headless, Caddy, and systemd-managed lor-director/lor-world@1 units, verified end-to-end with a real WebSocket connection through Caddy to the world instance. Full provisioning record, deviations from the guide as written, and follow-ups (DO project assignment, git deploy credentials on the box, TLS once a domain exists) are in server-instance/001’s dated note, written up for external reading as deliverables/005-server-instance-live-and-how-to-deploy.md.

DNS (2026-08-04)

The game server has a hostname: lor-server.cocreations.com.au → A 209.38.29.22 (TTL 200). It’s a dev/server hostname only — it deliberately does not preempt naming-and-brand’s still-open public-domain question (Q002).

The cocreations.com.au zone is not managed at the domain’s registrar — its nameservers are iFastNet’s (ns101/ns201.ifastnet.com), and the zone is edited in Kris’s byethost cPanel: drawonthe.net:2083 → Zone Editor → cocreations.com.au. Kris added this record by hand on 2026-08-04; any future record changes happen there.

This hostname is what lets Caddy hold a real Let’s Encrypt certificate, which the Godot web client requires (web exports refuse to run outside a Secure Context — the plain-HTTP-on-bare-IP /play/ link failed in a real browser for exactly this reason).

Firewall, users, email (2026-09-13)

The security audit before the store launch reshaped the box: two unprivileged service users (lorgame for the director and the Areas, lorweb for the Builder and the site build), every unit sandboxed, a DigitalOcean cloud firewall beside ufw (22, 80, 443 and nothing else), daily database dumps, quiet-hours updates with an automatic reboot. The current shape of the box, and the script that applies it, is ops/droplet/README.md in the game repo — read that before touching the droplet; deliverable #4 below is the 2026-08 original, kept for the record. hello@spellgrove.com forwards to Kris through Namecheap; the box itself sends no mail yet (the send-only mail server for verification and reset emails is a task of its own).

Non-goals

• Not the server’s internal architecture — that’s server-architecture.
• Not load/scale planning for a hypothetical large player base — appropriate scope here is “a small number of players can connect and it works,” matching the project’s current stage.
• Not the staged multiplayer PoC implementation itself (director code, the Godot world server, the client) — this epic is the box it all runs on, not the software that runs on it.

Relevant docs

• deliverables/004-server-setup-guide.md — the actual, executable hosting decision: exact commands for every layer (droplet, hardening, Godot headless, Postgres, Caddy, systemd, deploy, verification).
• deliverables/005-server-instance-live-and-how-to-deploy.md — the server as actually built: what’s running, how to deploy to it, day-to-day ops, and open follow-ups.
• server-architecture/overview.md — the architecture decisions this hosting setup serves; its one open question (director runtime) doesn’t block this epic.
• workshop/historic-docs/epics/server-instance/questions/001-droplet-provisioning-credentials.md — exactly what Kris needs to supply before server-instance/001 can run.

Deliverables (3)

• #28 — The security audit — the box, the code and the client hardened before launch (2026-09-13)
• #5 — lor-game-server-01 is live: server notes and how to deploy to it (2026-08-02)
• #4 — The server instance — a droplet setup guide (2026-08-02)

Work on this epic

The granular work is GitHub Issues, one label per epic: epic:server-instance (private repository — sign-in required). The dated Where this stands section above names the open ones. The task files that carried this epic until 2026-09-13 are kept in the repo: task files to 2026-09-13 .

Also available as raw markdown.