Before you start
Back up server.cfg, missions and mod lists with their versions. Reserve a maintenance window. CubixServ startup explicitly selects /data/server.cfg using -config; uploading a different configuration file does not automatically activate it.
Identify the active configuration
Bohemia documents -config as the option selecting the server configuration file. Edit server.cfg through the service’s files interface, preserving syntax and a recovery copy. Use settings documented for your installed release. Startup options and hosting network rules are separate concerns. Do not replace the launcher merely to reproduce an example command designed for another administrator’s environment.
Prepare missions and rotation
Upload permitted mission files to the server’s mission directory, generally mpmissions. The Missions class references mission templates in the selected configuration. Verify filename case, terrain requirements and dependencies before enabling a rotation. Start with a known simple mission. A mission file that requires an absent terrain or addon will not become usable simply because its name appears in the rotation.
Define a consistent modpack
Keep a mod list consistent with both the mission and clients. Workshop distribution does not guarantee compatibility or make the server load every subscribed item. Startup parameters -mod and -serverMod serve different purposes. Automatic editing of these launch options is not promised for this offer. Confirm the panel’s actual capabilities before designing a complex modpack, and retain the versions required by your previous working mission.
Check signatures without bypassing protection
A .bisign file accompanies signed content; a public .bikey lets the server verify the corresponding signature. verifySignatures controls verification, including mode 2 as documented by Bohemia. Use keys provided by the authors and never share private signing keys. For a rejected connection, compare content versions and matching keys rather than globally disabling checks to hide the immediate symptom.
Measure AI load and understand headless clients
A mission with many AI units, repeated scripts or objects can exhaust processing capacity while RAM remains available. A headless client is another Arma process that can receive selected AI work. headlessClients[] authorises connections; it does not create that process. A suitable mission, separate resources and configuration are required. A headless client is not presented as included or as a universal fix for lag.
Validate before reopening
Check startup, mission loading, signatures and a client connection with the expected modpack in that order. Inspect logs after each step. Test major changes on a copy rather than during a community session. Preserve previous missions and versions for rollback. For persistent problems, send support the mission name, relevant time and useful errors, removing passwords and other secrets from configuration extracts.
For your situation
| Situation | Next check |
|---|---|
| Mission will not load | Check the template, mission files and terrain or mod dependencies. |
| Signature rejected | Compare the content version, .bisign and corresponding public .bikey. |
| Slow AI with free RAM | Measure mission processing before choosing more resources or a separate process. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.