Arma Reforger Mod Versions: Locking, Collections and Update Workflow

There is a specific failure that every Arma Reforger community with a modlist eventually hits. The server was fine on Tuesday. Nobody touched the config. On Wednesday evening, half the regulars cannot join, and the ones who can are missing content.

Nothing broke on your side. A mod updated on the Workshop, your server picked up the new build on its last restart, and the client-side state no longer matches. That is the default behaviour, not a bug — and it is worth understanding before it costs you an operation.

Why an unlocked mod is a moving target#

A mod entry in config.json looks like this:

{
    "modId": "591AF5BDA9F7CE8B",
    "name": "Capture & Hold",
    "required": true
}

No version field. That means "latest", evaluated at boot. Every restart is an opportunity for the modlist to change.

Add a version and it stops moving:

{
    "modId": "591AF5BDA9F7CE8B",
    "name": "Capture & Hold",
    "version": "1.0.3",
    "required": true
}

That is the entire mechanism. See adding Workshop mods for the surrounding format.

Locked versus latest: pick per server, not per community#

Neither answer is right for everything.

Lock versions when the server is something people schedule around — a milsim unit's operation night, a persistent Conflict campaign, anything where an unexpected outage costs more than a few days of running slightly behind. This is most servers that matter.

Track latest when the server is a test or staging instance, or a small private server where you would rather have the newest content than a stable one. Tracking latest on a test server is genuinely useful: it is where you find out a mod update broke something, before it reaches the server your community uses.

The strong pattern for an established community is both: a locked production server, and a latest-tracking test server that tells you what the next update will do.

An update workflow that does not ruin an evening#

1. Watch for updates rather than absorbing them. Check the Workshop pages for your locked mods, or let a test server surface changes for you.
2. Update the test server first. Load the new versions, start it, join it, and actually play the scenario briefly. A clean boot is not proof — content can be missing or behave differently on a server that started perfectly.
3. Update related mods together. When a framework and the content built on it both have new builds, promote them in the same pass. A half-updated set is harder to reason about than either version of it.
4. Schedule the production update. Announce it, then apply it at a time nobody is mid-session.
5. Restart deliberately, not incidentally. The dangerous restart is the unplanned one — a crash recovery at 21:00 that quietly pulls new builds. Locked versions make even that restart safe, which is most of the point.
6. Keep the previous versions written down. Rolling back is trivial if you know what you were on and impossible if you do not.

Collections: the other half of the problem#

Version locking stops the modlist changing under you. Collections solve a different problem: needing more than one modlist.

Most communities end up with at least two — a heavier milsim set and a lighter public set, or a Conflict list and a Game Master list. Managing that by hand-editing the mods array each time is where mistakes get made: an entry left behind from the previous list, a version lock dropped during a swap, a stray comma that stops the server booting at the worst moment.

Keeping each modlist as a named, saved set — and switching between them as a unit — removes that whole class of error. Our panel does this natively: save collections, switch between them in one action, keep per-collection version locks, and see the total download size players will face before you commit to a list.

Verify it worked#

1. Every mod entry that matters has an explicit version.
2. config.json validates — check it in the config validator before restarting.
3. The server boots and the log shows the versions you locked, not newer ones.
4. A client that has never joined this configuration connects cleanly. Test with an account whose cache is not already correct.
5. The previous version set is recorded somewhere you will find it under pressure.

Trusted references#

• Arma Reforger Workshop — mod pages, versions and dependencies
• Arma Reforger: Server Config
• Arma Reforger: Server Hosting