Self-hosted community platform
Put your game server on the web without putting it on the internet.
Runic Gateway is a community website for a game server — accounts, teams, forums, a wiki, news and a full admin panel — with a one-way bridge that puts the server's live world on the public site. The game itself never listens on the internet.
How it works
One path, one direction
Everything the website knows about your game arrives the same way. There is no second route in, and nothing on the internet can reach the game to ask.
Today that game server is a ServUO shard and that sidecar is uo-link. The shape is the contract; the implementations are what plug into it.
Your game server
A plugin inside the server dials out to the sidecar over loopback. The game never listens for anything, so there is nothing on it to find. Events go onto a bounded queue and the game moves on — a sidecar that is wedged or missing cannot slow the world down.
The sidecar
A small service beside the game, and the only piece of the bridge anything else can reach. It speaks a versioned wire protocol — protocol 7 today — so a mismatched pair is refused rather than misread, and it answers only your website's backend, over an authenticated WebSocket and REST.
Runic Gateway
Your site ingests the live feed and fans it back out on two streams: a public one carrying an allowlist of safe events, and a staff-only one carrying the rest. That split is a security boundary, not a preference. When the game is down the site stays up and shows it as offline.
Browser and app
The web client reads same-origin JSON and server-sent events. The Android app talks to the same documented API with bearer tokens. Neither has any idea where the game server is, because neither is ever told.
What it looks like
The other end of that diagram
A demo deployment with a real shard behind it. The gold supply, the state of the link and the player online in Britain are all read from the game server over the bridge. None of it is typed in, and none of it is a mock-up.
Why self-hosted
Your server, your data, your rules
There is no hosted tier and no account with us. The whole thing is software you run, which is the only arrangement under which "the game is not on the internet" can mean anything.
It runs on your box
Docker Compose, with prebuilt images that are pulled rather than built — nothing compiles on your server. One command up, one command back.
The game stays off the internet
The game host opens no inbound port. The sidecar beside it is the only exposed part of the bridge, and it answers exactly one caller: your website.
Branding is data, not a rebuild
Name, colours, logo and contact address live in a mounted file. The same image runs as any community — including this site, which is built the same way.
No analytics, anywhere
This site has no trackers, no third-party requests and no cookie banner, because it collects nothing. Your deployment talks to the services you configure, and to nothing you did not.
Documented, not just working
The whole backend is described by an OpenAPI 3.0 spec that ships with it, so the API you build against is the API that is actually there.
Free software
GPL-3.0-or-later, every repository in the open. If this project stops, what you are running does not.
What it does
A community site, and a window into the game
The core is game-agnostic: it does not know what a shard is. Everything that does arrives as an installable module, which is why the same platform can carry a different game without a fork.
Community
The site your players actually use, none of which knows what game you run — though Teams arrive from the installed module rather than being created here.
- Teams
- Team forums
- Notifications
- Event calendar
- Wiki
- News and newsletter
- Player self-service
Game intelligence
Module-suppliedSupplied by the installed game module, not by the core site. Today that module is module-uo, and this is what it publishes from a live shard.
- Live server status
- Economy and activity
- Character sheets
- Points and loyalty boards
- Player-vendor marketplace
- Houses and IDOC decay
- Spawn atlas
- Champion boards
- Guilds
- City governors
Administration
Running the place, with a record of who did what.
- Roles and permissions
- Moderation and appeals
- Content reports
- Append-only audit log
- Bot scoring and IP bans
- Scheduled world events
- Module management
- The game-server connection
Integration
The seams that let other things reach in — and one game reach out.
- Modules
- The sidecar bridge
- Discord: slash commands, notifications, voice
- Mobile and push
- SSO over OAuth2 / OIDC
Infrastructure
How it runs, and who it answers to.
- Self-hosted, start to finish
- Docker, with prebuilt pull-only images
- Branding as data, not a rebuild
- OpenAPI 3.0 for the whole API
Some things people reasonably expect are deliberately not built — a Matrix integration, more than one game module active at once, a second game module. They are listed rather than left out, on features and integrations.
Getting started
An install is two installs
This trips up almost everyone once. The website and the game-side bridge are separate deployments on separate machines, and neither one installs the other. Doing them in order takes an evening.
1 The site
A Docker Compose deployment on whatever host serves your community — a small VPS is plenty. Pull the images, bring it up, create the first admin, then install a game module from the admin panel.
2 The game side
One binary, run on the machine the game server already lives on. It syncs the plugin, installs the sidecar as a service, and prints four values. You paste those into Admin → Shard, and the two halves find each other.