Créer et administrer un serveur DayZ privé : configuration et gestion au quotidien

Par Benjamin D. · PDG

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

Contents

DayZ server configuration is not a single file you edit once: it is a stack of layers, from serverDZ.cfg for core parameters, to the mission folder for world rules, the central economy XML files for loot, and BattlEye plus admin mods for moderation. Knowing which file controls what saves hours of guesswork and avoids the classic "my loot edits never applied" frustration.

Where DayZ server configuration actually lives

A DayZ instance reads its settings from three distinct places, and mixing them up is the number one cause of settings that appear to be ignored. Community admins running on managed infrastructure such as DayZ server hosting get the file tree already laid out in the panel file manager, but the logic is identical on any Linux or Windows machine.

DayZServer/
├── serverDZ.cfg              # core parameters (slots, time, whitelist, mission)
├── battleye/
│   └── BEServer_x64.cfg      # RCON password and port
├── profiles/                 # logs (.ADM, .RPT), whitelist.txt, ban.txt
└── mpmissions/
    └── dayzOffline.chernarusplus/
        ├── init.c            # world init, date, weather, spawn gear
        ├── cfggameplay.json  # stamina, base building, HUD, player spawn
        ├── cfgeconomycore.xml
        ├── cfgspawnabletypes.xml
        ├── cfgeventspawns.xml
        ├── db/
        │   ├── types.xml     # loot table
        │   ├── globals.xml   # economy-wide variables
        │   ├── events.xml    # vehicles, heli crashes, animals
        │   └── messages.xml  # scheduled restart warnings
        └── storage_1/        # persistence data

Key serverDZ.cfg parameters

Open serverDZ.cfg in the panel editor or over SSH. Every line ends with a semicolon, and a stray comma or missing quote will make the instance fall back to defaults silently. A workable baseline for a community project looks like this:

password = "";                        // empty = public join
passwordAdmin = "USE_A_LONG_SECRET";
maxPlayers = 60;
verifySignatures = 2;                 // mandatory when running mods
forceSameBuild = 1;
disableVoN = 0;
vonCodecQuality = 20;
disable3rdPerson = 0;
disableCrosshair = 1;
serverTime = "SystemTime";
serverTimeAcceleration = 8;
serverNightTimeAcceleration = 4;
serverTimePersistent = 1;
guaranteedUpdates = 1;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;
instanceId = 1;
storageAutoFix = 1;
enableWhitelist = 1;
respawnTime = 5;
timeStampFormat = "Short";
logAverageFps = 30;
logMemory = 30;
logPlayers = 30;
logFile = "server_console.log";
adminLogPlayerHitsOnly = 0;
adminLogPlacement = 1;
adminLogBuildActions = 1;
adminLogPlayerList = 1;

motd[] = { "Welcome to the shard", "Restarts every 4h" };
motdInterval = 300;

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

Three parameters deserve attention. verifySignatures = 2 is required as soon as you load client-side mods, otherwise players will be kicked or, worse, unsigned content will be tolerated. instanceId separates persistence between shards — change it and you effectively wipe the world state, so keep it stable. serverTimeAcceleration multiplies the day cycle; a value of 8 with a night multiplier of 4 gives long daylight windows without erasing night gameplay entirely.

Launch parameters

The binary itself takes arguments that no config file can replace. On a Linux instance managed through a Pterodactyl panel, the startup line is usually editable in the startup tab:

./DayZServer -config=serverDZ.cfg -port=2302 \
  -BEpath=battleye -profiles=profiles \
  -dologs -adminlog -netlog -cpuCount=4 \
  -mod=@CF;@VPPAdminTools -servermod=@ServerSideOnly

Note the split between -mod (loaded by both sides, clients must have the same content) and -servermod (server-side only). Getting this wrong produces the endless "you cannot join, missing content" loop. The -adminlog flag is what populates the .ADM file used for moderation, and -cpuCount should match the cores actually available so the simulation thread is not starved. Ryzen-class CPUs with high clock speeds and NVMe storage help here: DayZ is heavily single-thread bound and persistence writes hit the disk on every save cycle.

Mission files: world rules, gameplay and persistence

Everything that describes how the world behaves sits in mpmissions/dayzOffline.chernarusplus/. If you edit a file in the wrong mission folder — a common mistake when several maps exist on disk — nothing changes in game, even after a restart.

init.c

This Enforce Script file runs when the world loads. It sets the in-game date, weather behaviour and, in many community setups, the starting loadout. A minimal date override looks like this:

void main()
{
    Hive ce = CreateHive();
    if ( ce ) ce.InitOffline();

    Weather weather = g_Game.GetWeather();
    weather.MissionWeather(false);
    weather.GetOvercast().Set(0.3, 0.5, 1);
    weather.GetRain().Set(0, 0.1, 1);
    weather.GetFog().Set(0.05, 0.2, 1);

    int year, month, day, hour, minute;
    GetGame().GetWorld().GetDate(year, month, day, hour, minute);
    GetGame().GetWorld().SetDate(year, 7, 15, 9, 0);
}

Custom spawn gear is added in the StartingEquipSetup section of the same file. Keep a copy of the vanilla version before touching it; a syntax error in init.c prevents the mission from loading at all, and the RPT log will point at the exact line.

cfggameplay.json

Introduced to expose gameplay values without scripting, this JSON file controls stamina behaviour, base building rules, HUD elements, map visibility and player spawn selection. Typical community edits include disabling the stamina cap for a more arcade feel, enabling the spawn selection screen, or blocking base damage outside raid windows. It is only read when "version" matches the current game build, so re-check it after every major patch.

Persistence and storage

