Configuration recipes

Ready-made setups for the common server shapes, plus the patterns that make them work. Each recipe is the delta from the minimal server.cfg — the convars it adds and the boot.cfg lines that open its arenas. For the meaning of any single convar, see Server configuration; for how arenas behave, see Operations & ranked.

The patterns

Two ideas explain almost every layout below.

Resources — load order is the contract

Resources live under bracketed groups ([platform]/, [modes]/, [packs]/, [systems]/); the brackets are organizational, FXServer loads anything beneath them. The order you ensure them in encodes who-consumes-whom:

sdk  →  ui · customization · lobby  →  engine  →  systems  →  modes  →  packs
└ owns the registries          └ store/identity convars   └ register themselves

sdk first — it owns the mode / pack / arena registries every later resource reads.
Store + identity convars above ensure engine — rfx_store, rfx_api_url, rfx_season, rfx_connect, rfx_region are read at the engine's first boot. Put them before that line or they only apply after a restart engine. (See the warning in Server configuration §4.)
Adding a mode or map is just an ensure — a mode/battleground pack registers itself with the SDK at start; no engine edit. Narrow the map rotation with rfx_battlegrounds (an allowlist) rather than unloading a battleground pack.
Each mode carries its own config — rfx_<id>_enabled, rfx_<id>_round, rfx_<id>_best_of (royale modes swap in gather/drop tuning). Disable a loaded mode with rfx_<id>_enabled false.

Arenas — one container, one ceiling

An arena is a persistent match container. Console/staff open them by command (in boot.cfg or live); players browse the arena list and join one. The model is uniform across modes:

One arena = one match at a time. Open as many as the concurrent matches you want; x<N> opens N identical arenas. The grand total of all live scenes is capped by rfx_max_scenes (default 8) — arenas past it just wait; and the total live arenas is capped by rfx_max_arenas (default 32; console/boot.cfg arenas bypass it).
Ranked vs casual is per arena (default casual). A ranked arena records stats; a casual arena records nothing. Ranked is system-only — opened from the console / boot.cfg, never by a player — so stats can't be farmed. That's the anti-fake-stats design.
Loadout rules. A ranked non-royale arena must pin a weapon config (pistols·smg·rifle·sniper·shotgun); royale modes require random; any casual arena may use random.
Auto-start on fill; arenas persist. An arena launches when it fills (duel/squad: full; royale: a gather countdown) — no ready-check, no host-start. Leaving or disconnecting frees only your slot; the arena itself survives. Persistent (ranked/staff) arenas recycle match after match until you close them; an empty player-created arena is garbage-collected after rfx_arena_empty_ttl (default 60 s).
Nothing opens by itself. A fresh server has zero arenas; you list the public ones in boot.cfg. Players may create their own casual arenas in-game (gated by rfx_arena_creation); ranked arenas only ever come from the console.

The full arena command:

rfx queue open <mode> [loadout] [rounds] [map] [s<N>] [ranked]

Recipe 1 — Pure 1v1 ranked ladder

A focused competitive duel server: ranked only, every weapon config as its own ladder, a random symmetric map each match. Pairs naturally with a leaderboard (Recipe 5).

# server.cfg — deltas
ensure mode_duel
ensure battleground_pack_base
 
set rfx_duel_round   90      # round seconds
set rfx_duel_best_of 5       # best-of
set rfx_max_scenes   12      # raise the concurrent-match ceiling on a bigger box

Ranked has no convar — a queue is ranked when you declare it with the ranked token, and that's console/boot.cfg-only, so the whole ladder lives in boot.cfg:

# boot.cfg — ONE Quick Play queue + ONE ranked queue per mode.
# No loadout = the RANDOM card: a fresh symmetric weapon each match, so you get full
# weapon variety without splitting the population across cards that never fill.
rfx queue open duel 5 s0
rfx ranked open duel 5 s0

Resist one ladder per weapon. Each extra card splits the searching population; on a small server five duel ladders means five 1-player queues. Add a pinned-weapon card only once a single queue is visibly busy — the engine warns you on every 2nd+ declare, and rfx_queue_max_templates can refuse them outright.

Rematch avoidance needs a crowd. With only two players joined, a rematch is unavoidable; the matchmaker only avoids re-pairing when there's someone else to offer.

Recipe 2 — Casual party server

Open and social: any player can create their own arena, 1v1 + 2v2 + close-quarters rooftop, plus a public Quick Play card per mode. Stats off the table (nothing recorded).

# server.cfg — deltas
ensure mode_duel
ensure mode_squad          # 2v2 — friends join together via a party (key G)
ensure mode_rooftop        # 1v1 close-quarters
ensure battleground_pack_base
 
