← Blog

Configurer un serveur DayZ : guide complet 2026

Par Benjamin D. · PDG

· Mis à jour le September 8, 2026 · Lecture 9 min

Contents

Le fichier DayZ serverDZ.cfg is the entry point of every dedicated instance: it defines slots, admin password, day/night acceleration, network ranges and logging. Around it live the mission folder, the central economy XML files and the mod loading parameters. This guide walks through each layer, with real directives, real file paths and the startup line that ties everything together.



How a DayZ instance really boots: files, mission and DayZ serverDZ.cfg

A DayZ instance is not a single executable reading a single file. It is a binary launched with parameters, which loads a configuration file, which points to a mission folder, which itself loads dozens of XML files describing loot, events, weather and spawn points. Understanding that chain saves hours of blind editing.

A typical Linux directory layout looks like this:

DayZServer/
├── DayZServer                 # binary
├── serverDZ.cfg               # main configuration file
├── battleye/                  # BEServer_x64.cfg, bans, RCON
├── keys/                      # .bikey files of every loaded mod
├── profiles/                  # logs, ADM/RPT files, BattlEye output
├── mpmissions/
│   └── dayzOffline.chernarusplus/
│       ├── init.c
│       ├── cfgeconomycore.xml
│       ├── cfgspawnabletypes.xml
│       ├── cfgeventspawns.xml
│       ├── cfgplayerspawnpoints.xml
│       ├── cfggameplay.json
│       ├── db/
│       │   ├── types.xml
│       │   ├── events.xml
│       │   ├── globals.xml
│       │   ├── economy.xml
│       │   └── messages.xml
│       └── storage_1/         # persistence data
└── @ModName/                  # one folder per mod

The launch parameters decide which configuration file is read, which profile directory receives logs, and which mods are mounted. Everything else flows from there. If you are looking for a ready-to-run instance with a Pterodactyl console, automatic backups and anti-DDoS filtering already in place, our DayZ server hosting gives you the same file tree exposed in a web file manager, so every path shown below applies exactly as written.

On a machine you administer yourself, remember that DayZ is heavily single-thread bound: high-frequency Ryzen cores and NVMe storage make a visible difference on server FPS once fifty players and thousands of persistent objects are loaded. You can review the full catalogue on All our game servers if you also run Arma-family instances alongside.



Editing DayZ serverDZ.cfg parameter by parameter

The file uses a C-like syntax: key = value;, strings in double quotes, and a nested class Missions block at the end. A missing semicolon or an unmatched brace makes the whole file unreadable and the process falls back to defaults — always check the RPT file in profiles/ after an edit.

A working baseline

password = "";                          // join password, empty = public
passwordAdmin = "LongRandomString42!";  // admin password, never reuse it
enableWhitelist = 0;                    // 1 = whitelist.txt in profiles/

maxPlayers = 60;
instanceId = 1;
steamQueryPort = 2305;

verifySignatures = 2;                   // enforce signed mods
forceSameBuild = 1;                     // clients must match the build
allowFilePatching = 0;                  // block unsigned client files

disableVoN = 0;
vonCodecQuality = 20;
disable3rdPerson = 0;                   // 1 = first person only
disableCrosshair = 0;

serverTime = "SystemTime";
serverTimeAcceleration = 12;            // 12 = 2h in-game per real hour
serverNightTimeAcceleration = 4;
serverTimePersistent = 0;

guaranteedUpdates = 1;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;
respawnTime = 5;
storageAutoFix = 1;

timeStampFormat = "Short";
logAverageFps = 60;
logMemory = 60;
logPlayers = 60;
logFile = "server_console.log";
adminLogPlayerHitsOnly = 0;
adminLogPlacement = 1;
adminLogBuildActions = 1;
adminLogPlayerList = 1;

enableCfgGameplayFile = 1;              // enables cfggameplay.json
simulatedPlayersBatch = 20;
multithreadedReplication = 1;
speedhackDetection = 1;

networkRangeClose = 20;
networkRangeNear = 150;
networkRangeFar = 1000;
networkRangeDistantEffect = 4000;
defaultVisibility = 1375;
defaultObjectViewDistance = 1375;

