Arma 3 Server Configuration Guide

This is the reference I come back to when I need to look up a specific server.cfg or basic.cfg key, a commandline switch, how mods load, or how BattlEye RCON is wired up. If you're standing up your first Arma 3 server, start with Arma 3: Getting Started first – this article assumes you already have a server running on LOW.MS and just want to know what each knob actually does.

Arma 3 is the grand-dad of the series and its config surface shows it. You're dealing with two config files (server.cfg and basic.cfg), a profile folder for difficulty, a commandline for mods and engine flags, and a separate BattlEye config for RCON. It looks scattered on day one, and then it makes sense forever after.

Where to edit the config

On LOW.MS, open the Configuration Files tab in your server's control panel at control.low.ms. You'll see server.cfg and basic.cfg listed directly – edit them in place, save, and restart the server from the panel. There's no hidden apply step.

For the commandline (mods, engine flags like -autoInit), use Commandline Manager rather than touching a raw batch file. For the difficulty profile (Arma3Profile), use File Manager and browse to the profiles folder – full path below in the difficulty section.

One warning up front: our Windows servers expose SFTP on port 8822 and FTP on 8821, and both block .dll uploads. Arma 3 mods are folder-based (@modname containing .pbo, .bisign, .bikey files), so this almost never bites anyone. The one exception I've seen in the wild is Intercept Core, which ships a .dll – if you need a mod like that uploaded, open a support ticket and we'll place the file for you.

Canonical server.cfg

Here's a sane starting server.cfg. This is close to Bohemia's documented example and is what I'd drop in if I was setting up a fresh server from scratch.

// server.cfg – Arma 3 dedicated server

hostname        = "My LOW.MS Arma 3 Server";
password        = "";             // join password, leave empty for public
passwordAdmin   = "changeme";     // admin password for #login
serverCommandPassword = "changeme"; // used by #exec and scripting

maxPlayers      = 64;
persistent      = 1;              // keep mission running with no players
voteMissionPlayers = 1;
voteThreshold   = 0.33;

motd[] = {
  "Welcome to the server.",
  "Discord: example.com/discord"
};
motdInterval    = 5;

// Security
verifySignatures = 2;             // only v2 .bisign signatures accepted
allowedFilePatching = 1;          // 0 block all, 1 headless only, 2 allow all
BattlEye        = 1;              // anti-cheat on
kickDuplicate   = 1;
requiredBuild   = 0;

// Logging
timeStampFormat = "short";
logFile         = "server_console.log";

// Mission rotation
class Missions {
    class Mission01 {
        template   = "MyMission.Altis";  // mpmissions/MyMission.Altis.pbo
        difficulty = "Custom";
    };
};

// Difficulty profile (see difficulty section)
difficulty = "Custom";

A few things worth calling out before we go deeper:

• persistent = 1 is what lets the mission keep running when the last player leaves, and it's also a prerequisite for the -autoInit commandline flag that starts the mission immediately on server boot.
• verifySignatures = 2 is the current recommended value. 1 accepts both v1 and v2 signatures (v1 is legacy and not something you should rely on); 0 disables signature checking entirely and is how cheaters get in.
• allowedFilePatching = 1 lets a headless client with filePatching join (useful for mission dev) while still blocking regular clients. 0 blocks everyone.
• The admin password is passwordAdmin. Clients authenticate by typing #login yourpassword in chat.

Core server.cfg settings

If you find an older guide referring to equalModRequired or onUserConnected event hooks, those are still valid but rarely worth touching on a first pass. Defaults are fine.

basic.cfg – network tuning

basic.cfg is where you tune how the server pushes packets to clients. The defaults Bohemia ship are conservative and usually fine up to about 40 players on a stock mission. If you're running a busy modded server, you'll want to raise them.

// basic.cfg
language       = "English";
adapter        = -1;
3D_Performance = 1;
Resolution_W   = 1024;
Resolution_H   = 768;
Resolution_Bpp = 32;

// Network tuning
MaxMsgSend              = 384;
MaxSizeGuaranteed       = 512;
MaxSizeNonguaranteed    = 256;
MinBandwidth            = 15000000;
MaxBandwidth            = 100000000;
MinErrorToSend          = 0.001;
MinErrorToSendNear      = 0.01;
MaxCustomFileSize       = 160000;

class sockets { maxPacketSize = 1400; };

The five values that matter for tuning:

