← Blog

Configurer un serveur Arma Reforger depuis zéro

Par Benjamin Dayan · PDG

· Mis à jour le October 10, 2026 · Lecture 7 min

Contents

The Arma Reforger config.json file is the single source of truth for how your instance behaves: which scenario loads, how many players can connect, which mods are active, and how the mission is presented in the server browser. Starting from an empty file can feel intimidating, but the structure is logical once you break it into blocks.



How the Arma Reforger config.json File Is Organized

Before touching a single line, it helps to understand that the Arma Reforger config.json is a plain JSON document split into a handful of top-level objects: network bindings, an admin list, and a game object that nests everything related to the actual match (scenario, player slots, mods, and the mission header). Reforger does not ship with a default file — you create it, name it (commonly server.json), and point the executable to it with a launch argument.

The root of the file typically looks like this before you fill in the details:

{
  "bindAddress": "0.0.0.0",
  "bindPort": 2001,
  "publicAddress": "",
  "publicPort": 2001,
  "a2s": {
    "address": "0.0.0.0",
    "port": 17777
  },
  "rcon": {
    "address": "0.0.0.0",
    "port": 19999,
    "password": "changeMe",
    "permission": "admin",
    "blacklist": [],
    "whitelist": []
  },
  "game": {}
}

bindAddress and bindPort define where the process listens, publicAddress is what gets advertised to the master server list if you want your instance to appear publicly, and the a2s block handles the query protocol used by browser tools. The rcon object is optional but recommended if you plan to moderate remotely — always replace the default password before going live. If you'd rather skip the manual setup entirely and deploy a ready instance with the panel already wired to Pterodactyl, an Arma Reforger server hosting environment handles the binding and ports for you so you can focus on the game object itself, which is where the real configuration work happens.



Building the Game Object: Scenario, Player Count and Mods

Everything that defines the actual session lives inside game. This is where you set the scenario ID, the maximum number of players, and the mod list that gets downloaded and loaded by clients connecting to your instance.

Scenario ID

Reforger identifies scenarios by a resource path rather than a friendly name. The official Conflict scenario on Everon, for example, uses:

"scenarioId": "{ECC61978EDCC2B5A}Missions/23_Campaign.conf"

If you're running a custom mission built in the Workbench, the ID points to your exported .conf file instead. A wrong or mistyped scenario ID is the single most common reason a freshly written config fails silently on launch, so double-check the GUID and path against the editor export before saving.

Player Count and Visibility

Player slots, name, and whether the instance appears in the public browser are set directly under game:

"game": {
  "name": "My Reforger Session",
  "password": "",
  "passwordAdmin": "changeMeToo",
  "admins": [],
  "scenarioId": "{ECC61978EDCC2B5A}Missions/23_Campaign.conf",
  "maxPlayers": 64,
  "visible": true,
  "crossPlatform": true,
  "supportedPlatforms": ["PLATFORM_PC", "PLATFORM_XBL"],
  "gameProperties": {},
  "mods": []
}

maxPlayers should match what your hardware can actually sustain — tick rate and simulation load scale with player count and AI density, so pushing the slot count beyond what the CPU can process leads to desync rather than smoother sessions. This is one of the areas where running on fast Ryzen cores with NVMe storage noticeably reduces loading stutter when the mission streams in large persistence files or heavy mod packs.

The Mods Array

Each entry in mods needs the mod's workshop ID and name, pulled from the mod's page on the Reforger workshop:

"mods": [
  {
    "modId": "5CDC2CFC5D250123",
    "name": "Community Base Mod",
    "version": "1.2.0"
  },
  {
    "modId": "61DA7F74C664AED4",
    "name": "Extra Vehicles"
  }
]

The version field is optional; omitting it tells the server to always fetch the latest published build. If you run several mods together, load order matters for dependencies — place base/framework mods before the content that relies on them. Keep a backup of a working mod list before testing new additions; a single malformed entry in the array can prevent the whole file from parsing.



Mission Header and Game Properties