class Missions
{
    class DayZ
    {
        template = "dayzOffline.chernarusplus";
    };
};

The very first directive of the file, above everything else, is the public name displayed in the in-game browser. Keep it under 60 characters, avoid emoji-heavy strings, and put the ruleset (loot multiplier, PvE zones, first person) in it so filters return you correctly.

Parameters that actually change gameplay

DirectiveEffectPractical advice
serverTimeAccelerationMultiplies the passage of in-game time (1 to 64)8–12 for a balanced day cycle; pair with night acceleration
serverNightTimeAccelerationExtra multiplier applied only at night4–8 keeps nights short without removing them
serverTimePersistentTime survives a restartSet to 1 only if you like unpredictable cycles
disable3rdPersonForces first personHardcore communities set 1; changes PvP balance drastically
verifySignaturesRejects unsigned or mismatched modsAlways 2 on a modded instance
networkRangeFarDistance at which objects stop being replicatedLowering it reduces bandwidth and CPU load on full instances
simulatedPlayersBatchPlayers simulated per network frameRaise carefully on high-frequency cores, watch server FPS

Message of the day and scheduled warnings

motd[] = { "Welcome to the coast", "Restart every 4 hours" };
motdInterval = 600;

For restart countdowns broadcast in chat, use db/messages.xml inside the mission folder instead; it is driven by the central economy scheduler and is far more precise than a motd loop.



Tuning the loot economy inside mpmissions

Loot in DayZ is not random sprinkling. The central economy (CE) maintains a live count of every item on the map, refills it according to nominal values, and destroys items when their lifetime expires. All of this lives under mpmissions/<mission>/.

Which file does what

  • db/types.xml — quantity, lifetime, restock, category, usage and tiers for every item.
  • db/events.xml — dynamic events: vehicles, helicopter crashes, infected hordes, animals.
  • cfgeventspawns.xml — exact coordinates where those events may appear.
  • cfgspawnabletypes.xml — attachments and cargo spawned inside or on an item.
  • cfglimitsdefinition.xml / cfglimitsdefinitionuser.xml — the vocabulary of usages, tiers and value groups.
  • db/globals.xml — global switches such as cleanup timers and zombie limits.
  • db/economy.xml — enables or disables entire subsystems on load.
  • cfgplayerspawnpoints.xml — fresh spawn and respawn locations.
  • cfggameplay.json — stamina, base building rules, shock damage, active only if enableCfgGameplayFile = 1.

Anatomy of a types.xml entry

<type name="AKM">
    <nominal>12</nominal>
    <lifetime>7200</lifetime>
    <restock>1800</restock>
    <min>6</min>
    <quantmin>-1</quantmin>
    <quantmax>-1</quantmax>
    <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1"
           count_in_player="0" crafted="0" deloot="0"/>
    <category name="weapons"/>
    <usage name="Military"/>
    <value name="Tier3"/>
    <value name="Tier4"/>
</type>

Read it this way: the CE tries to keep nominal instances alive on the map, never dropping below min before triggering a refill after restock seconds. lifetime is how long a dropped instance survives untouched. usage and value restrict spawning to matching building categories and map tiers — a Tier4 item will not appear in a coastal village.

Common adjustments that work

  • Higher loot density: raise nominal and min proportionally. Raising only nominal without min produces long empty stretches.
  • Rarer weapons: lower nominal to 1–2 and set restock high (3600+). Keep min at 0 if you want genuine scarcity.
  • Faster cleanup: cut lifetime on low-value items (rags, cans) to reduce the persistent object count and keep server FPS stable.
  • Disable an item completely: set nominal and min to 0 rather than deleting the entry, which can break references.

Applying changes without breaking persistence

XML edits are read at boot. Restart the instance after every change, then open profiles/ and look for CE errors in the RPT file — an unclosed tag or an unknown class name will silently drop an entire file. Existing persistent items are unaffected by a lifetime change until they are picked up and dropped again. If you want a truly clean state, remove the persistence folder:

# stop the instance first, then wipe persistence
mv mpmissions/dayzOffline.chernarusplus/storage_1 /backup/storage_1_$(date +%F)

