Server instance

ops done

repo: land-of-lor · depends on: server-architecture · updated 2026-08-04

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).

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.
server-instance/questions/001-droplet-provisioning-credentials.md — exactly what Kris needs to supply before server-instance/001 can run.

Status

1 done

Next: Droplet live and now behind HTTPS at lor-server.cocreations.com.au (Let's Encrypt via Caddy, wss for director and game channels, verified 9/9 externally). Remaining follow-up cleanup — DO project assignment, git deploy credentials on the box — none of it blocking.

Deliverables (2)

#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)

Tasks (1)

done (1)

server-instance/001 — Provision the droplet via the DigitalOcean API and run deliverable #4's setup (priority 1, estimate M )

Answered questions (1)

server-instance/Q001 — Credentials and confirmation needed before automated droplet provisioning

Ask an agent about this epic

Also available as raw markdown.