Two sections are easy to overlook but shape how your session actually plays once people connect: the mission header exposed in the browser, and the gameProperties object that tunes gameplay rules.

Mission Header Fields

The header is what shows up in the in-game server list — name, description tags, and whether BattlEye is enforced:

"game": {
  "name": "Fly Example - Conflict 24/7",
  "battlEye": true,
  "visible": true
}

Setting battlEye to true enforces the anti-cheat layer at the process level; most community instances leave it on unless they're running heavily modded content that conflicts with the driver.

gameProperties: Fine-Tuning Gameplay

This nested object controls simulation-level behavior — view distance, network tick, AI limits, and voice options:

"gameProperties": {
  "serverMaxViewDistance": 2500,
  "serverMinGrassDistance": 50,
  "networkViewDistance": 1000,
  "disableThirdPerson": false,
  "fastValidation": true,
  "battlEye": true,
  "VONDisableUI": false,
  "VONDisableDirectSpeechUI": false,
  "missionHeader": {
    "m_sName": "Conflict Everon",
    "m_sAuthor": "Bohemia Interactive",
    "m_sSaveFileName": "Conflict"
  }
}

Raising serverMaxViewDistance improves spotting fairness on open maps like Everon but increases bandwidth and CPU cost per client, so pair any increase with monitoring of your instance's tick stability rather than setting it blind. networkViewDistance should generally stay at or below the max view distance to avoid clients rendering entities the network hasn't synced yet.

FieldPurposeTypical value
scenarioIdDefines which mission loadsWorkshop or editor path
maxPlayersCaps concurrent connections32–128 depending on hardware
serverMaxViewDistanceRender distance in meters1600–2500
battlEyeEnables anti-cheat enforcementtrue
modsList of active workshop contentArray of modId/name pairs


Validating and Deploying the Configuration File

JSON is strict about syntax — a missing comma or an unclosed bracket stops the whole process from launching, often without a clear error message in the console. Run the file through a validator before deployment, or use a text editor with JSON linting enabled to catch trailing commas and quote mismatches early.

Checking the File Before Launch

cat config.json | python3 -m json.tool

If this command prints a formatted, readable version of your file, the syntax is valid. Any parsing error will point you directly to the offending line.

Applying Changes

Once the file is saved in the correct folder, restart the process so the new configuration is read on boot:

systemctl restart arma-reforger

If you manage the instance through a control panel, uploading the edited file and using the restart button achieves the same result without touching a terminal. Through All our game servers, configuration changes, mod installs, and restarts are handled from a single interface, which is useful when you're iterating on gameProperties values and need quick restart cycles to test each tweak.

Backups and Self-Managed Instances

Keep a copy of every working version of your config before editing it further — a quick cp config.json config.json.bak saves time when a new mod addition breaks the parse. If you're running the process yourself on a machine you administer, securing SSH access with key-based authentication and restricting inbound ports with ufw protects the box the configuration lives on. A Linux VPS or a Pterodactyl VPS both work for this kind of self-managed setup, with automated snapshots adding a second safety net on top of your manual config backups. For the exact field list and accepted values, Bohemia Interactive's own documentation is the reference to check against: Arma Reforger Server Config Wiki.



Building a working Arma Reforger config.json from scratch comes down to four blocks: network bindings, the scenario ID, player and mod settings, and the mission header inside gameProperties. Validate the JSON syntax before every restart, keep backups of working versions, and adjust view distance and player count based on what your instance can actually sustain.



FAQ

Why does my Arma Reforger instance fail to start after editing config.json?

In most cases this is a JSON syntax error — a missing comma, unclosed bracket, or stray quote. Run the file through a JSON validator before restarting the process to catch the exact line causing the failure.

What happens if a modId in the mods array is incorrect?

The process will either fail to load the mod silently or refuse to start the mission entirely. Double-check the modId against the mod's official workshop page and remove the entry temporarily to isolate which one is causing the issue.

Can I change maxPlayers without restarting the whole session?

No, changes to config.json are only read on process start. Adjust the value, save the file, and restart the instance for the new player cap to take effect.

Read next