When your Arma Reforger server starts filling up, two things decide whether players stick around or rage-quit to the browser: whether there is a join queue to hold them while a slot opens, and whether your admins (and recently disconnected regulars) can skip ahead of everyone else. Both are controlled by a handful of exact fields in your config.json — but they live in different blocks, have strict numeric ranges, and several only exist in newer game versions. Get one value wrong and the queue silently does nothing.
This guide walks through every queue-related setting in the dedicated server config: maxPlayers, the joinQueue block, the admin priority queue, reserved-slot behaviour on disconnect, and how they interact. All field names, ranges and defaults below are verified against the official Bohemia Interactive server config wiki. Values are version-gated where Bohemia documents a specific introduction build, so check the per-feature notes if you are running an older install.
How queueing actually works in Arma Reforger
Arma Reforger does not have a single “queue” toggle. There are really three distinct mechanisms, and confusing them is the most common reason people think queues are broken:
- Player slot capacity —
game.maxPlayerssets how many players can be in the server at once (1–128, default 64). - The join queue —
operating.joinQueue.maxSizesets how many extra players can wait when the server is full (0–50, default 0 = disabled). - Priority queue — listed admins get their own queue ahead of normal waiting players (since v1.3.0), and disconnected players can have their slot reserved for a timeout window (
operating.slotReservationTimeout).
So a “queue” in the everyday sense is the combination of a sized waiting line (joinQueue.maxSize) plus the priority and reservation rules that decide who gets the next freed slot. Let’s set each one correctly.
Step 1: Set your player cap with maxPlayers
maxPlayers lives inside the game block of config.json. It is a number with a valid range of 1 to 128 and a default of 64. This is the hard ceiling — once this many players are connected, every additional joiner either gets bounced (if no queue) or placed into the join queue (if you enabled one in Step 2).
"game": {
"name": "My Reforger Server",
"maxPlayers": 64,
"scenarioId": "{ECC61978EDCC2B5A}Missions/23_Campaign.conf"
}One important nuance: a Conflict scenario also carries its own intended player count inside the mission header. You can override it with gameProperties.missionHeader using m_iPlayerCount. Setting maxPlayers to 128 while the scenario expects 40 will let bodies in, but the balance was not designed for it — keep the two roughly aligned. Be realistic about your hardware too: Reforger servers are CPU-bound and largely single-thread, so a 128-player Conflict fight with full AI is far heavier than the player count alone suggests. More on sizing later.
Step 2: Enable the join queue (joinQueue.maxSize)
The actual waiting line is operating.joinQueue.maxSize. It was added in v1.2.1.66, so if you are on an older build this field simply will not exist. Its valid range is 0 to 50, and the default is 0, which means the queue is disabled. That default is exactly why many server owners find no queue at all — you have to opt in.
"operating": {
"lobbyPlayerSynchronise": true,
"slotReservationTimeout": 60,
"joinQueue": {
"maxSize": 20
}
}With maxSize set to 20, up to 20 players can hold a place in line once your server hits maxPlayers. They wait on a connection screen instead of being kicked back to the browser, and they are admitted in order as slots free up. Pick a size proportional to your population — a 64-slot popular server might want 20–30; a small private server can leave it at 0 or set it to 5.
Note that joinQueue is a nested object, not a flat number. Writing "joinQueue": 20 is invalid JSON for this field — it must be "joinQueue": { "maxSize": 20 }. Remember that config keys are case-sensitive throughout.
Step 3: Give admins (and VIPs) priority with the admin queue
A general queue is fair, but you usually want your staff to jump the line. Since v1.3.0, listed admins get a dedicated priority queue that sits ahead of the normal join queue — when a slot opens, a waiting admin is admitted before regular players.
There is a critical catch that trips up nearly everyone: priority queue only works for admins specified by IdentityId, not by SteamId. The admins array accepts both IdentityIds and Steam64 IDs, and either kind lets that person #login as admin without a password (since v1.0.0). But if you list a 17-digit Steam64 ID, that admin can manage the server yet will not get priority-queue treatment. To grant queue priority, you must use the player’s IdentityId.
Also note that since v1.3.0 the admins list is capped at 20 unique IDs. That is your effective limit on how many people can hold reserved-slot/priority status this way.
"game": {
"passwordAdmin": "changeme",
"admins": [
"1a2b3c4d-0000-0000-0000-000000000000",
"9f8e7d6c-1111-1111-1111-111111111111"
]
}The IdentityId is the persistent Bohemia account identity, distinct from a Steam64 ID. You can read a connected player’s id in-game with the #id command, and list everyone currently in the session — with their playerIds — using #players. For a full walk-through of admin authentication and the command set, see our Arma Reforger 1.7 server admin guide.
Step 4: Reserve slots for disconnected players (slotReservationTimeout)
Reserved slots in Reforger are not a static VIP-list feature — they are a time-based hold for players who just dropped. operating.slotReservationTimeout (added in v0.9.9.31) controls how long the backend keeps a player’s slot reserved after a kick or disconnect, so they can reconnect straight into their place instead of fighting the queue again.
- Range: 5 to 300 seconds.
- Default: 60 seconds.
- Minimum (5): effectively disables reservation — the slot is treated as a normal immediate disconnect.
- Scope: applies only to replication kicks (network-level drops), not to manual
#kickor bans.
For a busy public server, the 60-second default is a sensible balance — long enough to ride out a brief connection hiccup, short enough that a genuinely gone player frees the slot for the queue quickly. Raise it toward 120–180 only if your community tolerates seats sitting empty during reconnects.
The 1.7.0.41 “Partisan Update” also introduced a reconnection-queue system on top of this. The exact behaviour is not fully documented yet, so treat it qualitatively: the takeaway is that recent versions are getting smarter about returning dropped players to their slots — check the current official changelog and wiki for the latest specifics before relying on details.
The complete queue config in context
Here is how all four pieces fit together in a real (trimmed) config.json. The game-traffic and query fields are included so the structure is clear, but the queue-relevant lines are maxPlayers, admins, slotReservationTimeout and the joinQueue block:
{
"bindAddress": "",
"bindPort": 2001,
"publicAddress": "",
"publicPort": 2001,
"a2s": { "address": "", "port": 17777 },
"game": {
"name": "My Reforger Server",
"password": "",
"passwordAdmin": "changeme",
"admins": ["1a2b3c4d-0000-0000-0000-000000000000"],
"scenarioId": "{ECC61978EDCC2B5A}Missions/23_Campaign.conf",
"maxPlayers": 64,
"visible": true,
"gameProperties": {
"serverMaxViewDistance": 1600,
"networkViewDistance": 1500,
"fastValidation": true,
"battlEye": true
}
},
"operating": {
"lobbyPlayerSynchronise": true,
"slotReservationTimeout": 60,
"joinQueue": { "maxSize": 20 }
}
}Pass this file at launch with the -config parameter and set a frame cap so the server does not eat all your CPU:
./ArmaReforgerServer -config /home/user/.config/ArmaReforgerServer/config.json -profile /home/user/.config/ArmaReforgerServer -maxFPS 60The dedicated server installs anonymously via SteamCMD using app ID 1874900 (the experimental branch is 1890870; do not use the client app 1874880). If you have not stood the server up yet, our full Arma Reforger server setup guide covers install, ports and first launch end to end, and the broader server configuration guide documents every config block beyond queues.
Queue and slot fields at a glance
| Field | Block | Range | Default | Purpose |
|---|---|---|---|---|
maxPlayers | game | 1–128 | 64 | Hard cap on connected players |
joinQueue.maxSize | operating | 0–50 | 0 (off) | How many players can wait in line |
slotReservationTimeout | operating | 5–300 s | 60 s | Hold a dropped player’s slot for reconnect |
admins | game | up to 20 IDs | [] | Priority queue (IdentityId only) |
lobbyPlayerSynchronise | operating | bool | true | Keeps reported player count accurate |
One supporting field worth enabling: operating.lobbyPlayerSynchronise (default true since v0.9.8.73) sends the player identity list with the server heartbeat, which fixes discrepancies between the real and reported player count. If your browser listing shows the wrong number of players — and therefore mis-signals when the queue should kick in — make sure this stays on.
Make sure players can actually reach the queue: ports
A queue is useless if players cannot find or reach the server in the first place. Port forwarding is required for any server reachable outside the LAN, and the player count shown in the browser depends on the query port. At minimum forward the game port; forward the query port too so your slot/queue status displays correctly.
| Purpose | Config field | Default | Protocol |
|---|---|---|---|
| Game traffic | bindPort / publicPort | 2001 | UDP (must forward) |
| Steam / A2S query | a2s.port | 17777 | UDP (forward for browser) |
| RCON | rcon.port | 19999 | UDP (optional) |
Note that IPv6 is not supported, so use IPv4 only. On Linux or Docker hosts, set publicAddress and publicPort to a reachable IP/port — by default a container registers its internal IP, which breaks client connections (and therefore queueing) entirely. The detailed connection steps live in our Arma Reforger documentation.
Sizing your server for the player count you queue for
If you set maxPlayers to 128 and a 30-deep queue, the machine behind it has to deliver. Bohemia does not publish official per-player server hardware tables, so the following is community and hosting-experience guidance, not an official requirement:
- Reforger servers are CPU-bound and largely single-thread — high single-core clock speed matters most. Large AI battles, not raw player count, are the dominant CPU driver.
- Rough RAM sizing: ~8 GB for ~32 players, ~16 GB for ~64 players, up to ~64 GB for 128 players.
- Server CPU load scales with tick rate — the wiki strongly recommends setting
-maxFPSto 60–120 so the server does not consume all available CPU. Running at ~30 FPS is far lighter. - Allow roughly 40 GB of free disk for the install (community figure).
If you do not need AI for a player-versus-player game mode, disabling it with operating.disableAI: true dramatically cuts CPU load and lets you support a higher real player count. See our guide on disabling AI for a PvP server for the trade-offs.
If you would rather skip the hardware math entirely, a managed Arma Reforger hosting plan ships these config files pre-built with the queue and priority fields exposed in the panel, on hardware tuned for single-thread performance — so a full server with a 30-deep queue stays smooth.
Frequently asked questions
Why is my Arma Reforger server queue not working?
The most common cause is that operating.joinQueue.maxSize is still at its default of 0, which disables the queue. Set it to a value between 1 and 50. The second most common cause is being on a game build older than v1.2.1.66, where the field does not exist. Also confirm the field is nested correctly as "joinQueue": { "maxSize": 20 } and that your JSON is valid — keys are case-sensitive, and a single syntax error can make the server ignore the operating block.
How do I give admins reserved slots or priority in the queue?
Add the admin to the game.admins array using their IdentityId, not their Steam64 ID. Since v1.3.0, listed admins get a priority queue ahead of regular players, but this only applies to IdentityId entries — a Steam64 ID grants admin rights yet no queue priority. The list is capped at 20 unique IDs. There is no separate “reserved VIP slot” list in vanilla Reforger; admin priority queue plus slotReservationTimeout are the built-in mechanisms.
What is the maximum number of players on an Arma Reforger server?
game.maxPlayers accepts a range of 1 to 128, with a default of 64. So 128 is the configurable maximum. In practice the achievable count depends on hardware (these servers are CPU-bound and single-thread-heavy) and on AI load — a 128-player Conflict match with full AI is far more demanding than the number suggests. Keep maxPlayers roughly aligned with the scenario’s intended count, which you can override via gameProperties.missionHeader.m_iPlayerCount.
How long does Arma Reforger hold a slot when a player disconnects?
By default, 60 seconds, controlled by operating.slotReservationTimeout. The valid range is 5 to 300 seconds. Setting it to the minimum of 5 effectively disables reservation, treating the drop as a normal immediate disconnect that frees the slot for the queue. Reservation applies only to replication (network) kicks — it does not hold a slot for someone you manually #kick or ban.
Does enabling a queue require mods or RCON?
No. The join queue, admin priority queue and slot reservation are all native config fields in vanilla Reforger — no mods needed. RCON (the rcon block, default port 19999) is optional and only used for remote administration; it has nothing to do with whether the queue functions. If you do add mods, note the crossplay trade-off: any mod removes PlayStation players entirely, and Xbox only keeps console-certified mods. See our guides on installing mods and cross-platform setup.
How do I see who is connected and manage the queue live?
Log in as admin with #login (no password needed if you are in the admins list), then use #players to list everyone in the session with their playerIds, and #id to read a player’s id. To free a slot for the queue you can #kick (they may rejoin) or #ban create where a duration of 0 is permanent. Use #restart to restart the scenario without dropping connected clients, or #shutdown to stop the server.
Set maxPlayers to your real capacity, turn on joinQueue.maxSize, list your staff by IdentityId for priority, and leave slotReservationTimeout near 60 seconds — that combination gives a full server that holds waiting players, lets admins jump in, and returns dropped regulars to their seats. Version-gate the newer fields against your build, and re-verify any 1.7.x reconnection-queue specifics against the current official wiki.
Ready to play?
Run your own Arma Reforger server with XGamingServer
Spin up an always-on Arma Reforger server your friends can join in minutes — no port-forwarding, no tech headaches.
