# Arma 3 Server Hosting - everything RE:NODE has published > A Arma 3 server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it. Generated from https://www.renode.space/game-servers/arma-3, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/arma-3. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is Arma 3 dedicated servers with Steam Workshop mod loading, headless clients and Creator DLC support. Bring your own Steam login -- Bohemia does not allow anonymous downloads. - Genres: Action, Simulation, Strategy - Developer: Bohemia Interactive - Released: 12 Sep, 2013 - Steam: https://store.steampowered.com/app/107410/ ### You supply two things yourself Arma 3 is only sold with a credential its publisher issues to a person, so you need to own the game yourself and provide it after checkout. We cannot create it for you and we never share one between customers. Your server is built immediately; the game installation waits until you paste it into the Setup tab, then runs itself. ### What comes with every Arma 3 server - Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other Arma 3 server on the internet. - The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off. - Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine. - 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose. - 5 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them. - People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams. ### Which Arma 3 plan do you need? Memory is what decides whether a server holds together, so start there. The Starter tier gives 4 GB and 1.5 vCPU, which suits a private group. The Advanced tier at 8 GB is where most public servers sit, and Premium at 12 GB exists for the servers that stay full. Storage matters more than people expect once mods and backups are involved - plans here run from 40 GB to 100 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have. If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players. More game servers: https://www.renode.space/ai/game-servers.md ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Where are the servers?** Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-15 02:50 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/arma-3 or in the panel shop at https://panel.renode.space before quoting one. - You supply: Steam username - The Arma 3 dedicated server cannot be downloaded anonymously, so the installer signs in as you. The account does NOT need to own Arma 3 unless you want Workshop mods downloaded automatically. Ideally use one with Steam Guard set to email rather than the mobile app — if Steam does not recognise this machine, there is a field below for the code it emails. Use a separate account kept for servers -- the credentials are stored as you type them so the server can update itself. (https://store.steampowered.com/join/) - You supply: Steam password - The password for the account above. Stored as typed, because SteamCMD is given it again on every update -- which is exactly why it should be a throwaway account and not your main one. (https://store.steampowered.com/join/) - You supply: Steam Guard code - Leave this blank the first time. If Steam does not recognise this account on this machine, it emails a short code to the account's own inbox. Come back, paste it in here, and press Start Setup again quickly — the code expires. | Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports | |---|---|---|---|---|---|---|---| | Starter | $12 | 4 GB | 1.5 vCPU | 40 GB | 1 | 2 | 5 | | Standard | $17 | 6 GB | 2 vCPU | 55 GB | 1 | 2 | 5 | | Advanced | $22 | 8 GB | 2.5 vCPU | 70 GB | 1 | 2 | 5 | | Pro | $28 | 10 GB | 3 vCPU | 85 GB | 1 | 2 | 5 | | Premium | $35 | 12 GB | 3.5 vCPU | 100 GB | 1 | 2 | 5 | ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 3 posts, newest first. Each one follows in full after the list. - [Arma 3 headless clients for AI offloading](https://www.renode.space/blog/arma-3-headless-clients) (2026-10-07): How Arma 3 headless clients work: locality, server.cfg settings, the mission slot, moving AI with setGroupOwner or ACE, several HCs, and proving it helped. - [Arma 3 server.cfg, basic.cfg and missions](https://www.renode.space/blog/arma-3-server-cfg-and-missions) (2026-09-21): Every Arma 3 server.cfg setting worth changing, what basic.cfg really does, mission rotation and difficulty, admin commands, and setting up a headless client. - [Arma 3 dedicated server setup and mods](https://www.renode.space/blog/arma-3-server-and-mods) (2026-08-21): How to install an Arma 3 server, what every server.cfg key does, how mods and signature keys work, and how a headless client buys back server FPS. --- ### Arma 3 headless clients for AI offloading Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/arma-3-headless-clients A headless client (HC) is a second copy of the Arma 3 server binary started with `-client`, which joins your server as an invisible player and runs the AI the mission gives it. It helps only when three things are true: AI is what is eating your server's frame time, the mission puts a headless client slot in the lobby, and something - mission code, ACE's headless component or another script - actually transfers AI groups to it. Get those right and a persistent mission with hundreds of AI holds a playable server FPS deep into a session; get any of them wrong and you have spent memory and a CPU share on a process that sits in a slot doing nothing. The server-side switches (`headlessClients[]`, `localClient[]`) are covered in [the Arma 3 server.cfg guide](https://www.renode.space/blog/arma-3-server-cfg-and-missions). This post is about everything around them: why locality is the whole story, how to put the slot in a mission, the three ways AI gets moved, running more than one HC, and how to prove it worked. #### Locality: why a headless client can help at all Every object in an Arma 3 multiplayer session is **local** to exactly one machine. That machine runs its simulation - for AI, that means pathfinding, target selection, knowledge updates, firing decisions - and broadcasts the results to everyone else. Every other machine holds a remote copy that it draws and interpolates but does not think for. By default, AI placed in the editor or spawned by server scripts is local to the server. So the server's main thread does the thinking for every AI unit in the mission on top of everything else it does, and Arma's simulation is largely single-threaded. When the AI count rises, server FPS falls, and when server FPS falls everything gets worse at once: AI react late, vehicles stutter, players desync. A headless client is just another machine for AI to be local to. It is a full Arma client with no rendering and no sound, so all of its frame time goes to simulating the units it owns. Move a hundred AI to it and those hundred units stop costing the server anything but network updates. ```diagram title: Where AI is simulated with two headless clients players = Players | own their units server = Dedicated server | objectives, scripts hc1 = HC1 | AI groups, east hc2 = HC2 | AI groups, west players <-> server : state updates hc1 <-> server : owns its groups hc2 <-> server : owns its groups ``` Three consequences fall out of this model and explain most HC problems: - **AI does not move by itself.** A unit is local where it was created until something calls `setGroupOwner` on it. Connecting an HC changes nothing about existing AI. - **Locality is per group.** You move whole groups, and the group's units, waypoints and vehicles they drive go with it. - **Scripts run where they run.** Code on the server that commands a unit which has moved to an HC may stop working, because many commands only take effect where the unit is local. #### Is it worth it? Measure before you build A headless client is not free. It is a second Arma process with the same mod list, so it needs its own memory - typically 2 to 4 GB with a moderate mod set - and its own CPU time. If your server's problem is not AI, it gives you nothing. Measure first. Log in as admin and run `#monitor 5`, which prints server FPS and related numbers into chat every five seconds. Then compare: | What you see | What it means | Does an HC help? | | --- | --- | --- | | Server FPS falls as AI count rises, recovers when AI dies | AI is the cost | Yes | | Server FPS falls slowly over hours with stable AI | Script leak or object build-up | No, fix the mission | | Server FPS fine, players complain of lag | Network or client performance | No | | Server FPS bad from the first minute with few AI | Mod or script cost at start | No, profile the mission | | Memory near the limit, FPS fine | Memory, not AI | No, and an HC makes memory worse | The general version of this is in [what tick rate actually means](https://www.renode.space/blog/what-tick-rate-actually-means) and [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers). On a panel with a CPU graph, the tell-tale picture is the server process pinned at its CPU allowance while memory is flat and the mission is spawning AI. #### The server side, briefly Two arrays in `server.cfg` make the server treat the HC properly: server.cfg: ```cfg headlessClients[] = {"127.0.0.1"}; localClient[] = {"127.0.0.1"}; ``` `headlessClients[]` lists the addresses allowed to take headless client slots. `localClient[]` marks addresses as local, which removes the bandwidth limits meant for players on home connections - without it the HC is throttled like a player and AI updates queue up. If the HC runs on another machine, both arrays need that machine's address instead of the loopback. The HC is started with the same binary: ```bash $ ./arma3server_x64 -client -connect=127.0.0.1 -port=2302 \ -password="joinpassword" -profiles=hc1 -name=hc1 \ -mod="@cba_a3;@ace" -world=empty -nosound ``` What each part does: - `-connect` and `-port` point at the server's game port. - `-password` is the **join** password, if the server has one. Not the admin password. - `-mod` must match the server's client mod list exactly. `-serverMod` items are not needed. - `-profiles` and `-name` give the HC its own profile folder and log, so its `.rpt` file does not mix with the server's. The HC connects, appears in the lobby, and takes a headless client slot if the mission has one. If it has none, it sits at the slot screen. #### Putting the slot in the mission This is the step most "my HC does nothing" reports come down to. The mission must contain a headless client entity, and that entity must be playable. In the Eden editor, the headless client is a logic entity named **Headless Client**. Place one per HC you intend to run, and for each: 1. Give it a variable name - `HC1`, `HC2`, `HC3`. Scripts find the HC by this name. 2. Tick **Playable**. A non-playable HC entity is never offered as a slot. 3. Save and export the mission to multiplayer, so the `.pbo` in `mpmissions` contains it. The HC takes the slot automatically when it connects; nobody has to assign it. In scripts, the variable name then refers to the HC's object, and `owner HC1` (evaluated on the server) returns its client ID - the number `setGroupOwner` needs. Large community missions such as Antistasi and Liberation ship with headless client slots already placed. A Workshop mission that does not mention headless clients in its description almost certainly does not. #### Three ways to move AI onto a headless client Once the slot exists, something has to transfer AI. There are three approaches, and they can be mixed. ##### 1. Spawn the AI on the HC in the first place The cleanest approach for missions you write: run the spawning code on the HC itself, so the AI is local there from birth and never transfers. init.sqf: ```text // true only on a headless client if (!hasInterface && !isServer) then { [] execVM "scripts\spawnPatrols.sqf"; }; // fall back to the server if no HC is connected if (isServer && {isNil "HC1" || {isNull HC1}}) then { [] execVM "scripts\spawnPatrols.sqf"; }; ``` `hasInterface` is false on dedicated servers and headless clients; `isServer` is true only on the server. That combination identifies an HC. The fallback matters: a mission that only spawns AI on the HC has no enemies on a night the HC fails to connect. ##### 2. Transfer groups from the server with setGroupOwner For AI placed in the editor or spawned by existing server scripts, transfer it. `setGroupOwner` runs on the server only, takes a group and a client ID, and moves the group and its units. initServer.sqf: ```text [] spawn { // wait until the HC has connected and has a client ID waitUntil { sleep 5; !isNil "HC1" && {!isNull HC1} && {owner HC1 > 2} }; sleep 30; // let mission init finish first private _hc = owner HC1; { private _grp = _x; if (local _grp && {({isPlayer _x} count units _grp) == 0} && {!(_grp getVariable ["keepOnServer", false])}) then { _grp setGroupOwner _hc; }; } forEach allGroups; }; ``` The checks in that loop are the important part. Only transfer groups local to the server, never a group containing a player, and give yourself a way to exclude groups that must stay put - scripted set pieces, units with server-side logic attached. The delay lets other initialisation finish first; transferring a group mid-setup is a classic source of half-configured AI. ##### 3. Let a mod do it **ACE3** includes a headless component that transfers AI groups to connected headless clients automatically and rebalances when HCs join or leave. It is configured from the CBA addon settings: enable it, set a transfer delay, and decide what happens when an HC disconnects. It has a per-group and per-unit exclusion variable for things that must stay on the server; check the ACE documentation for its exact name in your version. For a modded group already running ACE, this is the least effort route and works with editor-placed and Zeus-spawned AI. Older missions use **Werthles' Headless Module**, an editor module that does the same job. Pick one automatic mechanism per mission; two systems moving the same groups fight each other. > [!WARNING] > Units a Zeus curator places are local to the curator's own PC, not the server. On a Zeus-run night that means the curator's machine is simulating the enemy and their frame rate becomes the enemy's frame rate. Automatic HC balancing such as ACE's can pick those groups up; plain `setGroupOwner` loops on the server will not, because the groups are not local to the server. #### What breaks when AI changes owner Moving locality is not invisible to scripts. The common problems: - **Local-effect commands.** Some commands only work where the unit is local. A server loop that calls `doMove`, `disableAI` or `setBehaviour` on a group that has moved to the HC may silently do nothing. Run such code where the group lives, for example with `remoteExec` targeted at `groupOwner`, or run the whole behaviour script on the HC. - **Event handlers.** Handlers added with `addEventHandler` are local to the machine that added them, and several fire only where the unit is local. A server-side `Killed` or `Hit` handler on a transferred unit may stop firing. Use the multiplayer variants (`addMPEventHandler` with `MPKilled`, `MPHit`) or add handlers on the owning machine. - **Settings applied before transfer.** Some AI state set on the server before the move does not survive it. Apply skill, `disableAI` and behaviour after the transfer, on the new owner. - **Dead bodies and cleanup.** Garbage collection still runs on the server. That is fine, but a cleanup script that checks `local` before deleting will skip units owned by the HC. When a mission misbehaves only with an HC connected, these four are the checklist. #### Several headless clients, and dynamic simulation One HC is a second thread. Several HCs are several threads, and missions with very large AI counts distribute groups across HC1, HC2 and HC3 - by area, by side, or round-robin. Each needs its own playable slot, its own process with its own `-profiles` and `-name`, and its own share of memory and CPU. More HCs only help if there are cores to run them on. On your own hardware that is a question of physical cores. On a hosted server, CPU is usually a hard allowance - on RE:NODE each server is one container throttled to the share you bought - so a headless client running inside the same allowance competes with the server for it. It still helps when the server is stuck on one thread with spare allowance unused, which is the common case, but it cannot create CPU that is not in the plan. A second HC in the same allowance rarely beats one. The complement to headless clients is **dynamic simulation**, built into the game since 1.74. It freezes AI groups that are far from any player and wakes them when someone approaches: initServer.sqf: ```text enableDynamicSimulationSystem true; "Group" setDynamicSimulationDistance 1500; { _x enableDynamicSimulation true } forEach allGroups; ``` A frozen group costs almost nothing wherever it is local. On a large terrain with AI garrisons everywhere, dynamic simulation often removes more load than a headless client does, and the two together are the standard setup for big persistent missions. Enable it per group after any transfer. #### Proving it worked Do not trust that it works because the HC is in the lobby. Check three things. 1. **Groups actually moved.** In the debug console with server execution, count groups per owner: `{groupOwner _x == owner HC1} count allGroups`. Zero means nothing transferred. 2. **The HC is coping.** Have the HC log its own frame rate and group count into its `.rpt`: init.sqf: ```text if (!hasInterface && !isServer) then { [] spawn { while {true} do { diag_log format ["HC fps %1, local groups %2", diag_fps, {local _x} count allGroups]; sleep 60; }; }; }; ``` 3. **The server improved.** Run `#monitor 5` at the same point in the mission with and without the HC. If server FPS did not move, the bottleneck was not AI, and the HC can go. An HC whose own FPS has collapsed is now the bottleneck instead of the server: the AI it owns reacts as badly as before. That is the point to split across two HCs, cut AI count, or lean harder on dynamic simulation. Keep the HC's `.rpt` logs alongside the server's; [logs worth keeping](https://www.renode.space/blog/logs-worth-keeping) covers how long and why. #### Troubleshooting **The HC never appears in the lobby.** Its address is not in `headlessClients[]`, the mod list does not match, or it is pointing at the wrong port. Read the HC's own `.rpt` - it states why the connection failed. **The HC sits at slot selection.** The mission has no playable headless client entity, or all HC slots are already taken. **The HC connects but owns nothing.** Nothing transfers AI. Add a `setGroupOwner` loop, enable ACE's headless component, or spawn on the HC. **AI on the HC stands still.** Waypoints or behaviour scripts are running on the server and no longer apply. Move the script to the owner. **Server-side kill tracking broke.** Event handlers are local. Use `MPKilled` or add the handler on the HC. **Everything got worse.** The HC pushed the server towards its memory limit, or it is sharing a CPU allowance that was already full. Check both graphs and remove it if so. **The HC disconnects and the enemies vanish.** When an HC leaves, its AI is handed back to the server. If the server then struggles, that is expected; if the AI is deleted, a script is cleaning up the HC's groups on disconnect. #### FAQ ##### Do I need a separate Arma 3 licence for a headless client? No. The headless client is the free dedicated server binary started in client mode, downloaded the same way as the server. It needs the same mods as the server and nothing else. ##### How many headless clients should I run? One, until you have measured that it is overloaded. Add a second only when the first HC's own FPS drops under load and there is CPU available to run another process. Most groups never need more than one. ##### Will a headless client fix desync? Only if the desync is caused by the server running out of frame time because of AI. Network desync from a player's connection, or a server short of memory, is unaffected. ##### Does the mission have to be written for a headless client? It needs a playable headless client slot. Moving the AI can be done by the mission, by ACE's headless component or by another script, so a mission without HC code can still benefit if you add a slot and an automatic balancer. ##### Can the headless client run on a different machine? Yes. Put that machine's address in `headlessClients[]` and `localClient[]`, open the path between them, and expect some extra latency on AI updates. On the same machine is simpler and usually faster. ##### What happens to AI when the headless client crashes? Its groups transfer back to the server automatically. The mission continues, with the server carrying the load it was carrying before. A good mission or balancer re-transfers them when the HC reconnects. Arma 3 servers on RE:NODE start at 4 GB with five port allocations, full SFTP and file access for missions, profiles and `.rpt` logs, and CPU and memory graphs in the console so you can see whether a headless client actually moved the load. The install waits on the Setup tab for the Steam login that Workshop mods need. [See Arma 3 plans](https://www.renode.space/game-servers/arma-3) --- ### Arma 3 server.cfg, basic.cfg and missions Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/arma-3-server-cfg-and-missions An Arma 3 server is configured by two files with confusingly similar names and one command-line flag each. `server.cfg`, passed with `-config=`, holds everything about the server as a thing people join: its name, its passwords, its admins, its mission rotation, its security settings. `basic.cfg`, passed with `-cfg=`, holds a handful of network tuning values that almost nobody needs to change. Difficulty is in neither of them - it moved into the server profile years ago and that is still the most common reason a setting refuses to stick. This guide goes through both files key by key, then mission rotation, the admin commands, and the headless client, which is the single largest performance gain available to a mission with a lot of AI and also the one most often set up incorrectly. For mod loading, keys and signatures, see [an Arma 3 server and the mod list that will not load](https://www.renode.space/blog/arma-3-server-and-mods). #### Starting the server: the command line and the ports A complete Linux start line looks like this: ```bash $ ./arma3server_x64 -port=2302 \ -config=cfg/server.cfg \ -cfg=cfg/basic.cfg \ -profiles=profiles -name=server \ -mod="@cba_a3;@ace" -serverMod="@server_only" \ -world=empty -autoInit -filePatching ``` The parts that matter: - **`-config=` is server.cfg and `-cfg=` is basic.cfg.** They are the wrong way round from what anyone would guess, and swapping them produces a server that starts, ignores your settings and tells you nothing. - **`-profiles=` and `-name=`** decide where the server profile is written. Everything about difficulty lives in a file under that directory, named after `-name`. - **`-world=empty`** stops the server loading Altis at startup. It saves memory and start-up time and there is no reason not to use it. - **`-mod=`** is the list clients must also have. **`-serverMod=`** is loaded by the server alone, for things like server-side anti-cheat or a logging mod. Putting a server-only mod in `-mod=` forces every player to download it for nothing. - **`-autoInit`** starts the mission without waiting for a player, and needs `persistent = 1` in `server.cfg` to be useful. - **`-filePatching`** allows unpacked mission folders, which pairs with `allowedFilePatching` in the config. Installing the server itself needs a Steam account: the Arma 3 dedicated server and, more importantly, any Workshop mod has to come from an account that owns the game, which anonymous SteamCMD cannot do. On RE:NODE the server is created as soon as payment clears and the install waits on the Setup tab for those credentials, stored as you typed them - so use a spare account rather than your main one. [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers the download side in general. The ports form a block starting at `-port`: | Port | Protocol | Purpose | | --- | --- | --- | | `2302` | UDP | Game traffic and voice | | `2303` | UDP | Steam query, the port the browser talks to | | `2304` | UDP | Steam master | | `2305` | UDP | Reserved for voice | | `2306` | UDP | BattlEye | Changing `-port` moves the whole block, so two servers on one machine want at least 100 ports between them. Arma 3 plans on RE:NODE include five allocations for exactly this reason, and more can be added on the Network tab. If the server runs but nobody can find it, the query port is the first suspect - see [game server ports explained](https://www.renode.space/blog/game-server-ports-explained). #### server.cfg: the settings that matter Identity and access: server.cfg: ```cfg hostname = "Our Arma 3 server"; password = ""; passwordAdmin = "a-long-random-string"; serverCommandPassword = "a-different-long-string"; maxPlayers = 40; admins[] = {"76561198000000000"}; motd[] = {"Rules in the Discord", "Teamkilling is a ban"}; motdInterval = 5; logFile = "server_console.log"; ``` `password` is the join password and is empty for a public server. `passwordAdmin` is what you type after `#login`, and it should be long, because anyone who has it can restart your mission. `serverCommandPassword` is a third, separate password used for server commands issued by a client, and it is what a headless client needs. `admins[]` lists player UIDs that get admin rights without logging in at all, which is the better way to run staff on a server with more than one of them. Security: ```cfg verifySignatures = 2; BattlEye = 1; kickDuplicate = 1; allowedFilePatching = 1; requiredBuild = 0; onUnsignedData = "kick (_this select 0)"; onHackedData = "kick (_this select 0)"; onDifferentData = ""; ``` `verifySignatures = 2` is the setting that makes mod keys matter: every mod a client loads must be signed by a key present in the server's `keys/` folder. It is also the reason half of all "I cannot join" reports exist, and turning it off to make them stop is exactly the wrong fix. `allowedFilePatching` takes `0` for nobody, `1` for headless clients only, and `2` for everyone; `1` is the right answer on a server that uses a headless client and nothing else. Votes: ```cfg voteMissionPlayers = 3; voteThreshold = 0.33; allowedVoteCmds[] = {}; ``` `voteThreshold` above `1` disables voting entirely, which is what most organised groups want. Leaving it at the default on a public server means three people can vote your mission away. Network behaviour: ```cfg disconnectTimeout = 90; maxdesync = 150; maxping = 500; maxpacketloss = 50; kickClientsOnSlowNetwork[] = {0,0,0,0}; ``` The four numbers in `kickClientsOnSlowNetwork` correspond to desync, ping, packet loss and the "unresponsive" check: `0` warns, `1` kicks. Kicking on ping is tempting and usually a mistake, because Arma's ping figure spikes during loading and on a busy frame. Warn first, watch the log for a week, then decide. [Latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) covers telling a genuinely bad connection from a busy one. Persistence and voice: ```cfg persistent = 1; autoInit = 1; timeStampFormat = "short"; disableVoN = 0; vonCodecQuality = 30; vonCodec = 1; ``` `persistent = 1` keeps the mission running when the last player leaves, which is what a campaign server needs and what a scrim server does not. `autoInit = 1` starts the first mission at boot rather than waiting for somebody to connect, and it does nothing at all without `persistent`. #### Difficulty moved out of server.cfg Since Arma 3 1.58, difficulty is not configured in `server.cfg`. The config only names a preset per mission: `Recruit`, `Regular`, `Veteran` or `Custom`. The actual settings live in the server profile, a `.Arma3Profile` file written under the `-profiles` directory in a folder named after `-name`. server.Arma3Profile: ```cfg class DifficultyPresets { class CustomDifficulty { class Options { reducedDamage = 0; groupIndicators = 0; friendlyTags = 0; enemyTags = 0; detectedMines = 0; commands = 1; waypoints = 1; weaponInfo = 2; stanceIndicator = 1; staminaBar = 1; weaponCrosshair = 0; visionAid = 0; thirdPersonView = 0; cameraShake = 1; scoreTable = 1; deathMessages = 0; vonID = 1; mapContent = 0; autoReport = 0; multipleSaves = 0; }; aiLevelPreset = 3; }; class CustomAILevel { skillAI = 0.5; precisionAI = 0.3; }; }; ``` Two traps. The file does not exist until the server has run once with `-name=`, so there is nothing to edit on a fresh install until after the first start. And the server rewrites the profile on a clean shutdown, so an edit made to a running server is discarded the moment you stop it properly. Stop first, edit, then start. `aiLevelPreset = 3` selects the custom AI level defined below it. `precisionAI` is the one worth lowering: at high values the AI shoots with a consistency that no human match can survive, and most complaints about Arma being unfair are a precision value nobody turned down. #### Missions, rotation and persistence Missions are `.pbo` files in `mpmissions/`, named `missionName.worldName`. The rotation is declared at the end of `server.cfg`: server.cfg: ```cfg class Missions { class Mission_01 { template = "co40_liberation.Altis"; difficulty = "Custom"; class Params {}; }; class Mission_02 { template = "tvt30_assault.Malden"; difficulty = "Veteran"; }; }; missionWhitelist[] = {"co40_liberation.Altis", "tvt30_assault.Malden"}; ``` `template` is the pbo filename without the extension, including the world - `co40_liberation.Altis`, not `co40_liberation`. Getting that wrong is the reason a mission does not appear in the list. The server plays the classes in order and loops back to the first when the last ends. `class Params` sets the mission parameters that the mission itself defines - time of day, respawn rules, AI count. The names come from the mission's own `description.ext`, so they differ for every mission and an invalid one is ignored rather than reported. The mission whitelist restricts what can be selected or voted, which matters on a server where anyone can be voted admin. For a persistent campaign, one mission plus `persistent = 1` and `autoInit = 1` is the whole rotation: the server starts the mission at boot, holds it while nobody is on, and keeps going. For a session-based group, leave `persistent` off so the mission ends cleanly when everyone leaves, and use `#missions` to pick the next one. > [!NOTE] > Arma has no automatic save for multiplayer missions. Persistence across a restart is something the mission implements itself, usually into profile namespace or a database, and nothing in `server.cfg` provides it. If your campaign mission does not say it saves, it does not. #### basic.cfg and the myth of network tuning `basic.cfg` is where the internet's Arma advice goes to die. A typical file: basic.cfg: ```cfg MaxMsgSend = 128; MaxSizeGuaranteed = 512; MaxSizeNonguaranteed = 256; MinBandwidth = 131072; MaxBandwidth = 2097152000; MinErrorToSend = 0.001; MinErrorToSendNear = 0.01; MaxCustomFileSize = 0; class sockets { maxPacketSize = 1400; }; ``` Here is the uncomfortable version. The defaults are correct for nearly every server, the values circulating in forum posts were tuned for a specific machine on a specific connection in about 2014, and pasting somebody else's file is as likely to hurt as help. The two worth touching: - **`MaxCustomFileSize = 0`** blocks custom player faces and sound files. On a public server this is a straightforward win: it removes a category of nuisance content and a small attack surface. - **`MaxMsgSend`** controls how many messages the server sends per simulation cycle. Raising it can reduce desync when the server has CPU headroom, and makes things worse when it does not, because the messages queue instead. Change it by one step, run `#monitor` for a session, and write down what happened. `maxPacketSize` is the one to leave alone unless you know the path MTU, which on a hosted server you do not control. #### Admin commands Log in from the in-game chat with `#login `, or be listed in `admins[]` and skip it. | Command | What it does | | --- | --- | | `#login ` | Become admin, `#logout` to stop | | `#missions` | Opens the mission selection screen | | `#restart` | Restarts the current mission | | `#reassign` | Restarts and sends everyone back to slot selection | | `#shutdown` | Stops the server process | | `#kick ` | Disconnects a player | | `#exec ban ` | Bans, writing to the ban list | | `#lock`, `#unlock` | Stops and allows new connections | | `#userlist` | Prints connected players and their UIDs | | `#monitor ` | Prints server FPS and object counts, `0` to stop | | `#vote admin ` | Players vote someone admin, if allowed | `#monitor 5` is the most useful thing in that list. It prints the server's frame rate into chat every five seconds, and server FPS is the number that decides whether a mission plays well. A healthy server sits near its cap. Below about 20 the AI starts to behave visibly badly - slow reactions, late pathing, groups that stand still. Below 10 nothing works and no network setting will save it. That number falls as AI count rises, which is what the headless client is for. The general version of this argument is in [what tick rate actually means](https://www.renode.space/blog/what-tick-rate-actually-means). There is also BattlEye's own RCon, configured in `BEServer_x64.cfg` in the BattlEye folder with `RConPassword` and `RConPort`. It is what external admin tools connect to, and its protocol is not encrypted, so treat the port as local-only and the password as a secret that should never be reused. [RCON safely](https://www.renode.space/blog/rcon-safely) covers the general case. #### Headless clients Arma's simulation is largely single-threaded, and on a long mission it is the AI that eventually saturates that thread. A headless client is a second Arma process that connects to the server as a client with no graphics, takes ownership of AI groups the mission hands it, and simulates them on its own thread. On a mission built for it, moving fifty AI groups off the server can be the difference between an hour-three firefight that plays and one that crawls. The server side is three things: server.cfg: ```cfg headlessClients[] = {"127.0.0.1"}; localClient[] = {"127.0.0.1"}; serverCommandPassword = "a-different-long-string"; ``` `headlessClients[]` tells the server which addresses are allowed to connect as headless. `localClient[]` marks them as local, which exempts them from the bandwidth limits meant for players on domestic connections - without it the headless client is throttled like a player and does not help. Both take the loopback address when the headless client runs on the same machine, which it should. The client side is the same binary with `-client`: ```bash $ ./arma3server_x64 -client -connect=127.0.0.1 -port=2302 \ -password="" -mod="@cba_a3;@ace" \ -profiles=profiles -name=HC -world=empty ``` The mod list must match the server's exactly. The password is the server's join password, not the admin one. And then the part most guides skip: **the mission has to support it.** A headless client does nothing unless the mission contains a headless client slot and code that transfers AI groups to it once it connects. Frameworks aimed at long missions generally do; a mission from the workshop with no mention of it in the description generally does not, and running a headless client against one costs you memory and gains you nothing. Two honest caveats for hosted servers. A headless client is a second Arma process, so it wants its own core and a couple of gigabytes of memory. On a plan with a hard CPU limit - one container per server, throttled to the share you bought - the headless client draws from the same allowance, so it only helps if there is genuinely unused CPU inside your limit rather than unused cores on the machine. And if the headless client is refused at connection, check `headlessClients[]` first and the mod list second; those two account for nearly every case. [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) is worth reading before deciding which limit you are actually hitting. #### Troubleshooting **The server does not appear in the browser.** The Steam query port, `-port` plus one, is closed or in use. Joining by IP works while the browser does not, which is the quick way to confirm it. **My server.cfg changes do nothing.** `-config=` and `-cfg=` are the wrong way round, or the path is wrong and the server is running on defaults. The startup log names the file it loaded. **Difficulty settings keep reverting.** You edited the profile while the server was running and it was rewritten on shutdown. Stop the server, edit, start. **The mission is not in the list.** The `template` value is missing the world name, the pbo is not in `mpmissions/`, or `missionWhitelist[]` excludes it. **Players get "session lost" at the loading screen.** A mod or signature mismatch. With `verifySignatures = 2` the key must be in `keys/`, and the client must have the same mod version, not just the same mod. **Mods load on Windows and not on Linux.** Linux is case sensitive and Arma mod folders and pbo names are frequently mixed case. Lowercase the mod folder and its contents, or use a downloader that does it for you. **Everything is fine for two hours and then it crawls.** AI count. Run `#monitor 5`, watch the server FPS fall, and either cut the AI the mission spawns or set up a headless client. **`autoInit` is not starting the mission.** It needs `persistent = 1`. A weekly scheduled restart is still worth having on a persistent server - see [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help). #### FAQ ##### What is the difference between -config and -cfg in Arma 3? `-config=` loads `server.cfg`, which holds the server name, passwords, admins, security settings and mission rotation. `-cfg=` loads `basic.cfg`, which holds network tuning. The naming is counter-intuitive and swapping them silently gives you a default server. ##### Where do I set Arma 3 server difficulty? In the server profile, not `server.cfg`. The config only names a preset per mission; the values behind `Custom` live in a `.Arma3Profile` file under the `-profiles` directory. Edit it with the server stopped, or it will be overwritten. ##### How many players can an Arma 3 server hold? `maxPlayers` sets the cap, but the real limit is the mission's slot count and the CPU. Sixty players on a well-built mission is routine; the same server dies at thirty if the mission spawns several hundred AI, because AI is what consumes the frame time. ##### Do I need a headless client? Only if your mission supports one and AI is your bottleneck. Run `#monitor 5` during a bad moment: if server FPS is falling while CPU is pinned and the mission has a lot of AI, a headless client helps. If the mission has no headless slot, it does nothing. ##### Which ports does an Arma 3 server need? UDP `2302` for the game, `2303` for the Steam query, `2304` for the Steam master, `2305` reserved for voice and `2306` for BattlEye. They move as a block if you change `-port`. ##### Can I change basic.cfg to fix desync? Rarely. Desync in Arma is almost always the server running out of frame time, not the network running out of bandwidth. Fix the AI count first, measure with `#monitor`, and only then adjust `MaxMsgSend` by one step at a time. Arma 3 servers on RE:NODE start at 4 GB with five port allocations, so the whole `2302` to `2306` block is yours, plus full file and console access for `server.cfg`, the profile and the mod folders. The install waits on the Setup tab for your Steam login, which is what Workshop mods need. [See Arma 3 plans](https://www.renode.space/game-servers/arma-3) --- ### Arma 3 dedicated server setup and mods Published 2026-08-21, updated 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/arma-3-server-and-mods Arma 3 is a single-threaded simulation with a very long list of things to simulate, so the number that decides how it feels is clock speed, not core count. A sixteen-core machine at a modest frequency will lose to four fast cores every time, and no amount of memory changes that. The rest of the job is three files - `server.cfg`, `basic.cfg` and a profile - a mod list that every client must match exactly, and five UDP ports. This guide covers all of it: installing the server, every setting worth changing, how signature verification decides who can join, and the headless client, which is the single largest performance improvement available and the one most guides wave at. #### What an Arma 3 server is, and what decides how it feels The dedicated server is a free, separate application: **Arma 3 Dedicated Server**, Steam app id `233780`, downloadable with an anonymous SteamCMD login. It runs without graphics or sound, loads a mission, and simulates everything in it - terrain objects, physics, ballistics, and above all AI. Server performance is measured in server FPS, which you read with `#monitor 1` in chat as a logged-in admin. Above 30 is healthy, 20 is the point where AI starts making bad decisions, and below 15 a firefight becomes a slideshow of units teleporting into cover. What drives that number, in order: 1. **AI count.** Every AI unit costs pathfinding, targeting and knowledge updates every frame. Two hundred AI on a large terrain will halve your server FPS before a single player connects. 2. **Scripting.** A mission running heavy loops in unscheduled code blocks the same thread the simulation uses. The mission, not the host, is usually the reason a server degrades at hour three. 3. **Objects and physics.** Destroyed vehicles, dropped weapon holders and ragdolls accumulate. A mission that never cleans up is a mission that gets slower. 4. **Players.** Surprisingly far down the list. Players are cheap next to AI. Memory is rarely the constraint on vanilla and always the constraint on heavily modded servers, because mods load their content into the process whether the mission uses it or not. #### Requirements and resource usage | Setup | RAM | CPU | Disk | | --- | --- | --- | --- | | Vanilla, 20-30 players, light AI | 3-4 GB | 2 fast cores | 40 GB | | CBA plus ACE, one mission, 40 players | 6 GB | 2-3 fast cores | 55 GB | | Full pack: CBA, ACE, RHS, CUP Terrains | 8-12 GB | 3+ fast cores | 80-100 GB | | Headless client alongside the server | add 2-4 GB | add 1-2 cores | none | - **Disk is the surprise.** The base server is around 20 GB. CUP Terrains complete and RHS together are larger than the game. A group that adds a couple of map packs mid-campaign can run a plan out of disk in an afternoon, and Arma does not fail gracefully when it cannot write. - **CPU share matters more than core count.** If your host throttles you to a fraction of a core, Arma will feel exactly as bad as that sounds. See [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) for reading which one you are actually short of. - **Bandwidth** runs roughly 100-300 KB/s per player on a busy mission, higher with many AI in view. That is not much, but Arma is sensitive to jitter in a way most games are not - [latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) covers telling the three apart. #### Installing the server with SteamCMD The server itself needs no account: ```bash $ steamcmd +force_install_dir /home/arma/server +login anonymous \ +app_update 233780 validate +quit ``` Workshop mods are a different matter. They belong to the game, app id `107410`, and downloading them requires a Steam account that owns Arma 3: ```bash $ steamcmd +force_install_dir /home/arma/server +login your_account \ +workshop_download_item 107410 +quit ``` Downloaded items land in `steamapps/workshop/content/107410//`. Copy or symlink each one to a folder named `@ModName` in the server root. On RE:NODE the Arma 3 install asks for a Steam login on the Setup tab for this reason, and the credentials are stored as you type them - use a spare account that owns the game, not your main one. A working Linux start line looks like this: ```bash $ ./arma3server_x64 -port=2302 -config=server.cfg -cfg=basic.cfg \ -profiles=./profiles -name=server -world=empty -autoInit \ -bandwidthAlg=2 \ -mod="@CBA_A3;@ace;@RHSAFRF" -serverMod="@ServerTools" ``` | Argument | What it does | | --- | --- | | `-port=2302` | Game port. The query port is always this plus one | | `-config=` | The `server.cfg` described below | | `-cfg=` | The `basic.cfg` network file | | `-profiles=` | Where the difficulty profile and logs are written | | `-name=` | Which profile inside that directory to use | | `-world=empty` | Skip loading a terrain at startup. Faster, lighter | | `-autoInit` | Start the first mission without waiting for a player | | `-mod=` | Mods every client must also load | | `-serverMod=` | Mods only the server loads | | `-bandwidthAlg=2` | The newer bandwidth estimator. Worth having on | | `-filePatching` | Allow loading unpacked files. Off unless you need it | Always use `arma3server_x64`, never the 32-bit `arma3server`. The 32-bit binary still exists, still starts, and will run out of address space the moment you add a mod list. #### server.cfg: the settings that matter `server.cfg` is a plain text file in the server root, in Arma's own config syntax - semicolons after every statement, arrays declared with `[]`. server.cfg: ```cfg hostname = "Longship Crew - ACE"; password = ""; passwordAdmin = "change-me"; serverCommandPassword = "also-change-me"; maxPlayers = 40; motd[] = {"Rules in the Discord.", "TFAR on channel 1."}; motdInterval = 20; admins[] = {"76561198012345678"}; logFile = "server_console.log"; verifySignatures = 2; BattlEye = 1; kickDuplicate = 1; allowedFilePatching = 0; persistent = 1; timeStampFormat = "short"; disconnectTimeout = 90; steamProtocolMaxDataSize = 1024; voteMissionPlayers = 3; voteThreshold = 0.33; onUnsignedData = "kick (_this select 0)"; onHackedData = "kick (_this select 0)"; headlessClients[] = {"127.0.0.1"}; localClient[] = {"127.0.0.1"}; class Missions { class Liberation { template = "Liberation.Altis"; difficulty = "custom"; }; }; ``` The ones that decide whether the server works at all: - **`passwordAdmin`** is what `#login` takes. **`serverCommandPassword`** is separate and grants only the `#` commands, which is what you give a trusted moderator who should not be able to shut the server down. **`password`** is the join password and is usually empty. - **`admins[]`** lists SteamID64s that get admin without typing a password. Safer than sharing `passwordAdmin` with six people. - **`verifySignatures = 2`** refuses any addon that is not signed with a key the server holds. This is what keeps modified PBOs off your server, and it is also the number one cause of "I cannot join" - covered below. - **`persistent = 1`** keeps the mission running when the last player leaves. With `-autoInit` it also starts the mission at boot. Without it, your campaign resets every time the server empties. - **`steamProtocolMaxDataSize = 1024`** raises the size of the server's Steam response so the Arma launcher can actually show a long mod list. Leave it at the default with thirty mods and players get an incomplete list and a failed join. - **`class Missions`** is the rotation. `template` is the mission folder or `.pbo` name including the terrain suffix, exactly as it appears in `mpmissions`. A typo here means the server sits in the lobby with nothing selected. `difficulty = "custom"` points at the difficulty settings in your profile file, which lives under the `-profiles` directory in a folder named after `-name`. That file is where third person, crosshairs, the map marker and AI skill live. Edit it with the server stopped; the server writes it back on exit. > [!TIP] > `kickClientsOnSlowNetwork[] = {0,0,0,0};` and the `maxPing`, `maxDesync` and `maxPacketLoss` values look like a way to keep laggy players out. In practice they kick people during a routine loading spike. Leave the kicking off and deal with a genuinely bad client individually. #### Ports and connecting | Port | Protocol | Purpose | | --- | --- | --- | | `2302` | UDP | Game traffic | | `2303` | UDP | Steam query. The browser and launcher talk to this | | `2304` | UDP | Steam master, server reporting | | `2305` | UDP | Reserved by the port block | | `2306` | UDP | BattlEye | The rule is that Arma claims `-port` through `-port + 4`, all UDP, and shifting the game port shifts the whole block. That is why the RE:NODE Arma 3 plans come with five allocations rather than one - anything less and either the browser or BattlEye silently fails. If you need more, the Network tab adds and removes ports. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) goes into why a query port exists separately at all. Players join through the in-game server browser, through the Arma 3 Launcher's direct connect, or by adding the address to their Steam favourites. The launcher is the one to point people at, because it can load the server's mod list in one click - provided `steamProtocolMaxDataSize` is set. #### Mods, keys and signature verification A mod is a folder starting with `@` containing an `addons` directory of `.pbo` files and usually a `keys` directory holding one `.bikey`. Two rules cover almost every join failure: 1. **Every `.bikey` from every mod in `-mod=` must be copied into the server's root `keys/` folder.** With `verifySignatures = 2` and a missing key, the client is rejected with a message about an unsigned addon that names a file rather than the mod. 2. **The client's mod list must match the server's `-mod=` list**, same mods, same versions. `-serverMod=` mods are the exception - they load only on the server and clients neither need nor see them. Server-side admin tools, logging and performance mods belong there. Load order is yours and it matters. CBA_A3 loads before anything that depends on it; ACE after CBA; map mods before mods that patch those maps. Arma resolves most dependencies by itself, but a mod that patches another and loads first simply does not apply. On Linux there is one more trap that costs people an evening: **case sensitivity**. Workshop content ships with mixed-case folder and file names, and the Linux server will not find `Addons/ACE_Main.pbo` when the config asks for `addons/ace_main.pbo`. Lowercase everything after every download: ```bash $ find ./@ace -depth -name '*[A-Z]*' -execdir bash -c 'mv "$0" "${0,,}"' {} \; ``` Three habits keep a mod list stable. Pin versions: a mod that auto-updates mid-campaign ends the campaign, and Arma's workshop has no version pinning of its own, so pinning means not re-downloading. Publish the list somewhere players can copy from, ideally a launcher preset file, rather than describing it in a message. And when something does break, [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is a shorter path than rebuilding the list from scratch. Creator DLC is worth a note: a server can run a CDLC terrain, and players who do not own it can still join, with the owned content restricted for them. Whether that works for your mission depends on what the mission uses. #### basic.cfg and the settings people copy without measuring `basic.cfg` holds network tuning. These are the documented defaults: basic.cfg: ```cfg MaxMsgSend = 128; MaxSizeGuaranteed = 512; MaxSizeNonguaranteed = 256; MinBandwidth = 131072; MaxBandwidth = 2147483647; MinErrorToSend = 0.001; MinErrorToSendNear = 0.01; MaxCustomFileSize = 0; class sockets { maxPacketSize = 1400; }; ``` `MaxMsgSend` is the number of messages the server sends per simulation cycle and is the one with a real effect: raising it to 256 on a populated server with good CPU headroom reduces desync, and raising it on a server that is already CPU-starved makes things worse, because the messages have to be built on the same thread that is already late. `MinErrorToSend` and `MinErrorToSendNear` control how much an object must have changed before an update is sent - lowering them smooths distant movement at the cost of bandwidth and CPU. The honest position on this file is that it is the most copied and least measured configuration in Arma. Change one value, play a session with `#monitor 1` running, and write down the numbers. If you cannot see a difference in server FPS or reported desync, put it back. #### The headless client AI is what eats the frame time on a long mission, and the headless client is how you move that work off the server process. It is a second copy of the same binary that connects to the server as a player with no screen, and the mission hands it ownership of AI groups. On a machine with cores to spare it is the difference between an hour-three firefight that plays and one that crawls. ```bash $ ./arma3server_x64 -client -connect=127.0.0.1 -port=2302 \ -profiles=./hc -name=hc -nosound \ -mod="@CBA_A3;@ace;@RHSAFRF" ``` ```diagram title: Where the AI runs with a headless client players = Players | up to 40 clients server = Arma 3 server | UDP 2302 hc = Headless client | same machine ai = Offloaded AI | groups it owns players -> server : UDP 2302 hc -> server : joins as a client server -> hc : hands over groups hc -> ai ``` Three conditions, all of which have to hold: - `headlessClients[] = {"127.0.0.1"};` and `localClient[] = {"127.0.0.1"};` in `server.cfg`, so the server grants it headless status and unrestricted bandwidth. - The same mod list as the server, loaded with `-mod=`. - **A mission written for it.** This is the part most guides skip. Unless the mission explicitly transfers AI groups to the headless client, connecting one changes nothing at all except your player count. Liberation, Antistasi and most large persistent missions support it; a mission you wrote last week does not until you add the handover. It also costs a slot and its own memory, so on a small plan a headless client can make things worse by pushing the whole thing towards its memory limit. Give it its own 2-4 GB before you count it as a win. #### Admin commands and mission control Log in from chat with `#login `, then: | Command | What it does | | --- | --- | | `#login ` | Become admin | | `#logout` | Give up admin | | `#missions` | Return to the mission selection screen | | `#mission ` | Load a specific mission | | `#restart` | Restart the current mission | | `#reassign` | Restart and send everyone back to slot selection | | `#monitor 1` | Print server FPS and CPS in chat every second | | `#userlist` | List connected players | | `#kick ` | Disconnect a player | | `#lock` / `#unlock` | Stop and allow new connections | | `#shutdown` | Stop the server | | `#exec ban ` | Ban a player | `#monitor 1` is the diagnostic that matters. It prints server FPS and CPS (condition evaluations per second); watch it across a session and you will see exactly when a mission starts losing. `#monitor 0` turns it off again. For anything you want to keep, the server log named by `logFile` is the record - [logs worth keeping](https://www.renode.space/blog/logs-worth-keeping) covers which lines are worth retaining and for how long. #### Troubleshooting **"You cannot play/edit this mission; it is dependent on downloadable content."** The client is missing a mod the mission needs, or has it at a different version. The error names the addon, not the mod, so search the addon name. **Kicked immediately with a signature error.** A `.bikey` is missing from the server's `keys/` folder, or the client has a modified PBO. Add the key; if it persists for one player only, they have a broken download and should verify their mod. **The launcher shows only part of the mod list.** `steamProtocolMaxDataSize` is too small. Set it to `1024`. **The server is in the browser but nobody can connect.** Check that the whole UDP block from `-port` to `-port + 4` is open, not just the game port. **Server FPS collapses an hour into every mission.** Almost always the mission, not the host: uncleaned wrecks, bodies and dropped items, or a script loop. Turn on `#monitor 1` and watch when it drops. If it correlates with an event in the mission, it is the mission. **The mission resets whenever the last player leaves.** `persistent = 1` is missing. **Mods load on Windows and not on Linux.** Case. Lowercase the mod folders and their contents. **The server stops without a crash log.** Memory. On RE:NODE a container that reaches its limit is stopped and restarted clean rather than left to swap, which looks exactly like this from inside the game; check the memory graph across the session before you look for an engine bug. #### FAQ ##### How much RAM does an Arma 3 server need? Three to four gigabytes for vanilla with thirty players, six with CBA and ACE, and eight to twelve for a full RHS and CUP pack. Mods are loaded whether or not the mission uses them, so the mod list sets the floor and the mission sets how far above it you go. ##### Does a faster CPU really matter more than more cores? Yes. The simulation runs on one thread and cannot be split, so a higher clock directly raises server FPS while extra cores mostly sit idle. The exception is a headless client, which is a genuine second process and does use another core. ##### Why can some players join and others cannot? Their mod list does not match. Same mods is not enough - the versions have to match too, which is why a mod that auto-updated for half your group breaks the other half. Distribute a launcher preset rather than a list of names. ##### Do clients need the mods loaded with -serverMod? No, and that is the point of the argument. Server-side logging, admin and performance mods go in `-serverMod=` so they never appear in the list a player has to match. ##### Can I run two Arma 3 servers on one machine? Yes, if each gets its own five-port block and its own `-profiles` directory. Use `-port=2302` and `-port=2312` rather than adjacent numbers, so the blocks cannot overlap, and remember each server holds its own copy of the mod list in memory. ##### Is a headless client worth setting up for a small group? Only if your mission supports it and you are already short of server FPS. On a twelve-player co-op with sixty AI, the server handles it. On a persistent mission with hundreds of AI, it is the largest single improvement available and nothing else comes close. Arma 3 servers on RE:NODE start from 4 GB and $12 a month with five port allocations already assigned, so the game, query, master and BattlEye ports all work without a ticket. Full file manager and SFTP access means the mod folders, `keys/` and `server.cfg` are yours to edit, and the unfiltered console shows the startup log while it loads. [See Arma 3 plans](https://www.renode.space/game-servers/arma-3) ## Rules for the assistant - Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead. - Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository. - An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port. - On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker. - Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak. - Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository. - Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current. - For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one. - If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.