• MaxMsgSend – messages per simulation cycle. Default is 128. I bump to 384 on busy servers; higher is not always better because it can starve the sim.
• MaxSizeGuaranteed – max reliable packet size in bytes. Default 512. Rarely needs changing.
• MaxSizeNonguaranteed – max unreliable packet size. Default 256. Same story.
• MinBandwidth – bandwidth the server is guaranteed to have, in bits per second. Default is low – around 256 kbit/s – which is a hangover from the Arma 2 era. On LOW.MS hardware, 15000000 (15 Mbps) is a sensible floor.
• MaxBandwidth – hard ceiling in bps. Default is effectively unlimited. I set it to 100 Mbps so one runaway server can't starve a neighbour.

If players are desyncing, the first lever is MaxMsgSend, not bandwidth. Bandwidth ceilings only matter once you're genuinely saturating a link, and on LOW.MS you almost never are.

Mods

Arma 3 mods are plain folders prefixed with @ – e.g. @CBA_A3, @ace, @RHSAFRF. Inside each folder is an addons/ directory of .pbo files plus signing keys (.bisign, .bikey). You drop the folder into the server root and then reference it on the commandline.

There are two commandline flags for mods, and the difference matters:

• -mod= loads client-side mods. These are announced to the client on join and the client must have them installed. This is what you use for CBA, ACE, RHS, and anything that adds content players can see.
• -serverMod= loads server-side mods that are NOT announced to clients. Use this for admin tools, logging mods, and server-only script extensions that don't ship content.

Both flags take a semicolon-separated list:

-mod=@CBA_A3;@ace;@RHSAFRF -serverMod=@AdminLogging

Signing keys

If verifySignatures = 2; is set, every .pbo in a client-side mod needs a matching .bisign file, and the public key (.bikey) has to live in the server's keys/ folder. Without the key in keys/, the server will kick clients carrying that mod as "signature not found." Most Workshop mods ship the .bikey in a keys/ subfolder – just copy it up one level into the server's root-level keys/ directory.

Workshop vs manual

Steam Workshop is the path of least resistance. In the panel, use Mod Manager to search the Workshop, pick the mod, and it'll download and unpack into the right place. From there, add @modname to your -mod= line in Commandline Manager and restart.

For mods not on the Workshop (private builds, older versions, custom patches), upload the @modname folder via SFTP on port 8822 and add it to the commandline the same way. Remember that .dll uploads are blocked over SFTP – open a ticket for Intercept Core or anything similar.

A tip: if you're running a large modset (ACE + RHS + CUP is already 30+ GB), Steam Workshop downloads through the panel are dramatically faster than SFTP uploads from your home connection. Use the Workshop wherever you can.

Missions

Missions are .pbo files that live in mpmissions/ inside your server root. The filename matters: it's always MissionName.TerrainName.pbo. A mission called "MyOps" on Altis is MyOps.Altis.pbo; the same mission on Tanoa is MyOps.Tanoa.pbo.

Reference them in server.cfg like this:

class Missions {
    class Mission01 {
        template   = "MyOps.Altis";   // no .pbo extension
        difficulty = "Custom";
        class Params {};
    };
    class Mission02 {
        template   = "MyOps.Tanoa";
        difficulty = "Custom";
        class Params {};
    };
};

Two things that trip people up:

1. Two classes with the same name won't load. Use Mission01, Mission02, etc.
2. The template value never includes .pbo. Just the mission filename minus the extension.

With persistent = 1 and -autoInit on the commandline, the first mission in the list starts automatically at server boot. Without -autoInit, a player has to connect and pick it from the lobby on the first run.

Difficulty profile

difficulty = "Custom" in server.cfg tells the engine to read the profile's Arma3Profile file for the actual difficulty settings. That file lives at:

<server-root>\profiles\Users\server\server.Arma3Profile

On LOW.MS the profiles folder is pre-created. Open the file in File Manager and you'll see a class CustomDifficulty block with dozens of toggles – third-person view, map contents, stamina, weapon sway, AI skill, and so on. Edit the values, save, restart. The BI wiki has a full reference of the keys if you want to go deep.

If you'd rather not customise, set difficulty to "Recruit", "Regular", or "Veteran" in server.cfg and skip the profile file entirely.

Commandline switches

All of these go into Commandline Manager in the panel. LOW.MS pre-populates the basics (-port, -config, -cfg, -profiles) – you mostly add to the list rather than rewrite it.

