Runic Gateway

Search

What you get

Everything the platform does

Grouped the way the software is actually divided, because that division is the thing most worth understanding before you install it: the core site is game-agnostic and does not know what a shard is, and everything that does arrives as an installable module.

Today there is one module and it covers Ultima Online, so the second group below is what a UO deployment gets. On a deployment with no module, that group is simply absent and the other four are unchanged.

Community

Core

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

    Needs a module

    A roster, a leader, a private forum, its own notification streams and a Discord voice channel, all hanging off one group. Core owns every part of that machinery and deliberately cannot create a Team: they arrive from the installed module, which is how a guild inside the game becomes a Team on the site — and why a different game can call them something else without core learning a new word.

    See it running

  • Team forums

    Needs a module

    Announcements, discussion threads and replies, with an edit window, post moderation, and abuse reports a member can raise without going through staff first. Forums are an admin switch for the whole deployment, and image uploads stay off until someone deliberately turns them on.

  • Notifications

    On the site, by push and by email, chosen per notification by each person rather than per person by you. The on-site inbox arrives by default and can be switched off; push and email only ever arrive if they were asked for.

  • Event calendar

    What is scheduled, what is happening now, what finished recently, and the results afterwards — with arcs, so a three-part story reads as one thing rather than three unrelated entries. A run that was cancelled says so instead of quietly vanishing. Core owns the whole calendar and can run an event on its own; what an event may do inside a game world comes from the installed module.

    See it running

  • Wiki

    For the things that outlive a news post — rules, guides, the lore nobody wants to retype in chat. Written in the admin panel, published on the public site.

    See it running

  • News and newsletter

    Four kinds of post — news, five-on-friday, newsletter issues and screenshots — plus CMS pages and a page builder for everything that is not a post at all.

    See it running

  • Player self-service

    An account area every signed-in person gets, whatever their role: their profile, their linked game accounts, their own characters, their devices and sessions. Staff are players too, so it is the same area for everyone.

The news page, listing posts with their category, date, headline and summary.
News, five-on-friday and the newsletter are one posting system with three categories — and none of it knows what game you run.

Game intelligence

From the installed module

Supplied 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

    Whether the server is up, who is on it, and how long ago the site last heard from it. When the game is down this page is the thing that says so — the site does not go down with it.

    See it running

  • Economy and activity

    A live feed of what is happening in the world, and the economy underneath it. Every event passes an allowlist before it can reach a public page; staff read a second stream carrying the rest.

    See it running

  • Character sheets

    Skills, stats and equipment, drawn from the live world rather than from a form somebody filled in. Reachable by the account the character is linked to, and by staff — not by the public.

  • Points and loyalty boards

    The leaderboards the game already keeps, published without anyone exporting a spreadsheet on a Sunday.

    See it running

  • Player-vendor marketplace

    Every player vendor on the server and what is on it, searchable without logging in to the game. Item names arrive from the world as numeric ids and are resolved against the game's own string table, so they read as names rather than numbers.

    See it running

  • Houses and IDOC decay

    Who owns what and where it stands, including which houses are decaying — published while it is still information rather than after it has become a rumour.

    See it running

  • Spawn atlas

    A bestiary and spawn map built by reading your shard's own spawn tables, so it describes your server rather than someone else's idea of the game. Regions, landmarks and champion altars come with it.

    See it running

  • Champion boards

    Which altars are running, how far along they are, and what turned up.

    See it running

  • Guilds

    Guild rosters and standings, kept in step with the game. This is also what fills the Teams primitive above: a guild in the world becomes a Team on the site, with the forum, the notifications and the voice channel that core attaches to one.

    See it running

  • City governors

    Who holds which city, and what they did with it.

    See it running
The marketplace page, listing items for sale by player vendors with their prices, shop names and locations, above a search box and price filters.
Player vendors, searchable from the website — the same index the in-game vendor search reads, honouring the same per-vendor opt-out.
The spawn atlas, listing creatures with how many of them spawn and on which facets, above a search box and facet filters.
The spawn atlas is parsed from the shard's own spawn files, so it stays accurate whether or not the server is up.
The guilds page, listing each guild on the shard with its abbreviation, how many members are online, and its leader.
Guilds arrive from the shard, not from a form — and a Team on the website is one of them, with its own forum and roster.
The houses page, listing homes that have entered their final decay stage with their owner and location.
Houses in danger, from the same decay data the game uses — a live process, not a nightly export.

Administration

Core

