Cross-Server Setup

Prerequisites

• Two or more Minecraft servers behind a Velocity or BungeeCord proxy
• Redis available to all Minecraft servers through Ceremony’s distributed services
• Ceremony installed and configured on every server
• One server designated as the Frontier ORCHESTRATOR
• Matching ladders.conf, formats.conf, and messages.conf across the network

Architecture

[Lobby 1 (PARTICIPANT)] --\
                           \
[Lobby 2 (PARTICIPANT)] -----> [Redis / Ceremony distributed services] <-----> [Battle Server (ORCHESTRATOR)]
                           /
[Lobby 3 (PARTICIPANT)] --/

• ORCHESTRATOR runs matchmaking, publishes queue sizes, receives remote queue joins, and hosts the actual battles
• PARTICIPANT servers accept queue/challenge input and forward the requests to the orchestrator

ORCHESTRATOR Config

In config/frontier/config.conf:

crossServer {
    enabled = true
    role = ORCHESTRATOR
    battleServer = "battle"
    channel = "frontier"
}

This server also needs:

• arenas configured
• full ladder / format / clause / tournament data
• enough resources to host the live battles

PARTICIPANT Config

crossServer {
    enabled = true
    role = PARTICIPANT
    battleServer = "battle"
    channel = "frontier"
}

Participant servers should keep these in sync with the orchestrator:

• ladders.conf
• formats.conf
• messages.conf

That lets them validate teams locally and display the right queue information before forwarding requests.

Ceremony / Redis

Each server needs a unique Ceremony messageBus.serverId.

Example conceptually:

messageBus {
    serverId = "battle"
    redis {
        host = "your-redis-host"
        port = 6379
    }
}

The exact Ceremony structure may vary by version, but the important rule is: every server gets a unique serverId, and every Frontier server points at the same distributed backend.

Cross-Server Queue Flow

1. Player joins /ranked queue <ladder> on a participant.
2. The participant validates the team locally.
3. The participant forwards the queue join to the orchestrator.
4. The orchestrator stores the remote queue entry, including the player’s source server and serialized team.
5. The orchestrator runs normal matchmaking.
6. When a match is found:
   • local players are matched directly or marked as pending arrival
   • remote players receive transfer orders back through their source servers
7. Both players arrive on the orchestrator and the match starts there.
8. After the battle, they return to their origin server and original position.

Queue Visibility on Participants

Participants do not own the queues. Instead:

• the orchestrator publishes queue sizes into distributed KV
• participants refresh cached queue sizes from that shared data
• the queue GUIs and /ranked queue info use the cached counts

That is why one orchestrator is required.

Challenges, Spectating, and Tournaments

Cross-server mode also covers:

• direct challenges between players on different servers
• spectator transfers to the orchestrator
• remote tournament registration and tournament match transfers

If a remote tournament player is offline when their match should start, they forfeit.

Troubleshooting

Symptom	Likely Cause
”Battle server unavailable”	The orchestrator or distributed backend is down.
Queue counts stay at zero on participants	Queue size publishing from the orchestrator is not reaching distributed KV.
Transfers never happen	Ceremony/plugin messaging transfer flow is not working through the proxy.
Players do not return after matches	Return transfer handling is failing or the origin server is unavailable.
Cross-server commands work but no matches form	The orchestrator is not receiving forwarded queue entries or cannot see remote presence.