sidecar.toml

The uo-link sidecar’s configuration. It is deliberately tiny: the sidecar is a dumb forwarder, and policy lives on the website where an administrator can see it.

The file is written, not shipped

The sidecar writes sidecar.toml on first run, including a generated auth token. There is no committed sample that is authoritative, and nothing is compiled into the binary.

Point it elsewhere with $UOLINK_CONFIG.

Authentication is always on

A blank token is not “no authentication” — it is auto-generated and written back, so the web surface is authenticated from first boot. There is no way to turn it off, which is the correct default for the one component that is exposed.

The keys

Key	What it is for
shard.bind	Loopback address the game plugin dials out to
web.bind	Address the website reaches the sidecar on
web.auth_token	Shared secret the website must present. Generated on first run if blank
store.path	The sidecar's own durable store

This list is checked against the sidecar’s own config structs on every build, so a key added upstream turns this page red rather than quietly going undocumented.

What is not in here

Worth stating, because the absences are the design:

• No allowlist, no audience rules, no visibility settings. Those are the website’s, and admin-toggleable. The sidecar forwards; the site decides who may see what.
• No website URL. The website reaches the sidecar, not the other way round.
• No protocol version. It is compiled in, because a sidecar that could be configured to claim a different protocol would defeat the check. See Protocol versions.

Running it

cargo run                 # writes sidecar.toml on first run
RUST_LOG=debug cargo run   # verbose, including heartbeats

Normally you do not run it by hand — the installer installs it and registers its service.

Canonical documents

The structs in sidecar/src/config.rs are the authority; link/PLAN.md is the design of record and ADMIN_CONTROLS.md covers what the site may command the game to do.