What is Runic Gateway?

Runic Gateway puts a private game server’s live state on a public website without ever exposing the game to the internet.

The shard dials out to a small sidecar over loopback; the sidecar is the only network-facing component, and only the website’s backend is allowed to talk to it. The website degrades gracefully when the game is down, and sensitive events never reach the public event stream.

What the platform is on today

Wire protocol	7
Module API	1.10.0
Current bundle	2026.09.10
uo-link sidecar	v2.2.0
Plugin overlay	v1.2.0
Installer	v0.1.1
ServUO (minimum)	57.4

Every value in that table is read from src/data/platform.json and re-checked against its source of truth on each build. None of it is typed into prose — including here.

An install is two installs

Worth stating before anything else, because it is a real trap: a Runic Gateway install is two independent deployments.

1. The site is a Docker deployment — the website, a database, and a game module.
2. The shard side is the installer binary, run on the game server’s host. It sets up the plugin overlay and the sidecar, and it never contacts the website.

They meet at four values pasted into the module’s shard screen, and at protocol 7, which both sides check before they will pair.

You can stop after the first one. A site with no game server attached is a complete community website — news, wiki, pages, Teams, forums, accounts, moderation and the event calendar are all core, and none of them knows a game exists. The second install is what fills the game screens, and what lets an event reach into a world.

Start here

The seven pages of Getting started are that sequence, in order, and each one says what you should expect to see before you move on:

1. Requirements — what you need on both hosts
2. Install the site — Docker Compose, pull-only
3. First run — the first admin, and maintenance → live
4. Install a game module — what makes the game screens exist
5. Connect a game server — the installer, on the shard host
6. Verify the whole stack — proving it works, rather than assuming

Then Administration covers running it: configuration, branding, content, users, authentication, Teams, scheduled events, moderation, notifications, modules, the shard connection, upgrades, and what to do when something is wrong.

Where the truth lives

The canonical, normative documents live in the docs repository and always win over anything written here. This site authors the journey — install, configure, administer, extend — which is the thing no existing document owns end to end, because the repositories are organised by component and an operator is not.