Configurer un serveur DayZ : serverDZ.cfg, loot et mods expliqués

Par Benjamin D. · PDG

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

Contents

DayZ server configuration is where a survival community is won or lost: one wrong value in serverDZ.cfg or types.xml turns a promising map into an empty loot desert or a stuttering mess. This guide walks through the files that genuinely matter, what each parameter changes in-game, and how to tune them step by step without wrecking persistence.

What DayZ server configuration actually controls

A DayZ instance runs on three separate layers, and most administration mistakes come from confusing them. The first layer is the engine and network layer, defined by serverDZ.cfg: slots, time acceleration, replication, logging, signature checks. The second is the mission layer, stored in mpmissions/dayzOffline.chernarusplus/, which holds the Central Economy (CE) — loot tables, events, spawn points and persistence storage. The third is the mod layer, injected at launch through startup parameters, which can silently override both of the others.

DayZServer/
├── serverDZ.cfg
├── keys/
├── profiles/
│   ├── server_console.log
│   └── *_CE/
├── mpmissions/
│   └── dayzOffline.chernarusplus/
│       ├── init.c
│       ├── cfgeconomycore.xml
│       ├── cfgspawnabletypes.xml
│       ├── cfgeventspawns.xml
│       ├── cfgplayerspawnpoints.xml
│       ├── db/
│       │   ├── economy.xml
│       │   ├── globals.xml
│       │   ├── events.xml
│       │   ├── messages.xml
│       │   └── types.xml
│       └── storage_1/
└── @CF/ @Mods/

Working on these files goes a lot faster when you have a live console, a file manager and one-click restarts in front of you rather than an FTP client and a terminal in another window. That is exactly what a Pterodactyl-based DayZ server hosting environment gives you: edit types.xml, restart, watch the console output, repeat. If you want to see the other titles running on the same panel logic, browse All our game servers.

One rule before you touch anything

Change one block of values at a time, restart, and observe for at least a full loot cycle (roughly 15–30 minutes of live play). CE behaviour is delayed by design; if you edit ten variables at once you will never know which one caused the flood of Mosins on the coast.

Inside serverDZ.cfg: the parameters that shape performance

The main configuration file is plain text, semicolon-terminated, and read once at launch. Here is a realistic baseline for a 60-slot Chernarus instance:

hostname = "Chernarus | Hardcore | Weekly Restarts";
password = "";
passwordAdmin = "ChangeThisNow_2024!";
maxPlayers = 60;
verifySignatures = 2;
forceSameBuild = 1;
disableVoN = 0;
vonCodecQuality = 20;
disable3rdPerson = 1;
disableCrosshair = 1;
disablePersonalLight = 1;
serverTime = "SystemTime";
serverTimeAcceleration = 8;
serverNightTimeAcceleration = 4;
serverTimePersistent = 0;
guaranteedUpdates = 1;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;
instanceId = 1;
storageAutoFix = 1;
respawnTime = 5;
timeStampFormat = "Short";
logAverageFps = 1;
logMemory = 1;
logPlayers = 1;
logFile = "server_console.log";
adminLogPlayerHitsOnly = 0;
adminLogPlacement = 1;
adminLogBuildActions = 1;
enableDebugMonitor = 0;
allowFilePatching = 0;
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";
    };
};

Network bubble and view distance

The networkRange* family defines how far entities are replicated to each client. Raising networkRangeFar to 2000+ on a 100-slot map multiplies the number of synchronised objects per player and is one of the fastest ways to drive average frame time up. Keep defaultVisibility and defaultObjectViewDistance aligned (1375 is a sane figure); pushing them to 3000 mostly benefits snipers and punishes everyone else through bandwidth and CPU load.

simulatedPlayersBatch controls how many players are processed per simulation batch. Lower values ease per-frame spikes on busy instances but increase perceived desync. multithreadedReplication = 1 should stay enabled on modern high-frequency Ryzen cores, since DayZ still leans heavily on single-thread speed for its main loop while replication runs alongside.

Time, persistence and instance identity

Parameter	Effect	Practical value
`serverTimeAcceleration`	Day length multiplier	6–12 for a full day/night cycle across a play session
`serverNightTimeAcceleration`	Extra multiplier applied at night only	3–6 to shorten darkness without killing atmosphere
`serverTimePersistent`	Keeps world time across restarts	1 if you restart often and want continuity
`instanceId`	Selects the `storage_X` folder	1 unless you run several worlds from one install
`storageAutoFix`	Repairs corrupted persistence entries at boot	1, always
`verifySignatures`	Rejects unsigned mods and tampered PBOs	2 on any public instance

Two anti-cheat-adjacent values deserve attention: allowFilePatching = 0 blocks clients loading unpacked scripts, and forceSameBuild = 1 prevents version mismatch after a game update. Combined with speedhackDetection = 1 and a strong passwordAdmin, they cover the basics. Volumetric DDoS filtering is handled upstream at infrastructure level on Fly-Serv, so your job is application-level hygiene: strong admin credentials, restricted BattlEye RCON access, and automatic backups of storage_1/.

Loot economy files: types.xml, globals.xml and the db folder

The Central Economy is the part of DayZ server configuration players actually feel. It is a spawner with a memory: it counts every registered item in the world, in containers, on players, and decides what to add or delete over time.

Reading nominal, min, lifetime and restock

