Skip to main content

​
Connect your network

Give players one place to choose a recording, then send them to a dedicated replay server. This guide connects recorder → shared storage → lobby → player.
Only need one server? Skip this page. Everything here is for multi-server setups with a proxy. Get local recording and playback working first.

​
Before you begin

  • A working local recording/playback test.
  • A proxy with stable backend names, such as replay-lobby and replay-1.
  • Shared SQL replay storage reachable by every role.
Two systems, two jobs: SQL stores your replay archive. Availability tells the lobby which replay servers are online; it can use that SQL database or Redis.

​
Architecture

Two separate systems must be shared:
  1. Replay storage: typically one SQL database used by recorder, lobby, and player.
  2. Availability: either the database backend or a shared Redis endpoint used by lobby and player.
Redis contains liveness and short-lived handoffs, not .rpl event data or chunk snapshots.

​
1. Configure the proxy

Register your lobby and replay servers under stable proxy names, for example replay-lobby, replay-1, and replay-2. Players must be able to connect to those names through the proxy. Transfers use the BungeeCord plugin-message channel with the Connect subchannel. For BungeeCord-compatible proxies, make sure that channel is supported. On Velocity, enable its BungeeCord plugin-message compatibility option where required by your proxy configuration. No separate Reverse proxy plugin is supplied. Do an ordinary manual proxy transfer first. Fix forwarding/server-registration issues before debugging Reverse’s selection flow.

​
2. Share storage

Use the same SQL connection settings on all participating roles. Merge this section into each config.yml, retaining the other generated storage fields:
The example hostname is a placeholder. Create the database and a suitable account yourself. Reverse’s backend initializes its schema; it does not provision a database server. Do not enable local fallback on a worker and expect its private disk to be visible elsewhere. See storage.

​
3. Choose availability

Choose one backend and use the same choice on the lobby and every replay server. sql, mongodb (matching the storage backend you opened) and redis are built-in choices opened at startup. Reverse does not discover availability providers from other installed plugins. The API exposes the runtime’s existing availability service for integrations, but it is not an instruction to replace or reopen the backend after startup.

​
Use your shared database

On the lobby:
On the first player server, use the same settings but node-id: replay-1. On the second use node-id: replay-2. Keep the generated redis section even when unused.SQL availability requires SQL storage to have actually opened successfully. spatial does not provide a shared SQL availability backend. With storage.backend: mongodb, use backend: mongodb instead; it reuses that backend’s availability collections.

​
4. Restart and test

  1. Restart backend servers after changing storage/network settings.
  2. Make a test recording and wait for save completion.
  3. Join the lobby as an owner or administrator.
  4. Open /reverseview and select the replay.
  5. Confirm arrival starts playback on the selected replay server.
  6. Stop playback and confirm return to the origin lobby.
  7. Repeat with a nonowner and check access denial.
Ready to use: a viewer can select a saved recording in the lobby, arrive on a replay server, watch it, and return to the original lobby after stopping.

​
How selection works

Player nodes publish heartbeats. The lobby queries fresh nodes in heartbeat order and chooses the first. It writes a pending selection for the target node/viewer and sends a proxy transfer. The player consumes that selection on join and loads the replay. The lobby does not render scenes or read terrain through a chunk facade. Its Watch action only authorizes the catalog selection and dispatches through the proxy. Chunk delivery belongs to the player server. Pending selections expire after five minutes and are consumed once. A successful dispatch result means the selection was written and a transfer message sent; it is not confirmation that the proxy completed the connection or the client finished loading. Availability is not a queue, capacity reservation, or least-loaded matchmaking system. Several viewers can be sent to the same replayer. Duplicate requests by one viewer are guarded while pending.

​
Common mistakes

  • A node ID is a hostname, UUID, or display title instead of the proxy’s server name.
  • Lobby and player use different Redis databases or SQL databases.
  • One node fell back to local storage at startup.
  • A replay template is present on the recorder but not on the player.
  • A player worker was switched to network mode without restarting.
  • A heartbeat is present, but the proxy cannot reach that server.
Something still not lining up? Work through the troubleshooting guide.