The two I'd always add are -autoInit and -loadMissionToMemory. -autoInit means a reboot doesn't leave your server sitting in the lobby; -loadMissionToMemory knocks serious time off reconnection for players after a crash or restart.

Ports and ranges

LOW.MS ships Arma 3 on a 2302 + 20 layout:

• 2302 UDP – game port (also VON voice)
• 2303 UDP – Steam query
• 2304 UDP – Steam master
• 2305 UDP – VON (reserved, not currently used)
• 2306 UDP – BattlEye client traffic
• 2312 TCP – BattlEye RCON (LOW.MS convention, game port + 10)

Your actual ports may start at 2322, 2342, and so on, depending on what's free on your node. Check Service Settings in the panel for the exact numbers. The BattlEye RCON rule is always "game port + 10," so if your game port is 2342, RCON is on 2352.

BattlEye and RCON

BattlEye has shipped inside the Arma 3 dedicated server package for years and is enabled by default on LOW.MS. You don't install it separately. What you do need to do, if you want RCON, is edit the BattlEye config files at the server root:

• battleye\beserver.cfg – used with the 32-bit arma3server.exe (rarely used now)
• battleye\beserver_x64.cfg – used with the 64-bit arma3server_x64.exe (what LOW.MS runs)

A minimal beserver_x64.cfg:

RConPassword yourStrongRconPasswordHere
RConPort 2312
RConIP 0.0.0.0
MaxPing 400

Restart the server after saving. A few caveats:

• RConPort must not overlap with your game port range (2302 to 2306 on a fresh layout). Game port + 10 is LOW.MS's convention.
• The password cannot contain spaces, and I'd avoid special characters that your RCON client might mangle.
• There's no RCON UI inside TCAdmin. Use an external client like BattlEye Extended Controls (BEC) or a Python-based RCON tool – you point it at your public IP, the RCON port, and the password.

Two separate command surfaces get conflated here. The in-game admin chat commands (typed in-game once you are logged in with #login) are things like #missions (return to lobby), #shutdown, #restart, #init (reload server.cfg), plus #exec kick "Name" and #exec ban "Name". The BE RCon commands sent from an external tool like BEC are plain kick, ban, players, admins, say – no hash prefix. For richer stuff like scheduled restarts, auto-announce, and advanced bans, BEC is the community standard.

Headless clients

Headless clients are Arma 3 clients that connect without rendering and take on AI simulation, freeing the dedicated server's CPU for network and sim work. On a scenario with 100+ AI, a headless client can be the difference between playable and slideshow.

In server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[]     = {"127.0.0.1"};

If the headless client runs on a different machine, use its public IP rather than 127.0.0.1. Both arrays accept multiple IPs.

Running a headless client on the same node as your Arma 3 server is something we set up case by case – open a support ticket if you want one. The in-depth scripting side (distributing AI groups to the HC, detecting HC presence in mission code) is covered in detail on the BI wiki.

DLC and content

If your mission uses official DLC content (Apex/Tanoa, Contact/Livonia, Global Mobilization, S.O.G. Prairie Fire, CSLA, Western Sahara, Spearhead 1944, Reaction Forces, Expeditionary Forces), the dedicated server SteamCMD install picks those up as long as they're present in the server library. LOW.MS pre-provisions the stock DLC terrains; Creator DLCs from third-party developers (Heavy Ordnance Works for Spearhead, Rotators Collective for Reaction Forces, Tiny Gecko Studios for Expeditionary Forces, and so on) can be added on request.

Players still need to own the DLC themselves to join a server running DLC content, with the usual caveat that terrains are sometimes downloadable free for multiplayer and the weapons/vehicles are the paid-gated part.

When something breaks

If the server refuses to start or won't show up in the browser after a config edit, the cause is almost always one of:

1. A syntax error in server.cfg – missing semicolon, unmatched brace. Check Log Viewer in the panel for the specific line.
2. A mod in -mod= that isn't actually uploaded, or whose .bikey isn't in keys/.
3. verifySignatures = 2; with a mod that has unsigned .pbo files. Either sign them or drop to verifySignatures = 0; (not recommended for public servers).
4. A class Missions entry pointing at a .pbo that isn't in mpmissions/.

Steam Update in the panel reinstalls the server binary without wiping your configs or mods, which fixes more things than it has any right to. If you've still hit a wall, Arma 3: Troubleshooting has the common fixes with logs examples.

Want to spin up an Arma 3 server? Pricing and specs are on low.ms/game-servers/arma-3-server-hosting and you'll be editing server.cfg within a few minutes.