<type name="M4A1">
    <nominal>12</nominal>
    <lifetime>7200</lifetime>
    <restock>1800</restock>
    <min>6</min>
    <quantmin>-1</quantmin>
    <quantmax>-1</quantmax>
    <cost>100</cost>
    <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>

nominal — target number of instances the economy tries to maintain. Not a guarantee, a ceiling it aims for.
min — the trigger. When the counted amount drops below min, the item becomes eligible for respawn back toward nominal.
lifetime — seconds an untouched item stays on the ground before cleanup. 7200 = two hours.
restock — cooldown in seconds before the item can respawn again after being consumed. Set it to 0 for instant availability, or high for rare gear.
quantmin / quantmax — fill percentage for consumables (ammo boxes, canteens, magazines). -1 means not applicable.
flags — the counting rules. count_in_cargo and count_in_player set to 1 mean hoarded items still count against nominal, which is how you prevent gear inflation on long-lived maps.

The classic tuning error is raising nominal without touching the flags. If count_in_cargo="0", everything stuffed into a tent disappears from the count, the economy keeps spawning more, and after three weeks the map is drowning in military gear. For a loot-scarce hardcore ruleset, set count_in_cargo="1" and count_in_hoarder="1" on weapons and high-tier attachments.

Usage tags and tiers

<usage> defines where an item can spawn (Military, Police, Medic, Farm, Industrial, Town, Village, Hunting, Coast). <value> defines which map tier accepts it — Tier1 near the coast, Tier4 deep inland and on high-value military zones. Removing a usage tag is the cleanest way to stop a rifle appearing in residential buildings without editing every single building prototype in mapgroupproto.xml.

globals.xml: the variables that hit performance

Variable	What it does	Note
`ZombieMaxCount`	Global infected cap	Biggest single CPU lever. 1000 vanilla; drop to 600–800 on heavily modded instances
`AnimalMaxCount`	Global wildlife cap	200 default; lower it if you also add mod fauna
`CleanupLifetimeDefault`	Fallback despawn timer	Applies to anything with no explicit lifetime
`CleanupLifetimeDeadPlayer`	Corpse persistence	3600 is plenty; longer values bloat persistence
`IdleModeCountdown`	Delay before CE sleeps on an empty instance	Keeps CPU usage low overnight
`FlagRefreshFrequency`	Base-building refresh interval	Paired with `FlagRefreshMaxDuration` for wipe policy
`TimeLogin` / `TimeLogout`	Connect and disconnect timers	Raise `TimeLogout` to 30s to discourage combat logging

Overriding without touching vanilla files

Editing db/types.xml directly means every game update or mission re-copy can overwrite your work. Register a custom folder in cfgeconomycore.xml instead:

<ce folder="custom">
    <file name="cfgtypes_custom.xml" type="types"/>
    <file name="cfgspawnabletypes_custom.xml" type="spawnabletypes"/>
</ce>

Entries loaded later override earlier ones for the same class name, so your custom file wins. Keep it version-controlled and re-upload it after each patch. Full attribute reference is documented on the official Bohemia community wiki.

Mod load order, keys and economy conflicts

Mods are not merged intelligently — they are stacked. Order decides which script and which config wins, and a bad order produces the two most common failure modes: a black screen at 90% loading, or an instance that boots but ignores half your loot edits.

Startup line and dependency order

./DayZServer \
  -config=serverDZ.cfg \
  -port=2302 \
  -BEpath=battleye \
  -profiles=profiles \
  -mod=@CF;@Dabs_Framework;@VPPAdminTools;@BuilderItems;@MuchStuffPack \
  -serverMod=@ServerAntiHack \
  -dologs -adminlog -netlog -freezecheck

Frameworks first. @CF, @Dabs_Framework and similar libraries must be loaded before anything that depends on them.
Content mods after. Weapon packs, building mods, map add-ons.
Compatibility patches last, since they are meant to override the mods they patch.
-serverMod loads server-side-only PBOs that clients do not need to download.

Signature checks and keys

With verifySignatures = 2, every mod's .bikey must be present in the keys/ directory or clients get kicked at connection. After each mod update, re-copy the keys — mod authors do rotate them.

cp @CF/keys/*.bikey keys/
cp @VPPAdminTools/keys/*.bikey keys/
ls -1 keys/

When mods fight the economy

Most content mods ship their own CE folder and expect you to declare it in cfgeconomycore.xml. If you skip that step, the items exist in game but never spawn. If two mods register a class with the same name, the last one loaded overwrites the first — check profiles/server_console.log for Unknown type or duplicate-class warnings after a boot, they are your best diagnostic.

A tuning loop that does not wipe your map

Take a backup of mpmissions/ and storage_1/ before any economy edit — automatic backups in the panel cover this, but a manual snapshot before a big change costs nothing.
Edit one file. Save. Restart from the console.
Watch the boot log for XML parse errors; a malformed types.xml silently disables the whole economy.
Play or fly around a known loot zone for 20 minutes and compare against your expected nominal.
Only wipe storage_1/ when you change persistence-critical structures (map, mission template, base-building mods). Loot table edits alone do not require a wipe.

The same discipline applies to any survival title with a persistent world — the file names differ but the logic is identical on an Arma Reforger server or a Rust server. More configuration walkthroughs are collected on the Fly-Serv blog.

Putting it together

Solid DayZ server configuration is iterative, not a single perfect file. Start from vanilla values, tighten