docs/rust-link/INTEGRATION.md

rust-link — standing the bridge up

Operator- and developer-facing. How to get a Rust server, a sidecar and a website talking, and how to tell which of the three is wrong when they are not. The contract itself is PROTOCOL.md.

There is no installer support for Rust yet — that is a later phase — so everything here is done by hand. When the installer gains --game rust, this page becomes the fallback path rather than the only one.

---

1. What you need

Piece	Where it comes from
A Rust dedicated server with Oxide	umod.org
RunicGateway.cs	Rust-Plugins, overlay/oxide/plugins/
rust-link-sidecar	Rust-Link
A Runic Gateway website with module-rust installed	Module-Rust

One game server, one sidecar, on that server's own host. Six servers means six of the first two pairs and six rows in the website's admin panel.

The module also expects four third-party Oxide plugins to be present for the features that follow the bridge itself — Clans, Kits, PopupNotifications and ZoneManager, all from k1lly0u on umod.org. The bridge works without them; the features that read them do not.

---

2. The order that works

Sidecar first, then plugin, then website. Any order eventually converges — the plugin retries for ever and the website polls — but this one gives you a readable log at each step instead of three components all reporting that something else is missing.

2.1 The sidecar

rust-link-sidecar --print-config

This resolves the configuration exactly as a normal start would: it writes sidecar.toml if it is missing, generates and saves an auth token if there is none, and prints the whole thing as JSON — including the token in clear text, which is the point. Keep that token; the website needs it and there is no second way to read it back.

{
  "component": "rust-link-sidecar",
  "protocol": 1,
  "config_path": "/etc/runicgateway/rust-main.toml",
  "game": { "bind": "127.0.0.1:7799", "server_id": "" },
  "web":  { "bind": "127.0.0.1:8090", "auth_token": "…", "ws_path": "/ws" },
  "store": { "path": "/var/lib/runicgateway/rust-link.db" }
}

Then start it. On a host running more than one game server, give each sidecar its own --config, its own ports and its own database file.

[game].bind stays on loopback. There is no token on the game link — the plugin and the sidecar share a host and 127.0.0.1 is the authentication. Moving that bind to a routable address puts an unauthenticated command channel on the network.

[web].bind is the one you may need to move, because the website is usually on another host. Behind TLS and a firewall: the token is the only thing guarding it.

Check it:

curl http://127.0.0.1:8090/health
{"status":"degraded","protocol":1,"plugin_connected":false,"database":"ok","uptime":"0m","last_event":null}

degraded with plugin_connected: false is exactly right at this point — nothing is connected yet.

2.2 The plugin

cp RunicGateway.cs /path/to/rust/oxide/plugins/

Oxide compiles and loads it on the write. Watch oxide/logs/:

[Info] RunicGateway was compiled successfully in 2295ms
[Info] [Runic Gateway] protocol 1, serverId 'main', sidecar 127.0.0.1:7799
[Info] [Runic Gateway] connected to 127.0.0.1:7799

The first load also writes oxide/config/RunicGateway.json. Set ServerId before you go further:

{ "Host": "127.0.0.1", "Port": 7799, "QueueCap": 5000, "ServerId": "main" }

ServerId is this server's identity as the website knows it, and it is permanent. It is not derived from the hostname on purpose — an operator renames a server for a season, and the site must not lose its history for it. Changing it later orphans everything recorded under the old one.

Now /health should read:

{"status":"ok","protocol":1,"plugin_connected":true,"database":"ok","uptime":"2m","last_event":"…"}

If it does not, ask the game server:

rg.link
protocol=1 serverId=main connected=True depth=0 sent=3 dropped=0 received=2
connects=1 writeErrors=0 bootId=boot-20260915T194502Z

2.3 The website

Admin → Rust → add a server. Four values:

Field	Value
Id	the slug every URL carries. Match ServerId in the plugin config
Name	what visitors see
Sidecar base URL	http://<sidecar host>:8090
Sidecar token	the auth_token from --print-config

The token is write-only. It is stored encrypted and never returned to any client; the panel reports only whether one is set. A save that leaves the field blank keeps the stored one — so renaming a server does not mean re-pasting a credential.

Then press Test, which probes the sidecar and reports what came back:

{ "ok": true, "status": "ok",
  "sidecar": { "status": "ok", "protocol": 1, "plugin_connected": true, … } }

Within a poll interval the server appears at /rust/servers.

---

3. When it does not work

A wrong URL, a wrong token and a mismatched protocol version all present as "the site says my server is offline". The Test button is what separates them, and its status is the whole diagnosis:

status	What is wrong	Where to look
ok	nothing	—
no-token	the admin form was saved without one	Admin → Rust
unauthorized	the token does not match	--print-config on the sidecar host
protocol-mismatch	the sidecar and the module speak different versions	upgrade one of them; the body names both numbers
timeout	the sidecar answered too slowly, or not at all	the sidecar's own log
transport-error	nothing is listening at that address	the base URL, the firewall, whether the sidecar is running
http-<code>	something answered, and it was not a sidecar	usually a reverse proxy in front of the wrong thing

Two failures that look alike and are not:

• plugin_connected: false with an otherwise healthy sidecar — the bridge is fine and the game is not talking to it. Check the plugin is loaded (oxide.plugins) and rg.link on the game server.
• The server is listed but reads stale — something reported once and has not since. The row says what was true when it was written; nothing has written it since. Either the poll is failing (the website's log) or the sidecar stopped (its own).

3.1 The failures that are supposed to happen

Three things look like breakage and are the design:

• Killing the sidecar does not disturb the game. The plugin logs sidecar link lost; reconnecting and retries with backoff, buffering into a bounded queue that drops its oldest entries rather than growing. The game does not stall, and Emit never touches a socket.
• Starting the plugin before the sidecar logs one line and then goes quiet. cannot reach the sidecar: … — retrying quietly until it answers, printed once per load rather than every few seconds. A wrong Host or Port looks exactly like this, which is why it is printed at all.
• The website renders with every game server off. The server list, the player counts and the last-reported times all come from stored state. A page that 500s because a socket is closed would be a module that made the site's availability depend on the game's.

---

4. Running more than one server

Each pair is fully independent: its own ports, its own sidecar.toml, its own database file, its own token, its own row on the website.

Set [game].server_id in each sidecar.toml to match that server's plugin config. It is a cross-check, not a second source of truth — the plugin's announcement wins — and it exists to catch exactly one mistake: two game servers pointed at one sidecar by a copied config, which is silent in every other design and produces one server's history under another's name. When it fires you get a warning naming both ids.

---

5. Upgrading

The four declaration sites in PROTOCOL.md §2 must agree. In practice that means upgrading the sidecar and the plugin together, because the game link has no version check of its own and a mismatched plugin mis-parses rather than refusing.

The website is the forgiving half: it sends its version on every request and a sidecar that disagrees answers 409 with both numbers, so a module ahead of or behind its sidecar reports a named fault rather than misbehaving.