set rfx_arena_creation all  # anyone may create an arena  (default: staff)
set rfx_arena_private  all  # anyone may create a PRIVATE (password) arena
set rfx_group_max      2    # party ceiling — must be ≥ a squad mode's perTeam

Put rfx_arena_creation / rfx_arena_private above ensure engine — they're read at the engine's first boot (like the store convars), not in the bottom convar block.

# boot.cfg — one Quick Play card per mode, alongside player-created arenas
rfx queue open duel
rfx queue open squad
rfx queue open rooftop

One card per mode, no loadout. Omitting the loadout gives the RANDOM card — a fresh symmetric weapon every match, so weapon variety costs no population split. Declaring one card per weapon instead is what leaves four half-empty queues on a small server.

2v2 needs room for a full party. mode_squad is perTeam = 2, so rfx_group_max must be ≥ 2 or a party can never fill a team.

Recipe 3 — Battle-royale night

Large last-standing lobbies: solo BR + squad royale, a public Quick Play card each, plus VIP-created royale arenas. Royale loadouts are always random.

# server.cfg — deltas
ensure mode_battle_royale  # N teams × 1 (solo)
ensure mode_squad_royale   # N teams × K (squads, group-only)
ensure battleground_pack_base
 
# Solo BR
set rfx_br_max_players 32   # players per drop
set rfx_br_min_players 12   # waiting players that ARM the countdown
set rfx_br_countdown   45   # drop countdown (s) once min is reached
 
# Squad royale
set rfx_sqbr_per_team  2    # squad size (floored at 2)
set rfx_sqbr_max_teams 16   # squads per drop  → max players = per_team × max_teams
set rfx_group_max      2    # parties must reach the squad size (≥ rfx_sqbr_per_team)
 
# Let VIPs create their own royale arenas (a royale is just an arena now)
set rfx_arena_creation vip  # tier allowed to create an arena  (default: staff)

# boot.cfg — one Quick Play card per royale (loadout is RANDOM; launches on a gather countdown)
rfx queue open battle_royale
rfx queue open squad_royale

Squad royale is group-only. A lone player is bounced: only parties of exactly rfx_sqbr_per_team can enter, so rfx_group_max must be ≥ it or the card is unjoinable.

Custom drops are gone. A royale is just an arena — a player creates one via the in-game create form (or an operator via rfx arena open), gated by rfx_arena_creation like any other mode. There's no separate drop convar.

Recipe 4 — VIP-perks server

Turn the defaults into a VIP value ladder: VIPs create arenas and private arenas; everyone else joins what staff opened. This is the configuration half of Selling VIP & packs (which covers Tebex + the cosmetic side).

# server.cfg — gate the creation capabilities behind the VIP tier
# (read at engine first boot → keep these ABOVE `ensure engine`)
set rfx_arena_creation  vip   # only VIP+ may CREATE an arena         (default: staff)
set rfx_arena_private   vip   # only VIP+ may create a PRIVATE arena  (default: all)
 
# OPTIONAL per-mode override (key = the mode id, NOT the resource name)
#set rfx_create_tier_squad  staff  # reserve 2v2 creation to staff while duel stays VIP
 
# Who holds each tier (ACE → tier mapping; defaults shown)
set rfx_ace_vip   group.vip
set rfx_ace_staff group.staff
set rfx_ace_admin group.admin

Grant VIP to a player two ways — by ACE (manual / permanent) or by subscription (via the store). For testing, grant it live:

/rfx ent grant <id> vip 30      # 30-day VIP, exercises the exact path Tebex uses
/rfx ent show  <id>             # inspect: vip + owned packs

VIP also unlocks access='vip' cosmetic packs — the subscription folds into the tier, so VIP-included skins/wraps light up automatically. The full sale model (subscription vs standalone packs, Tebex wiring) is Selling VIP & packs.

Recipe 5 — Public server with a website + leaderboard

Switch from the self-contained kvp store to the api store: a cross-player leaderboard, a public stats site, and the substrate the Tebex pipeline needs. Requires a deployed stats API (Deploy §10).

# server.cfg — these convars are read at engine FIRST boot, so keep them ABOVE `ensure engine`
set rfx_store     api
set rfx_api_url   "https://api.example.com"   # your deployed stats API (no trailing slash)
set rfx_season    alpha                        # bump to roll the leaderboard forward
set rfx_server_id eu-duel-1                     # stable per-server slug (per-server stats)
set rfx_connect   "play.example.com"           # shown on the site join card
set rfx_region    "EU-West"                     # display label
 
ensure engine     # ...everything above this line applies on a cold start

# server_secrets.cfg — the write token is a SECRET, never in server.cfg
set rfx_api_token "…"      # must equal the API's ingest token

rfx_store=api is the prerequisite for selling. Purchases are delivered Tebex → cloud API → server, so monetization only works on this store. See Selling VIP & packs.