Running the place, with a record of who did what.

  • Roles and permissions

    Admin, moderator and player. Admin access is re-checked against the database on every request rather than trusted from whatever the session was issued with, so demoting someone takes effect on their next click and not at their next login.

  • Moderation and appeals

    Decisions carry a written reason, and the person on the receiving end has a documented way to answer rather than a direct message to whoever is awake.

  • Content reports

    Anything a member writes can be reported by another member, into a staff queue with the context attached.

  • Append-only audit log

    Staff actions are recorded, and nothing in the panel can edit or delete the record afterwards. That is worth having on the day you need to prove what did not happen.

  • Bot scoring and IP bans

    Login attempts are scored on behaviour rather than on a puzzle a real person has to solve, and a bad enough score bans the address by itself. The panel is a read view with an emergency unban, deliberately — it is not somewhere to tune a threshold at three in the morning.

  • Scheduled world events

    Author an event as phases and steps, publish a version, put it on the calendar and let it run unattended — with a dry run first that prices the whole plan against this deployment’s caps. Every action arrives switched off, every run has a per-run budget enforced in the database rather than in a role check, and everything an event creates or borrows is written to a ledger so the undo is generated rather than authored. Pause, resume, skip a step or cancel with cleanup, all logged with the person who did it.

  • Module management

    Install, disable, uninstall and purge a module from the panel. Uninstalling keeps the data and reinstalling picks it up where it was; deleting it is a separate, opt-in choice.

  • The game-server connection

    The bridge's address, token and protocol version live in the panel rather than in an environment file, so connecting a server is not a redeploy. The token is encrypted at rest and write-only in the API — it is never returned to any client, including yours.

The administration dashboard, showing the site mode, counts of posts, wiki pages and users, and a feed of recent administrative activity.
The dashboard on first sign-in: site mode, what the site holds, and who has done what.
The users screen, listing accounts with their role and status and the controls to change them.
Users and roles. A change of role takes effect on the next request, not the next login.

Integration

Core

The seams that let other things reach in — and one game reach out.

  • Modules

    The whole game-specific half of a deployment is an installable module: routes, screens, tables and nav rows, versioned against a declared core API. Installing one is a paste in the admin panel or a line in your environment, never a build.

  • The sidecar bridge

    A small service beside the game server, speaking a versioned wire protocol to the site and a loopback socket to the game. It is the only part of the bridge anything can reach over a network, and the game never listens at all.

  • Discord: slash commands, notifications, voice

    A bot for the guild you already have. Commands answer from your site, notifications bridge into channels, and a Team can be granted a voice channel that maintains its own membership.

  • Mobile and push

    A native Android app against the same documented API the website uses, with push delivered through your own ntfy server rather than a vendor in the middle.

  • SSO over OAuth2 / OIDC

    Google, Discord, or any OIDC provider you run. Link-only by policy: an external identity has to be attached to an account that already exists, and signing in with one never creates a user.

The modules screen, showing the Ultima Online module running with the routes it mounts, and the list of hosts modules may be installed from.
A module is installed from a release URL and runs inside the server, so only listed hosts are allowed to serve one.

Infrastructure

Core

How it runs, and who it answers to.

  • Self-hosted, start to finish

    There is no hosted tier and no account with us. Every part of this runs on hardware you control, which is the only arrangement under which the rest of the claims on this page mean anything.

  • Docker, with prebuilt pull-only images

    Compose up, compose down. Images are pulled rather than built, so nothing compiles on your server and an upgrade is a pull and a restart.

  • Branding as data, not a rebuild

    Name, colours, logo and contact address are a mounted file. The same image runs as any community — including this site, which is built the same way.

  • OpenAPI 3.0 for the whole API

    The spec ships with the server and an installed module merges its own routes into it, so the API you build against is the API that is actually running.

Not built

Things a reader could reasonably expect, that are not here

Every one of these is a decision rather than a backlog item, so each says why. Where the reasoning was written down in the open, it is linked.

  • More than one game module at a time

    One active module per deployment. The database columns that would scope data to a module exist and are populated, so the door is not nailed shut, but nothing exercises them and no interface offers it. A community running two games runs two deployments.

    What would change itSomeone needing it. The schema was shaped to keep it possible, which is a different thing from planning it.

  • A macOS or Windows-on-ARM installer

    Linux and Windows, on x86-64, plus Linux on arm64. The missing builds are missing on purpose: the installer runs on the machine the game server lives on, because the game and the bridge have to share a host, and no game server anybody runs is on either of those platforms.

    What would change itA game server that runs there.

    The operator guide

  • A public demo you can click through

    Planned and out of scope today: a virtual machine running the whole stack including a game server, with settings locked down and an hourly reset. Until it exists this site does not link to one, and there is no screenshot here of something that is not running somewhere.

    What would change itThe machine being stood up. The site is already built to gain it by way of one line in a configuration file, rather than a rebuild.