serverDZ.cfg is the one file every DayZ server reads before anything else: name, passwords, player count, time of day, anti-cheat strictness, logging, the login queue and which mission folder to load. It holds roughly fifty key = value; lines plus a class Missions block, and only about a dozen of them matter for most servers. The rest are either safe defaults or network tuning you should not touch without a reason. This guide goes through the file group by group, gives the value worth using for each line, and finishes with the syntax mistakes that make the server ignore your edits or refuse to start.
If you are setting up a server from nothing, start with the full DayZ server guide, which covers the install, ports and mods. This post is the reference you keep open while editing the file.
Where the file lives and how it is read#
The file sits in the server root, next to DayZServer_x64.exe on Windows or DayZServer on Linux, and the server is pointed at it with a launch parameter:
$ ./DayZServer -config=serverDZ.cfg -port=2302 -profiles=profilesThe name is a convention, not a requirement. -config= can point at any file, which is how people keep two configurations (a test one and a live one) side by side. On a panel host the parameter is usually fixed on the Startup tab and you only edit the file itself, either in the browser or over SFTP.
Three facts about how the server reads it explain most of the confusion people have:
- It is read once, at start. Editing the file while the server runs changes nothing until the next restart. Unlike some games, DayZ does not rewrite the file on shutdown, so an edit made on a running server is not lost - it is just not active yet.
- Unknown keys are ignored silently. A misspelt key, or one copied from an old guide that Bohemia has since removed, produces no error. The server simply uses the default. If a setting seems to do nothing, check the spelling against the file Bohemia ships with the current build.
- Syntax errors are not always silent. A missing semicolon or an unclosed quote can make the parser swallow the next line, or stop the server at start. The error, when there is one, is near the top of the server's
.RPTfile in the profiles folder.
The safest workflow is the boring one: stop the server, edit, save, start, then read the first screen of the log.
Identity and access#
hostname = "EU | Chernarus | Vanilla+ | 3-hour restarts";password = "";passwordAdmin = "a-long-random-string";enableWhitelist = 0;maxPlayers = 60;| Key | What it does | Worth setting to |
|---|---|---|
hostname | Name in the launcher and browser | Region, map, style, restart rhythm |
password | Join password | Empty for public, set for private |
passwordAdmin | Logs you in as admin in game | Long and random, never shared |
enableWhitelist | Only listed players may join | 0 for public, 1 for private |
maxPlayers | Slot count | What your CPU can actually serve |
The hostname is your only advertisement in a list of thousands of servers, and players filter by reading it. Put the things they decide on into it: region, map, whether it is vanilla, and how often it restarts. Avoid special characters that the launcher renders badly; plain ASCII and the pipe character are safe.
passwordAdmin is what you type after #login in the in-game chat to gain the handful of vanilla admin commands, such as #kick and #shutdown. It is separate from the BattlEye RCon password, which lives in a different file entirely and is covered in DayZ admin tools and BattlEye RCon. Both should be long and random. A short admin password on a public DayZ server is guessed, not cracked.
enableWhitelist = 1 turns the server allow-list only. On standard installs the list is a plain text file, whitelist.txt, with one SteamID64 per line; the server reads it at start. If you turn the whitelist on with an empty file, nobody can join, including you, so add yourself first.
maxPlayers accepts high numbers, but the honest limit is server FPS, not the field. A 60-slot vanilla server is reasonable on three cores; a 60-slot server with a large mod list often is not. The numbers are in the requirements table of the main guide, and how many players fit on a server covers the general reasoning.
Anti-cheat, builds and client restrictions#
verifySignatures = 2;forceSameBuild = 1;allowFilePatching = 0;speedhackDetection = 1;disable3rdPerson = 0;disableCrosshair = 0;disableVoN = 0;vonCodecQuality = 20;verifySignatures = 2 checks every mod's signature against the keys in the server's keys folder. It is the only value Bohemia supports, and dropping it is how servers end up running modified client files. If players are kicked with a signature error, the fix is to copy the missing .bikey into keys, never to lower this value.
forceSameBuild = 1 rejects clients on a different game build. After a patch, players who have not updated get a clear message at the door instead of a vague failure halfway through loading. Leave it on.
allowFilePatching = 0 blocks clients launched with -filePatching, which lets a client load loose files instead of signed PBOs. Mod developers testing locally need it on; nobody else does, and it is a common path for casual cheating.
speedhackDetection = 1 enables the engine's speed-hack check. It is cheap and rarely produces false positives; leave it at the shipped value.
disable3rdPerson and disableCrosshair are the two settings that define a server's style more than any other. First-person only (disable3rdPerson = 1) removes the ability to peek over walls from third person and is the norm on "hardcore" servers. It also changes how bases are attacked and defended, so decide before launch rather than after a month of third-person base design.
disableVoN = 0 keeps proximity voice, which is a large part of how DayZ plays - hold-ups, negotiation, trading. vonCodecQuality runs from 0 to 30; 20 is the shipped value and a sensible trade between clarity and bandwidth. Raising it to 30 costs a little bandwidth per talking player and is rarely noticed.
Time of day and the day-night cycle#
serverTime = "SystemTime";serverTimeAcceleration = 6;serverNightTimeAcceleration = 4;serverTimePersistent = 1;| Key | Range | What it does |
|---|---|---|
serverTime | "SystemTime" or "YYYY/MM/DD/HH/MM" | Starting date and time |
serverTimeAcceleration | 0 to 24 | Multiplier on the in-game clock |
serverNightTimeAcceleration | 0.1 to 64 | Extra multiplier applied at night |
serverTimePersistent | 0 or 1 | Keep the clock across restarts |
This group causes more player complaints than any other, and the arithmetic is simple once you see it. serverTimeAcceleration multiplies the whole clock: at 1 a day lasts 24 real hours, at 6 it lasts four, at 12 it lasts two. serverNightTimeAcceleration is applied on top of that, only at night, so the effective night speed is the two values multiplied together.
A worked example. With serverTimeAcceleration = 6 and serverNightTimeAcceleration = 4, daytime passes at 6x and night at 24x. A real-world four-hour play session sees long, playable days and nights that are over in well under an hour. That shape - long day, short night - is what most public servers want, because DayZ nights are genuinely dark and a large part of any population logs off for them.
serverTime = "SystemTime" starts the clock at the machine's local time. A fixed value such as "2024/6/15/8/0" starts every session at eight in the morning in June, which also controls the season-dependent length of daylight. With serverTimePersistent = 0, that starting time is reapplied at every restart - which is why servers with four restarts a day and the default of 0 have the same morning four times. Set it to 1 and the clock carries on from where it stopped.
Two related keys change how night looks rather than how long it lasts. lightingConfig = 0 is the brighter night, 1 the darker one. disablePersonalLight = 1 removes the faint light around each player that makes pitch-dark nights playable without a torch. Turning both towards dark makes nights much harder; turning them towards light makes them merely atmospheric. On recent builds these two can also be set in cfggameplay.json, covered below.
Persistence, respawn and base damage#
instanceId = 1;storageAutoFix = 1;respawnTime = 5;disableRespawnDialog = 0;disableBaseDamage = 0;disableContainerDamage = 0;instanceId decides which persistence folder the server reads and writes: storage_1 for instance 1, storage_2 for instance 2, inside the mission folder. That folder holds every base, tent, vehicle and character. Change the number and the server starts a fresh world beside the old one - the old data is still there, just not loaded. Two servers on one machine must never share an instance id. Everything about that folder, including partial and full wipes, is in DayZ wipes and persistence.
storageAutoFix = 1 lets the server repair a damaged persistence file at start instead of refusing to load it. Keep it on. The alternative to an automatic repair is not an intact world, it is a server that will not boot until somebody restores a backup by hand.
respawnTime is the delay in seconds before a dead player can respawn. disableRespawnDialog = 1 skips the choice between a fresh and a random spawn and sends the player straight to a random point.
disableBaseDamage = 1 makes built fences and walls indestructible, and disableContainerDamage = 1 does the same for tents, barrels and crates. Together they turn a server into a no-raid server. That is a legitimate style for PvE or roleplay communities, but it removes the counterweight to hoarding, and on a long-running server with indestructible storage the loot economy fills up with items nobody will ever lose. If you switch raiding off, pay closer attention to the counting flags in types.xml, explained in the loot economy guide.
Login queue, ping and messages#
loginQueueConcurrentPlayers = 5;loginQueueMaxPlayers = 500;maxPing = 200;motd[] = {"Restarts every 3 hours", "Discord: example.gg/server"};motdInterval = 300;loginQueueConcurrentPlayers is how many players may be in the loading process at once, and loginQueueMaxPlayers is how long the queue may get. The defaults exist for a reason: twenty players loading simultaneously after a restart is a large burst of disk and CPU work, and letting them in five at a time keeps the server FPS stable for the people already in. Raising the first value makes the post-restart rush faster and the first minutes rougher.
maxPing kicks players whose ping stays above the given value in milliseconds. For a server in Germany, 200 lets in most of Europe, the Middle East and the eastern United States, and excludes players whose movement would desync for everybody near them. Lower it only if you are sure of your audience. Latency, jitter and packet loss explains why a high ping hurts other people as well as the player who has it.
motd[] is an array of strings, shown in rotation; motdInterval is the gap between them in seconds. Note the brackets after the name and the braces around the list: that is the one place in the file where the syntax changes, and it is where most parse errors come from.
Logging and the debug monitor#
timeStampFormat = "Short";logAverageFps = 300;logMemory = 300;logPlayers = 300;logFile = "server_console.log";adminLogPlayerHitsOnly = 0;adminLogPlacement = 1;adminLogBuildActions = 1;adminLogPlayerList = 1;enableDebugMonitor = 0;The three log* values are intervals in seconds. logAverageFps = 300 writes the server FPS to the log every five minutes, and it is the single most useful number for judging whether a server is overloaded. Healthy is above about 30; under 15, players notice rubber-banding and doors that need two attempts. logMemory and logPlayers do the same for memory use and player count, which lets you line up a slowdown against how many people were online.
logFile names the console log written into the profiles folder. timeStampFormat is "Short" (time only) or "Full" (date and time); use Full if you ever have to compare logs across days.
The adminLog* keys decide what goes into the .ADM file, the record of connections, kills, hits and positions:
adminLogPlayerHitsOnly = 1limits hit logging to hits on players, which shrinks the file on servers with many infected.adminLogPlacement = 1records every placed object - tents, traps, fences. Essential for settling arguments about who built what where.adminLogBuildActions = 1records building, dismantling and destroying base parts. Turn it on if your rules care about raiding.adminLogPlayerList = 1writes the full player list with positions every five minutes.
All of it costs disk rather than CPU. A busy server with every option on writes a few tens of megabytes of .ADM a day, which is cheap insurance; just prune old logs on a schedule. Logs worth keeping has a sensible retention policy.
enableDebugMonitor = 1 shows a small overlay to every player with their health, blood and position. It is useful on a test server and a gift to anyone hunting other players on a live one. Leave it off in public.
Network, query and replication#
steamQueryPort = 2305;guaranteedUpdates = 1;multithreadedReplication = 1;simulatedPlayersBatch = 20;networkRangeClose = 20;networkRangeNear = 150;networkRangeFar = 1000;networkRangeDistantEffect = 4000;defaultVisibility = 1375;defaultObjectViewDistance = 1375;steamQueryPort is the UDP port the launcher and browser query for the server's name, map and player count. If the server is joinable by IP but missing from the list, this port is the first suspect: it must match a port actually allocated to the server and must not be used by anything else. Game server ports explained covers why games split the query port from the game port.
guaranteedUpdates = 1 selects the network protocol; 1 is the only documented value. multithreadedReplication = 1 lets the engine spread network replication across threads and should stay on. simulatedPlayersBatch caps how many players the server simulates per frame.
The networkRange* values are distances in metres within which objects are replicated to a client at different priorities, and the two visibility values cap view distance and object view distance. They are the kind of settings that hosting forums recommend raising for "better visuals". Do not. Each increase means more objects replicated to every player, every frame, and the cost lands on the main thread that already decides your server FPS. The shipped values are tuned for the shipped maps. The only good reason to change them is a specific problem you have measured, on a test instance first.
The mission block and cfggameplay.json#
The file ends with the block that chooses the map and economy:
enableCfgGameplayFile = 1;class Missions{ class DayZ { template = "dayzOffline.chernarusplus"; };};template is the name of a folder in mpmissions, spelled exactly, capitals included. Chernarus is dayzOffline.chernarusplus and Livonia is dayzOffline.enoch; community maps ship their own mission folders, as described in running Deer Isle or Namalsk. A wrong name does not fall back to Chernarus - the server fails to load a mission.
enableCfgGameplayFile = 1 tells the server to read cfggameplay.json from the mission folder. Bohemia added that file to hold gameplay settings that used to need a script mod: stamina, movement, base-building restrictions, spawn gear presets, temperature and lighting. Several values exist in both places - disablePersonalLight, lightingConfig, disableBaseDamage, disableContainerDamage, disableRespawnDialog - and with the json enabled, Bohemia's documentation treats the json as the place they are set. If you enable it, set those values there and leave the .cfg copies at defaults, so there is only one answer to "where is this configured".
A fragment, as an illustration of the shape rather than a complete file:
{ "GeneralData": { "disableBaseDamage": false, "disableContainerDamage": false, "disableRespawnDialog": false }, "PlayerData": { "disablePersonalLight": false }, "WorldsData": { "lightingConfig": 1 }}Start from the cfggameplay.json that ships in your mission folder rather than writing one: the file has a version field and many more keys, and the structure changes between game updates. Validate the JSON before restarting - one trailing comma and the server either ignores the file or stops.
A clean starting configuration#
Put together, a sensible public server looks like this. Copy the shape, not the strings:
hostname = "EU | Chernarus | Vanilla+ | Restarts 00 03 06 09 12 15 18 21 CET";password = "";passwordAdmin = "replace-with-32-random-characters";enableWhitelist = 0;maxPlayers = 50;verifySignatures = 2;forceSameBuild = 1;allowFilePatching = 0;disableVoN = 0;vonCodecQuality = 20;disable3rdPerson = 0;disableCrosshair = 0;serverTime = "SystemTime";serverTimeAcceleration = 6;serverNightTimeAcceleration = 4;serverTimePersistent = 1;loginQueueConcurrentPlayers = 5;loginQueueMaxPlayers = 500;instanceId = 1;storageAutoFix = 1;respawnTime = 5;maxPing = 200;timeStampFormat = "Full";logAverageFps = 300;logMemory = 300;logPlayers = 300;logFile = "server_console.log";adminLogPlacement = 1;adminLogBuildActions = 1;enableDebugMonitor = 0;steamQueryPort = 2305;enableCfgGameplayFile = 1;class Missions{ class DayZ { template = "dayzOffline.chernarusplus"; };};Before you copy that, take a backup of the original file. On RE:NODE the in-browser editor highlights the syntax, which catches unclosed quotes before you restart, and backup slots on every DayZ plan let you put the whole server back with a button if an edit goes wrong. The query and game ports are allocated for you and shown on the Network tab, so steamQueryPort should match the one listed there.
Mistakes that break the file#
- Smart quotes. Copying from a web page or a word processor turns
"into curly quotes, which the parser does not accept. Edit in a plain text editor or the panel's editor. - Keys from old guides. Guides from 2018 list keys that have been removed or renamed. Unknown keys are ignored, so the server runs and the setting does nothing. Compare against the file shipped with your build.
- The template name. Case matters on Linux.
dayzoffline.chernarusplusanddayzOffline.chernarusplusare different folders there. - Two copies of one setting. A value set in both
serverDZ.cfgandcfggameplay.jsonleads to arguments about which one wins. Set it in one place. - Editing the wrong file. If the launch line says
-config=serverDZ_live.cfg, editingserverDZ.cfgchanges nothing. Check the Startup tab or launch line first. - Changing `instanceId` by accident. The world appears wiped. It is not - the old storage folder is still there. Put the number back.
FAQ#
Do I need to restart after editing serverDZ.cfg?
Yes. The file is read once when the server starts. Changes take effect at the next start, and the server does not overwrite your edits on shutdown, so it is safe to edit while it runs as long as you restart afterwards.
How do I make nights shorter on my DayZ server?
Raise serverNightTimeAcceleration. It multiplies the normal acceleration only at night, so serverTimeAcceleration = 6 with a night value of 4 gives long days and nights that pass four times faster than the days.
Why does my server ignore a setting I added?
Usually a misspelt or obsolete key, which DayZ ignores without an error, or a missing semicolon on the line before it. Compare the key with the shipped file and check the .RPT log for parse messages.
What is the difference between passwordAdmin and the RCon password?
passwordAdmin is used in game with #login and gives a few chat commands. The BattlEye RCon password lives in BEServer_x64.cfg and is what remote tools use to connect. They are independent and should both be long and random.
Should I raise the network range and view distance values?
No, unless you have measured a specific problem. Higher values replicate more objects to every player and cost server FPS. The shipped values are tuned for the shipped maps.
Can I run two servers with the same serverDZ.cfg?
Not as-is. Each needs its own ports, its own steamQueryPort and its own instanceId, or the second will fail to bind or will share and corrupt the first one's persistence.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.