Never wipe live. Take a backup of the whole mission folder first — automatic backups in the panel cover the whole file tree, but a manual copy before an economy overhaul is cheap insurance. The parameter reference used above is documented on the Bohemia Interactive configuration wiki.



Loading mods and writing the correct startup parameters

Mods are folders prefixed with @ placed at the root of the instance, next to the binary and serverDZ.cfg. Each one contains an addons/ directory and, usually, a keys/ directory.

Three steps, in order

  1. Upload @ModName to the root directory.
  2. Copy every .bikey from @ModName/keys/ into the global keys/ folder. Without this, verifySignatures = 2 kicks every connecting player.
  3. Append the mod to the -mod= parameter, respecting dependency order.
./DayZServer \
  -config=serverDZ.cfg \
  -port=2302 \
  -BEpath=battleye \
  -profiles=profiles \
  -dologs -adminlog -netlog -freezecheck \
  -mod=@CF;@Dabs\ Framework;@Community-Online-Tools \
  -servermod=@ServerSideOnlyTweaks

Key distinctions:

  • -mod= loads mods that clients must also have. Order matters: frameworks such as CF or Dabs Framework come first, dependent mods after.
  • -servermod= loads mods applied only on the machine, never downloaded by clients — admin tools, loot tweaks, spawn scripts.
  • Separate entries with ; and no spaces around it. Escape spaces inside folder names or, better, rename folders without spaces.
  • -freezecheck restarts a frozen process automatically; keep it enabled.

In a Pterodactyl panel, this line is not typed in a shell: the mod list goes into the dedicated startup variable, and the console rebuilds the command at every boot. Same logic, one text field.

Registering mod items in the economy

A mod that adds weapons or clothing ships classes, not loot rules. Nothing spawns until you declare it. Create a custom CE folder and reference it in cfgeconomycore.xml:

<economycore>
    <classes>...</classes>
    <defaults>...</defaults>
    <ce folder="custom">
        <file name="mod_types.xml" type="types"/>
        <file name="mod_spawnabletypes.xml" type="spawnabletypes"/>
    </ce>
</economycore>

Put mod_types.xml in mpmissions/<mission>/custom/ with the same structure as the vanilla file. This keeps mod entries separate from vanilla ones, which makes updates far less painful than merging thousands of lines by hand.

When something refuses to load

SymptomLikely causeFix
Players kicked for signatureMissing .bikey in keys/Copy the key, restart
Instance not listed in the browserQuery port blocked or wrongOpen UDP 2302–2305 and 27016, check steamQueryPort
Mod items never spawnNo types entryAdd a custom CE file
Boot loop after an editSyntax error in the configuration fileRead the last lines of the RPT in profiles/
Loot stays empty everywhereBroken XML dropped by the CEValidate every file, one at a time

Routine administration

  • Schedule restarts every 3–4 hours; memory usage and desync climb over long uptimes.
  • Keep automatic backups of mpmissions/ and profiles/, and export a copy before any mod update.
  • Use a long random passwordAdmin and a separate RCON password in battleye/BEServer_x64.cfg.
  • Watch the ADM log for teleport and duplication patterns; adminLogPlayerHitsOnly = 0 gives you the full picture.
  • Volumetric DDoS filtering is handled at infrastructure level on Fly-Serv, so your job stays on the application side: passwords, whitelist, signatures and updates.

More configuration walkthroughs for survival titles are published on the Fly-Serv blog.

Configuring DayZ is iterative: adjust one layer, restart, read the logs, measure. Start with a clean baseline configuration file, get the mission and its economy stable, then introduce mods one at a time with their keys and their custom CE entries. Once that discipline is in place, tuning loot tables or day cycles takes minutes instead of an evening of guesswork.



FAQ

Why don't my types.xml changes show up in game after a restart?

Three usual causes: an XML syntax error made the central economy drop the file (check the RPT log in profiles/), the items already exist as persistent objects and keep their old lifetime until they are picked up and dropped, or the usage and value tags do not match any building in the loot tier you are testing. Validate the file, restart, then verify in a Tier-appropriate area.

What exactly does verifySignatures = 2 do, and why are players being kicked?

It forces the instance to accept only mods signed with a key present in the global keys/