The storage_1 folder holds player positions, built structures, vehicles and buried stashes. Wiping a shard means deleting that folder while the process is stopped — never while it is running. Automatic backups matter here: a corrupted persistence file after an unclean shutdown can erase weeks of base building. Snapshot the whole mission folder, not just the database, so custom XML edits are restored together with the world state.

Loot economy: types.xml and the central economy

The central economy (CE) is the part of DayZ server configuration that separates a generic shard from a tuned one. It decides how many items exist on the map, where they spawn, how long they survive and when they come back.

Anatomy of a type entry

<type name="Mosin9130">
    <nominal>8</nominal>
    <lifetime>14400</lifetime>
    <restock>1800</restock>
    <min>4</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>

Attribute	What it controls
`nominal`	Target number of that item alive on the map at once.
`min`	Threshold below which the economy queues a respawn.
`lifetime`	Seconds an untouched item stays before despawning.
`restock`	Delay before the item is allowed to spawn again.
`quantmin` / `quantmax`	Fill percentage for ammo, liquids and consumables.
`usage`	Building type where it can appear (Military, Industrial, Farm…).
`value`	Loot tier zone, Tier1 to Tier4, matching map areas.
`count_in_*` flags	Whether stored, buried or carried items count against nominal.

A frequent pitfall: raising nominal without lowering lifetime. Items already lying on the ground still occupy slots, so the new ones never appear. Setting count_in_cargo="1" on high-value gear also stops hoarders from emptying the map by stashing everything in tents.

Adding custom files instead of editing vanilla

Modifying db/types.xml directly means your edits are overwritten at every game update. The cleaner approach is a dedicated folder registered in cfgeconomycore.xml:

<ce folder="custom">
    <file name="custom_types.xml" type="types"/>
    <file name="custom_events.xml" type="events"/>
    <file name="custom_spawnabletypes.xml" type="spawnabletypes"/>
</ce>

Entries declared there override the vanilla values for matching class names. After every edit, validate the XML before restarting — a single unclosed tag makes the whole economy fail to load, and the RPT will show Unable to load file with the offending path. Details on the schema are documented on the official Bohemia Interactive central economy wiki.

Events, vehicles and spawnable types

events.xml drives dynamic content: vehicle spawns, helicopter crash sites, infected hordes and animal groups. cfgeventspawns.xml holds the coordinates for each event, and cfgspawnabletypes.xml defines the cargo and attachments that come with a spawned object — for instance which weapons appear inside a crash site, or which wheels a car spawns with. Together, these three files let you build a custom loot rhythm without a single line of script.

Whitelist, RCON and admin tools

A community shard needs control over who joins and a way to intervene without restarting. This is the operational half of DayZ server configuration.

Whitelisting

Set enableWhitelist = 1; in serverDZ.cfg, then create profiles/whitelist.txt containing one Steam64 ID per line. Any ID not listed is refused at connection. The same folder holds ban.txt, where entries use the BattlEye GUID or Steam64 ID with an optional duration and reason. Both files are re-read on restart, so keep restarts scheduled rather than manual.

BattlEye and RCON

Remote administration goes through BattlEye. In battleye/BEServer_x64.cfg:

RConPassword A_LONG_RANDOM_STRING
RestrictRCon 0
RConPort 2306

Use a long random RCON secret, distinct from passwordAdmin, and rotate it whenever a staff member leaves the team. Any RCON client can then broadcast messages, kick players and trigger shutdowns. Pair it with a scheduler to send countdown warnings before each restart, and mirror the same warnings in db/messages.xml so players see them even without a third-party client.

In-game admin mods

Community Framework (CF) — dependency for most admin mods, loaded on both sides.
VPPAdminTools — teleport, spawn items, ESP for moderation, ban management, permissions per staff role.
Community Online Tools (COT) — similar toolkit with granular permission groups.
DayZ Editor Loader — loads custom map buildings exported from the editor, server-side only.

Give each moderator a named account with the minimum permission set, and keep spawn-item rights restricted to a small group. Panels with sub-user support let you apply the same principle outside the game: console access for moderators, file access limited to the people who actually edit XML.

Logs, backups and stability

The profiles folder produces .ADM (player actions, placements, kills), .RPT (script errors and warnings) and crash logs. Grep the RPT after every configuration change:

grep -iE "error|unable to load|cannot" profiles/*.RPT | tail -n 40

Automatic backups, a fixed restart schedule every three to four hours and a validated XML set before each restart are what keep a shard predictable. Anti-DDoS filtering at the infrastructure level handles volumetric attacks, but application-side hygiene — solid RCON secrets, whitelist, updated mods — stays your responsibility. If you administer several communities, the same logic of layered config files applies to other survival titles; you can browse All our game servers or read more admin guides on the Fly-Serv blog.

Bringing the layers together

Treat the four layers as a checklist: core parameters, mission rules, economy XML, admin tooling. Change one thing at a time, restart, then read the RPT. Keep custom economy files separate from vanilla ones so game updates never erase your work, and back up the mission folder before each session of edits. That discipline is what makes a community shard stable over months.

FAQ

Why are my types.xml changes not visible in game?

Three usual causes: you edited the wrong mission folder, the XML failed to parse, or existing items still fill the nominal count. Check the RPT for "Unable to load file", confirm the path matches the template declared in serverDZ.cfg, and shorten lifetime so old items despawn before the new values take effect.

How do I whitelist players on a DayZ community shard?

Set enableWhitelist = 1; in serverDZ.cfg, then add one Steam64 ID per line in profiles/whitelist.txt. Restart for the file to be read. Keep the list in version control or a shared document so several moderators can update it without overwriting each other.

What is the difference between -mod and -servermod?

-mod loads content that clients must also have installed, and requires verifySignatures = 2. -servermod loads content used only by the machine running the world, such as map object loaders or economy scripts, and players join without downloading anything extra.