# DayZ Server Hosting - everything RE:NODE has published > A DayZ server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it. Generated from https://www.renode.space/game-servers/dayz, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/dayz. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is DayZ servers with room for a full Chernarus wipe. - Genres: Action, Adventure, Massively Multiplayer - Developer: Bohemia Interactive - Released: 13 Dec, 2018 - Steam: https://store.steampowered.com/app/221100/ ### You supply two things yourself DayZ is only sold with a credential its publisher issues to a person, so you need to own the game yourself and provide it after checkout. We cannot create it for you and we never share one between customers. Your server is built immediately; the game installation waits until you paste it into the Setup tab, then runs itself. ### What comes with every DayZ server - Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other DayZ server on the internet. - The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off. - Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine. - 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose. - 3 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them. - People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams. ### Which DayZ plan do you need? Memory is what decides whether a server holds together, so start there. The Standard tier gives 6 GB and 2 vCPU, which suits a private group. The Pro tier at 10 GB is where most public servers sit, and Premium at 12 GB exists for the servers that stay full. Storage matters more than people expect once mods and backups are involved - plans here run from 35 GB to 85 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have. If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players. More game servers: https://www.renode.space/ai/game-servers.md ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Where are the servers?** Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-15 03:06 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/dayz or in the panel shop at https://panel.renode.space before quoting one. - You supply: Steam username - DayZ server files are not downloadable anonymously, so the installer signs in as you. Use an account that owns DayZ Server, ideally a separate one with Steam Guard set to email rather than the mobile app, or the download cannot complete unattended. (https://store.steampowered.com/about/) - You supply: Steam password - Stored with the server and used only by SteamCMD to download the server files. We strongly suggest a dedicated account rather than your main one. - You supply: Steam Guard code - Leave this blank the first time. If Steam does not recognise this account on this machine, it emails a short code to the account's own inbox. Come back, paste it in here, and press Start Setup again quickly — the code expires. | Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports | |---|---|---|---|---|---|---|---| | Standard | $19 | 6 GB | 2 vCPU | 35 GB | 1 | 2 | 3 | | Advanced | $25 | 8 GB | 2.5 vCPU | 50 GB | 1 | 2 | 3 | | Pro | $31 | 10 GB | 3 vCPU | 65 GB | 1 | 2 | 3 | | Premium | $38 | 12 GB | 3.5 vCPU | 85 GB | 1 | 2 | 3 | ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 10 posts, newest first. Each one follows in full after the list. - [DayZ bikey files and signature checks: fixing mod kicks](https://www.renode.space/blog/dayz-bikeys-and-signature-verification) (2026-10-15): How DayZ mod keys work: the keys folder, .bikey and .bisign files, verifySignatures, -mod vs -serverMod, and fixing signature kicks after a mod update. - [How to buy or rent a DayZ server without overpaying](https://www.renode.space/blog/how-to-buy-a-dayz-server) (2026-10-15): What to check before you rent a DayZ server: PC or console, slots versus RAM, mod-heavy needs, the Steam login, location, backups and a first-day checklist. - [DayZ admin tools and BattlEye RCon](https://www.renode.space/blog/dayz-admin-tools-and-rcon-battleye) (2026-10-07): Set up BattlEye RCon on a DayZ server, use its commands and bans, pick an RCon tool, and add an in-game admin mod such as VPP Admin Tools or COT safely. - [DayZ custom maps: Deer Isle and Namalsk](https://www.renode.space/blog/dayz-custom-map-deerisle-namalsk) (2026-10-07): How to run a DayZ community map: terrain mods, mission folders, the template line, Deer Isle and Namalsk step by step, persistence, loot files and updates. - [DayZ Expansion server: modules and traders](https://www.renode.space/blog/dayz-expansion-mod-server) (2026-10-07): Install DayZ Expansion on a server in the right order: dependencies, Bundle or single modules, mission files, settings JSON, market traders, AI and updates. - [DayZ serverDZ.cfg settings, line by line](https://www.renode.space/blog/dayz-server-cfg-explained) (2026-10-07): Every serverDZ.cfg setting on a DayZ server, grouped by purpose: access, time, logging, network, queue and persistence, plus the mistakes that break it. - [DayZ server wipes: full and partial resets](https://www.renode.space/blog/dayz-server-wipes-and-persistence) (2026-10-07): How DayZ persistence works: the storage folder, players.db, economy.xml and territory flags, plus how to run full, character-only and world-only wipes safely. - [DayZ server RAM: players, mods and economy](https://www.renode.space/blog/how-much-ram-does-a-dayz-server-need) (2026-10-07): DayZ server memory by slots and mod list, how the central economy and persistence drive it, the serverDZ.cfg logging that proves it, and why restarts are routine. - [DayZ types.xml: editing the loot economy](https://www.renode.space/blog/dayz-types-xml-and-loot-economy) (2026-09-21): How DayZ loot spawns: types.xml nominal, min, lifetime and restock, usage and tiers, events.xml, custom ce folders, and editing without emptying the map. - [DayZ server setup, mods and economy](https://www.renode.space/blog/dayz-server-and-mods) (2026-07-24): Running a DayZ server end to end: serverDZ.cfg, ports, mods and .bikey files, types.xml and the loot economy, restarts, persistence and the errors people hit. --- ### DayZ bikey files and signature checks: fixing mod kicks Published 2026-10-15 by RE:NODE Team. https://www.renode.space/blog/dayz-bikeys-and-signature-verification A DayZ player kicked at the loading screen with a signature error almost always means one thing: a mod they loaded is signed with a key the server does not have in its `keys` folder. The fix is to copy the `.bikey` file from that mod's own `keys` folder into the server's `keys` folder and restart, and to do it again every time the mod updates. Everything else in this guide explains why that works, how to tell which mod is missing its key, why server-only mods do not need one, and how to keep keys from going stale so the problem stops coming back after every Workshop update. This post covers only keys and signatures. For installing the server, ports and the loot economy, start with [the full DayZ server guide](https://www.renode.space/blog/dayz-server-and-mods); for every line of the config file, see [serverDZ.cfg explained](https://www.renode.space/blog/dayz-server-cfg-explained). #### What signature verification actually checks DayZ content ships as `.pbo` files - packed archives of models, textures, configs and scripts - inside a mod's `addons` folder. Next to each `.pbo` sits a `.bisign` file: a signature made by the mod author with a private key that never leaves the author's machine. The matching public key is the `.bikey`, which the author ships in the mod's `keys` folder so that servers can check the signatures. When a player connects to a server with `verifySignatures = 2`, the engine asks the client to prove that every `.pbo` it has loaded carries a valid signature from a key the server trusts. "Trusts" means one thing only: a `.bikey` with that name and content is sitting in the server's `keys` folder. If any loaded `.pbo` has no signature, a broken signature, or a signature from a key the server does not hold, the player is kicked. Three files, three jobs: | File | Where it lives | What it is | | --- | --- | --- | | `.pbo` | `@Mod/addons/` | The packed content itself | | `.bisign` | `@Mod/addons/`, beside each `.pbo` | The author's signature for that one `.pbo` | | `.bikey` | `@Mod/keys/`, then copied to the server's `keys/` | The public key that checks those signatures | A signature file is named after both the `.pbo` and the key that signed it, so a mod author whose key is called `MyMod` produces pairs like these: ```text @MyMod/ addons/ mymod_core.pbo mymod_core.pbo.MyMod.bisign mymod_items.pbo mymod_items.pbo.MyMod.bisign keys/ MyMod.bikey meta.cpp mod.cpp ``` The important consequence is that the server does not compare files byte for byte against its own copy. It checks that the client's files were signed by someone the server trusts. That is why the system catches a player who edited a `.pbo` to make walls transparent - the edited file no longer matches its signature - but also why trusting a key is a decision with weight: anything signed with that key will be accepted. It is also worth being clear about who does the kicking. Signature verification is part of the game engine, configured in `serverDZ.cfg`, and it works whether or not BattlEye is running. BattlEye is a separate anti-cheat layer that watches running processes and memory. Players and many guides blame BattlEye for signature kicks because the two happen at the same moment of the connection, but no BattlEye setting will fix a missing key. [BattlEye and Easy Anti-Cheat on servers](https://www.renode.space/blog/battleye-and-easy-anti-cheat-on-servers) draws that line across games. #### verifySignatures and the settings around it The setting is a single line in `serverDZ.cfg`: serverDZ.cfg: ```cfg verifySignatures = 2; allowFilePatching = 0; forceSameBuild = 1; ``` Bohemia's own documentation for DayZ describes `2` as the only supported value. Older Arma games had a weaker mode `1` that DayZ does not use, and `0` switches checking off. Running with `0` is occasionally suggested on forums as a quick fix for key errors. It does stop the kicks, in the same way that removing a lock stops you losing the key: every client can now load any modified file it likes, and your server will happily accept a player whose local copy of a mod has been altered to show loot through walls. Leave it at `2` and fix the key. The two settings beside it are part of the same picture: - `allowFilePatching = 0` refuses clients started with the `-filePatching` parameter, which lets the game load loose unpacked files from disk instead of signed `.pbo` files. Loose files have no signatures, so file patching is a hole straight through signature checking. Only a mod developer testing locally has a reason to turn it on. - `forceSameBuild = 1` rejects clients on a different game build. That is a version check, not a signature check, but it produces kicks at the same moment, and after a game patch it is often the real cause of what players describe as "the signature thing again". A key detail that saves time: the check is about what the client loads, not what the server runs. The server reads its own mods without checking signatures against its `keys` folder. The `keys` folder is purely the list of public keys a client's files are allowed to be signed with. #### The keys folder The server's `keys` folder sits in the server root, beside `DayZServer_x64.exe` on Windows or `DayZServer` on Linux, and next to the `@Mod` folders. A fresh install already contains one file: ```text keys/ dayz.bikey ``` `dayz.bikey` is Bohemia's own key, which signs the base game's `.pbo` files. Never delete it. Without it every client fails verification on the vanilla data, and the server becomes impossible to join even with no mods at all. Every client-loaded mod adds at least one key. A modded server's folder ends up looking like this: ```text keys/ dayz.bikey CF.bikey Dabs.bikey Expansion.bikey VPPAdminTools.bikey BuilderItems.bikey ``` Names are whatever the author chose, so they do not always match the mod's folder name. A mod named `@SomeWeaponsPack` can ship `SWP_v3.bikey`. One author with several mods often signs them all with one key, and a large mod split into several Workshop items, such as DayZ Expansion, can ship the same key in each part. Copying a key that is already there is harmless - it overwrites an identical file. > [!WARNING] > A `.bikey` in `keys` is a statement of trust: anything signed with it is accepted. Take keys only from the mod's official Workshop item, never from a re-upload or a file someone posts in Discord, and remove keys for mods you no longer run. Some mods ship their key in a folder called `Keys` or `key` instead of `keys`. On Windows that makes no difference. On a Linux server, paths are case-sensitive, so a script that only looks in `keys/` misses them. Search for the file extension rather than trusting a folder name. #### Installing a mod's key, step by step For one new client-side or client-and-server mod, the order is: 1. Stop the server. Keys and the mod list are read at start-up. 2. Download the mod. With SteamCMD that is the client app id, `221100`, not the server's `223350`. The files land in `steamapps/workshop/content/221100//`. 3. Copy or link that folder into the server root under a readable name such as `@SomeMod`. Workshop folders are named by number, and a launch line full of numbers is unmaintainable. 4. Copy every `.bikey` from inside the mod into the server's `keys` folder. 5. Add the mod to `-mod=` in dependency order, frameworks first. 6. Start the server, then join it yourself through the DayZ Launcher before telling anyone it is live. ```bash $ steamcmd +force_install_dir /home/dayz/server +login \ +workshop_download_item 221100 1559212036 +quit $ cd /home/dayz/server $ cp -r steamapps/workshop/content/221100/1559212036 @CF $ find @CF -iname '*.bikey' -exec cp -v {} keys/ \; ``` On a server with many mods, copy every key in one pass rather than mod by mod. From the server root on Linux: ```bash $ find . -maxdepth 3 -path './@*' -iname '*.bikey' -exec cp -v {} keys/ \; ``` On Windows, from the server folder in PowerShell: ```text Get-ChildItem -Path .\@* -Recurse -Filter *.bikey | Copy-Item -Destination .\keys\ ``` On a panel host you do the same thing with the file manager or SFTP: open each `@Mod/keys/` folder, copy the file, paste it into `keys/` in the server root. It takes a minute per mod, and it is the minute that decides whether anyone can join. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers getting connected, and for a mod list of more than a handful, dragging every key from a local copy of the mods into `keys/` in one upload is faster than clicking through each folder. The step people skip is the last one. A server that starts cleanly has proved only that the server can read its mods. Joining with the launcher proves that a client with the advertised mod list passes the check, which is the thing you actually care about. #### -mod vs -serverMod: which mods need keys DayZ has two launch parameters for mods, and the difference decides whether a key is needed at all: | Parameter | Loaded by | Needs a key in `keys/` | | --- | --- | --- | | `-mod=` | Server and every client | Yes, every mod in the list | | `-serverMod=` | Server only | No | ```text -mod=@CF;@Dabs Framework;@DayZ-Expansion-Core;@BuilderItems -serverMod=@MyServerTweaks;@LootLogger ``` Mods in `-mod=` are advertised to the DayZ Launcher, which subscribes players to them and starts the game with a matching list. Every one of those mods is loaded on the client, so every one is checked, so every one needs its key on the server. Mods in `-serverMod=` are never advertised and never loaded by clients. Since clients do not have them, there is nothing to verify, and their keys can stay out of `keys/`. Typical server-only mods are loot or economy tweaks done in script, logging tools, and the server half of mods that ship a separate server package. If the author says a mod is server-side, it belongs here. The mistakes go both ways, and each produces a different symptom: - **A client mod placed in `-serverMod=`.** The server loads it, players never get it, and anything it adds is invisible or broken for them: missing items, clothing showing as an error texture, menus that do not open. No signature kick, because the client never loads the mod. - **A server-only mod placed in `-mod=`.** Every player is made to download it, and if it has no key in `keys`, every player is kicked. Some server-only mods are not signed at all, because their authors never expected a client to load them - which turns the mistake into a guaranteed kick for everyone. Mods can also be client-only: interface tweaks, map overlays, sound replacements that the server does not need to run. These are not in either parameter. If you want to allow one, put its `.bikey` in `keys/`, and players who have it loaded will pass verification. Players without it are unaffected. This is the only correct way to permit an optional client mod, and also the reason to be sparing: every extra key widens what the server accepts. #### Updating mods without locking everyone out Most signature kicks on established servers happen the day a mod updates, and the cause is a mismatch between what the server has and what the launcher gives players. When a Workshop mod updates, players subscribed to it receive the new version automatically through Steam. If the server still has the old version, two things can break: - **The author signed the update with a new key.** Some authors generate a fresh key for each release, or rotate their key after a version change. The new `.bisign` files on the client point to a key the server has never seen. Every player with the update is kicked until the new `.bikey` is copied into `keys/`. - **Server and client versions differ in content.** Even with the same key, a server running an older version and clients running a newer one disagree about classes and data, which shows up as kicks, missing items or crashes on joining. The routine that prevents both: 1. Stop the server. 2. Update every mod on the server to the current Workshop version, not just the one you heard about. With SteamCMD that is `workshop_download_item` again for each id, adding `validate` if a download looks incomplete. 3. Copy the mod folders over the old ones in the server root. 4. Copy every `.bikey` again, from every mod, using the one-pass command above. 5. Start the server, read the start of the log for errors, and join through the launcher yourself. Step 4 is the habit to build: copy all keys after any update, whether or not you believe the key changed. It costs seconds and removes the most common reason a server goes unjoinable for an evening. Old keys pile up as authors rotate them. A stale key does no harm to joining, but it does mean the server still trusts signatures made with a key the author may have retired - in rare cases because it leaked. Once or twice a year, clear the folder back to `dayz.bikey`, copy every current key again, and you are left with exactly the set you need. The other half is not updating at a bad moment. A DayZ game patch can break mods until their authors rebuild them, and on patch day the launcher hands players new mod versions as fast as authors publish them. Updating the server a few hours after the authors, when the mod list has settled, beats updating it the minute the game patches. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) has the rollback routine, and [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers) explains how Workshop downloads behave server-side across games. ```diagram title: What happens to a signed mod when a player connects author = Mod author | signs .pbo files workshop = Steam Workshop | @Mod with keys/ client = Player's game | loads .pbo + .bisign server = DayZ server | verifySignatures 2 keys = keys/ folder | .bikey files author -> workshop : .pbo, .bisign, .bikey workshop -> client : launcher download workshop --> keys : admin copies .bikey client -> server : connect server -> keys : signer trusted? ``` #### Diagnosing a signature kick The kick message on the player's screen is short, and its wording has changed between versions, but it usually mentions a signature check, modified data, or a specific file. The useful detail is the file name, when it is shown: a `.pbo` name points straight at the mod that failed. Work through it in this order: 1. **Is it everyone or one player?** If every player is kicked, the server is missing a key, or a server-only mod has ended up in `-mod=`. If only one player is kicked, their local files are the problem. 2. **Read the server log.** The kick is logged in the `.RPT` file and the console log in the profiles folder at the moment it happens, usually naming the player and the file or reason. Search for the player's name around the time they tried to join. 3. **Find the mod.** Match the `.pbo` name to a mod folder: search every `@Mod/addons/` folder for that file. 4. **Check its key.** Open that mod's `keys` folder, note the `.bikey` name, and confirm the same file is in the server's `keys/`. If a file with that name is there but the mod was recently updated, copy it again anyway - a rotated key can keep the same name. 5. **Check the version.** Compare the mod's last update time on the Workshop with when the server's copy was updated. If the Workshop is newer, update the server. For one player on their own, the fix is on their machine: - In the DayZ Launcher, open the mod list, unsubscribe from the failing mod and subscribe again, or use the launcher's repair option. Verifying through the launcher rather than through Steam's game properties makes sure the mods are checked too. - Make sure they are not running a local edited copy of a mod, or extra client mods whose keys the server does not hold. Players who play on several servers often have a pile of mods loaded that your server never asked for. - If they added `-filePatching` to their launch options for some other server or a modding tutorial, remove it. If none of this finds it, start the server with only `@CF` or with no mods at all and join. If vanilla works, add mods back in groups until the kick returns. It is slow, but it always ends with a name. #### Signing your own repacks Server owners sometimes edit a mod - changing a config inside a `.pbo`, merging small mods, or retexturing an item. The moment you repack a `.pbo`, its original `.bisign` no longer matches, and every client loading your version is kicked. The answer is to sign it yourself, which is what the system is designed for. DayZ Tools, free on Steam, includes the DS utilities for this: `DSCreateKey` generates a key pair and `DSSignFile` signs a `.pbo` with the private half. Addon Builder in DayZ Tools can also sign while it packs, given a private key. The pair consists of a `.biprivatekey`, which signs, and a `.bikey`, which you ship. - Put your `.bikey` in the server's `keys/` folder and in your repack's own `keys/` folder. - Never share or upload the `.biprivatekey`. Anyone with it can sign files your server will accept. - Respect the original author's terms. Many mods forbid repacking outright, and publishing someone else's work re-signed under your key is how servers get Workshop items taken down. For most servers the better route is to avoid repacking entirely: change behaviour through the mission files, the mod's own config in the profiles folder, or a small server-side mod in `-serverMod=`, which needs no key at all. [The DayZ Expansion server guide](https://www.renode.space/blog/dayz-expansion-mod-server) shows how far that gets you with one of the largest mods there is. #### Keys on RE:NODE On a RE:NODE DayZ server the `keys` folder and every `@Mod` folder are reachable through the panel's file manager and over SFTP, with credentials per server. The file manager unpacks archives in place, so a mod uploaded as a zip can be extracted straight into the server root before you copy its key. The mod list goes in the startup settings on the Startup tab. There is no whitelist of allowed mods - you upload what you choose, and you choose which keys to trust. Before a mod update, take a backup from the panel. Backup slots are on every DayZ plan, a backup can be restored with a button, and restoring the previous state is the quickest way out of an update that went wrong. The DayZ install itself needs your own Steam login, entered on the Setup tab after the server is created, as with any host that installs DayZ for you. #### FAQ ##### Where do I put a DayZ .bikey file? In the `keys` folder in the server root, beside the server executable and the `@Mod` folders - not inside the mod, and not in the profiles folder. Every mod listed in `-mod=` needs its key there. Restart the server after adding keys. ##### Can I just set verifySignatures to 0 to stop the kicks? You can, and it will stop them, but it also stops the server rejecting modified files, so any player can load an edited `.pbo` that shows loot through walls or removes recoil. Fixing the missing key takes a minute and keeps the protection. ##### Do server-side mods need a bikey? No. Mods loaded with `-serverMod=` are never loaded by clients, so nothing is verified against them. Keys are only for what clients load: everything in `-mod=`, plus any optional client-only mod you choose to allow. ##### Why did the server break after a mod update when nothing else changed? The mod's author probably signed the new version with a new key, so players who received the update through the launcher now carry signatures the server cannot check. Update the mod on the server and copy every key again. ##### Why is only one player getting kicked? Their local copy differs: a corrupted or outdated download, a mod they edited, an extra client mod your server has no key for, or `-filePatching` in their launch options. Have them repair or re-subscribe through the DayZ Launcher. ##### Can I delete dayz.bikey? No. It is the key for the base game's own files. Without it, every client fails the signature check on vanilla data and nobody can join, modded or not. DayZ servers on RE:NODE start at 6 GB with three port allocations, SFTP and an in-browser file manager for the keys folder and your mods, and backup slots on every tier, restored with one button when an update goes wrong. The install waits on the Setup tab for your own Steam login. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### How to buy or rent a DayZ server without overpaying Published 2026-10-15 by RE:NODE Team. https://www.renode.space/blog/how-to-buy-a-dayz-server Before you rent a DayZ server, answer four questions: are your players on PC or on console, how many mods will you run, where do your players live, and do you have a Steam account you are willing to hand to a host. Those answers decide almost everything else. A PC server for a private group or a 30 to 40-slot vanilla community needs about 6 GB of memory, two real cores and 35 GB of disk. A server built around Expansion, traders and AI needs 10 to 12 GB and more disk than people expect. Console players cannot join a PC server at all. And the slot number printed on a plan is the least informative thing on the page, because DayZ's cost is driven by mods, persistence and one busy CPU thread, not by how many people are allowed in. This guide is about the buying decision: what to look for, what to avoid, and what to do on the first day so the money is not wasted. The detail on memory is in [how much RAM a DayZ server needs](https://www.renode.space/blog/how-much-ram-does-a-dayz-server-need), the install and mods are in [the DayZ server and mods guide](https://www.renode.space/blog/dayz-server-and-mods), and every config key is in [serverDZ.cfg explained](https://www.renode.space/blog/dayz-server-cfg-explained). #### PC or console: the decision that comes first DayZ has no crossplay. A PC server accepts PC players on Steam, an Xbox server accepts Xbox players, and a PlayStation server accepts PlayStation players. Nothing you configure and nothing a host sells changes that, so the platform your group plays on decides what you are shopping for. **PC servers** are the open market. The server application (`DayZ Server`, Steam app id `223350`) can be installed by anybody with a Steam account that owns the game, on their own hardware or on any host. You get the files, the mission folder, the mods, BattlEye and full control. **Console servers** are a different and much narrower product. Xbox and PlayStation community servers are not something you can install yourself: they are rented through Bohemia's licensed console partner, which has for years been Nitrado. You cannot run one at home, you cannot move one to another host, and you cannot run mods, because console clients cannot load them. What you can usually change is the economy and gameplay files - `types.xml`, `globals.xml`, `cfggameplay.json` and similar - through the partner's web interface. Console arrangements are commercial agreements and can change, so check Bohemia's current information before you pay for one. The honest summary for console groups: if anybody tells you they sell a DayZ server your PlayStation friends can join alongside PC players, they are wrong. If you need a console server, buy it from the licensed partner, and spend your effort on the economy files, since that is the part you control. ```diagram title: Which DayZ server you can actually buy group = Your players pc = PC players | Steam console = Console players | Xbox or PlayStation partner = Console partner | no mods, XML edits rented = Rented PC server | any host home = Own hardware | ports, uptime, power group -> pc group -> console console -> partner : only option pc -> rented pc -> home ``` The rest of this guide is about PC servers, where the choice is real. #### Slots or RAM: how DayZ servers are priced Hosts price game servers in one of two ways. **Per slot.** You pick a number of players and the price scales with it. It is easy to understand and it maps badly onto DayZ, because a slot costs almost nothing directly. What costs memory and CPU is the central economy, persistent bases, infected counts and the mod list. A 60-slot vanilla server can use less memory than a 30-slot server running Expansion's market and AI. A slot-priced plan either hides the resources behind the number - in which case you do not know what you are buying - or charges you for player capacity you may not need while giving you too little of the resource you do. **Per resource.** You buy memory, CPU and disk, and set `maxPlayers` in `serverDZ.cfg` yourself. This matches how DayZ actually behaves, and it means a quiet private server and a crowded public one on the same plan are the same price. The catch is that you have to know what you need, which is what the table below is for. Whichever model a host uses, find these four numbers before paying. If a plan page does not state them, ask; if the host will not say, that is your answer. | What to find | Why it matters for DayZ | | --- | --- | | Memory in GB | Mods, economy and persistence live here | | CPU share, and whether it is a hard limit | Server FPS is one busy main thread | | Disk in GB | Mods add 10-15 GB to a 3 GB install | | Ports included | Game, query and RCon are separate | `maxPlayers` is a line in a text file. A plan that "allows 100 slots" on 4 GB has told you nothing about whether 100 people can play on it; the answer is no. [How many players fit on a server](https://www.renode.space/blog/how-many-players-fit-on-a-server) goes through the reasoning for any game. #### Sizing: what to buy for what you will run These ranges come from the [DayZ RAM guide](https://www.renode.space/blog/how-much-ram-does-a-dayz-server-need), which explains where each gigabyte goes. Disk is the column people skip and regret. | Server | RAM and CPU | Disk | | --- | --- | --- | | 10-20 slots, vanilla | 4-6 GB, 2 cores | 20-30 GB | | 30-40 slots, vanilla or light mods | 6-8 GB, 2-3 cores | 30-40 GB | | 40-60 slots, vanilla | 8-10 GB, 3+ cores | 35-50 GB | | 30-50 slots, Expansion-scale mods | 10-12 GB, 3+ cores | 50-85 GB | How to use it: - **Size for the mod list, not the slot count.** Write down the mods you intend to run before choosing a plan. Community Framework and an admin tool are cheap. Expansion with its market, vehicles and AI modules, plus a weapons pack and a clothing pack, puts you in the bottom row whatever your player count. - **Size for month two, not day one.** Persistence grows with every base, stash and vehicle. A server that is comfortable in its first week can be tight five weeks later. - **Buy CPU deliberately.** A DayZ server's health is its logged server FPS. Above about 30 is healthy; below about 15, players notice rubber-banding and doors that need two attempts. Memory you do not use does nothing for that number. [Game server CPU requirements](https://www.renode.space/blog/game-server-cpu-requirements) explains why one fast core beats several slow ones. - **Leave disk headroom for mod updates.** Workshop downloads, a second copy of a mod folder you are testing, logs and the `.ADM` file all land on the same disk. The cheapest correct purchase is usually the tier that fits your mod list with a margin of about 15% memory at the end of a restart cycle. If the host lets you move up a tier on the same server, starting one tier lower and measuring is reasonable; if moving means reinstalling, start one tier higher. #### Mod-heavy servers: what the plan must allow Most DayZ communities are modded, and mods are where cheap plans and restrictive hosts fall down. Before buying, make sure you will be able to do each of these. 1. **Upload folders, not just files.** A mod is an `@ModName` folder containing addons, keys and sometimes a config. You need SFTP or a file manager that takes folder uploads, because thirty mods uploaded file by file is an evening gone. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers both. 2. **Copy keys.** Every mod's `.bikey` must sit in the server's `keys` folder, or BattlEye kicks players with a signature error. If a host's mod system manages this for you, check that it does it again after every mod update. 3. **Edit the launch line.** You need control over `-mod=` and `-servermod=`, including the order, because frameworks such as `@CF` must load before the mods that depend on them. 4. **Edit the mission folder.** Mods that add items need economy entries, ideally in a custom folder registered in `cfgeconomycore.xml`. A host that hides the mission folder hides the place most DayZ administration happens. 5. **Choose when to update.** A DayZ patch breaks mods until their authors rebuild them. You want to decide when mods update, not wake up to a server nobody can join. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is the plan for that day. A host's mod picker is convenient for the popular mods, but check that you can still add a mod it does not list, by hand, without a ticket. If the only route is their list, your server is limited to their list. Expansion and community maps deserve their own planning. Expansion is modular, and running only the modules you use makes a large difference to memory and CPU - see [the DayZ Expansion server guide](https://www.renode.space/blog/dayz-expansion-mod-server). A community map such as Namalsk or Deer Isle brings its own mission folder and adds a gigabyte or two; [running Deer Isle or Namalsk](https://www.renode.space/blog/dayz-custom-map-deerisle-namalsk) covers what changes. #### The Steam login requirement Unlike most Steam games, the DayZ server cannot be downloaded with an anonymous SteamCMD login. The install needs a Steam account that owns DayZ: ```bash $ steamcmd +force_install_dir /home/dayz/server +login \ +app_update 223350 validate +quit ``` Every host that installs a PC DayZ server is doing that with an account you supply, or with one of their own. That has consequences you should think about before you pay. - **Use a spare account.** Create a separate Steam account, buy DayZ on it, and use it only for servers. It costs one copy of the game. In exchange, the account you give a host has nothing else on it: no inventory, no payment method, no friends list, no other games. - **Expect the credentials to be stored as typed.** A host needs the password to update the server later, so it is kept in a form that can be used, not as a one-way hash. That is normal and unavoidable. It is exactly why the account should be a spare. - **Steam Guard.** SteamCMD asks for a Steam Guard code the first time an account logs in from a new machine. Read what your host's install step asks for and have the code ready; after the first login it usually does not ask again. - **Change the password if anything changes.** If you hand the server to another admin, leave a host, or suspect a leak, change the spare account's password and update it on the server. Workshop mods are downloaded against the client app id, `221100`, with the same login. [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers app ids, `validate` and beta branches if you are doing any of this by hand. > [!WARNING] > Never give a host, a fellow admin or a server tool the Steam account you buy things with. A game-server install has no reason to touch an account with a payment method on it, and you cannot un-share a password. On RE:NODE the server is created as soon as payment clears, and the DayZ install then waits on the Setup tab until you enter that Steam login. The panel stores it as typed, which is one more reason to use the spare. #### Location and ping DayZ is UDP and latency-sensitive, and a player with a bad connection desyncs for the people around them, not only for themselves. Put the server close to the bulk of your players. A server in central Europe serves Europe well and the eastern United States acceptably; it is the wrong choice for a group in Australia or on the American west coast, however cheap it is. [Game server ping by region](https://www.renode.space/blog/game-server-ping-by-region) has the rough distances, and [choosing where your server lives](https://www.renode.space/blog/choosing-where-your-server-lives) covers the decision in general. Two settings in `serverDZ.cfg` relate to this: serverDZ.cfg: ```cfg maxPing = 200; hostname = "EU | Chernarus | Vanilla+ | 3-hour restarts"; ``` `maxPing` kicks players whose ping stays above the value in milliseconds, which protects everybody else from a player who would rubber-band. Putting the region at the front of `hostname` lets players filter themselves out before they join. RE:NODE runs in one location, Germany, on hardware we run. That suits European communities and is not the right buy for a group whose players are mostly in Asia, Oceania or the Americas. Pick a host near your players rather than the other way round. #### Backups: what a host should give you DayZ keeps every base, tent, stash, vehicle and character in `storage_` inside the mission folder. That folder is your server's entire history. Lose it and the world is wiped; corrupt it and `storageAutoFix = 1` may save you, or may not. The mission XML you spent evenings tuning is the second thing worth protecting. What to look for in a plan: - **Backups included, not an add-on.** You will want one before every mod update and every game patch. - **Stored somewhere else.** A backup on the same disk as the server protects against a bad edit, not against losing the machine or deleting the server. - **Restorable without a ticket,** and downloadable, so you can keep your own copy. - **Schedulable,** so the backup runs just before the scheduled restart rather than when somebody remembers. Then restore one. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) explains why: a backup nobody has restored is a hypothesis. [Game server backup strategy](https://www.renode.space/blog/game-server-backup-strategy) covers how many to keep and when to take them, and [DayZ wipes and persistence](https://www.renode.space/blog/dayz-server-wipes-and-persistence) explains what is in `storage_1` and what a partial wipe can remove. Every DayZ plan on RE:NODE includes two backup slots. Backups run on demand or on a schedule, restore with a button, can be downloaded, can be locked so rotation does not remove them, and are stored off the machine they protect. One caution that applies there and almost everywhere: deleting a server deletes its backups, locked ones included. Download a copy before you cancel anything. #### Plans and offers to avoid Most bad DayZ purchases fall into a short list. - **Slot-priced plans that do not state memory and CPU.** You cannot size a DayZ server on a slot count. If the resources are not on the page, you are buying a guess. - **Small memory with a big slot number.** "60 slots" on 4 GB is a 60-player config line on a server that will struggle with a modded 20. - **Small disk for a modded server.** Under about 30 GB, a twenty-mod list, its updates and a season of logs will fill it. A full disk stops saves, and a DayZ server that cannot write persistence is a server about to lose a raid's worth of bases. - **No access to files.** If you cannot reach `serverDZ.cfg`, the mission folder, `keys` and the profiles logs, you cannot administer DayZ. A config form with ten fields is not a substitute. - **A year paid up front, on the first day.** Longer terms are cheaper per month at most hosts, including ours. They are worth it after you have run the server through a busy weekend and know the tier is right, not before. A refund is a conversation; a monthly term is a decision you can revisit. - **The wrong continent.** A cheap server far from your players costs you the players. - **"Unlimited" anything.** Memory, CPU and bandwidth all have limits somewhere. A plan that names its limits is one you can plan around. - **A shared Steam account you do not control.** Some offers install with an account of their own. That works until the account is changed or banned, and then your server cannot update. Know whose login is doing the install. Also be wary of buying the top tier "to be safe". Memory you do not use does not raise server FPS. If the server is slow while memory has room, the fix is fewer infected, less AI or a lighter mod list - [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) shows how to tell which is the limit. #### A first-day checklist The first evening sets up the server you will live with. Do these in order. 1. **Install with the spare account.** Enter the Steam login, wait for the install to finish, and start the server once vanilla so it generates its folders and logs. 2. **Back up the clean install.** Before any edit, take a backup and lock it if your host allows. It is your copy of the untouched mission folder and config. 3. **Set identity and access in `serverDZ.cfg`.** `hostname` with region and map, `passwordAdmin` as a long random string, `password` or `enableWhitelist` for a private server, and a realistic `maxPlayers`. 4. **Match the ports.** Check that `-port` and `steamQueryPort` match the ports your host allocated. A server that is joinable by IP but missing from the launcher list almost always has the query port wrong - see [game server ports explained](https://www.renode.space/blog/game-server-ports-explained). 5. **Set the RCon password.** It lives in `BEServer_x64.cfg` in the BattlEye folder inside the profiles directory, separate from `passwordAdmin`. Make it long and random, and read [RCON safely](https://www.renode.space/blog/rcon-safely). [DayZ admin tools and BattlEye RCon](https://www.renode.space/blog/dayz-admin-tools-and-rcon-battleye) covers the clients. 6. **Turn on the logging you will need.** The block after this list gives you the numbers for every sizing decision later. 7. **Add mods one at a time.** Upload the folder, copy its key, add it to `-mod=` in dependency order, restart, join, read the log. Adding twenty at once turns one mistake into an evening of guessing. 8. **Schedule the restart cycle.** Every three to four hours is the DayZ norm. Put a backup just before one restart a day. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers choosing the interval, and `db/messages.xml` can warn players before each one. 9. **Watch one busy evening.** Read the logged server FPS and memory across a whole cycle before you change tier in either direction. serverDZ.cfg: ```cfg logAverageFps = 300; logMemory = 300; logPlayers = 300; timeStampFormat = "Full"; ``` The values are intervals in seconds. With them set, the `.RPT` file in the profiles folder records server FPS, memory and player count every five minutes, which is all the evidence a sizing decision needs. > [!TIP] > Join your own server through the DayZ Launcher before inviting anybody. The launcher reads the advertised mod list exactly as your players will, so if it fails for you, it fails for them. #### FAQ ##### How much does a DayZ server cost to rent? It depends on the memory and CPU you need rather than the slot count. A vanilla or lightly modded PC server needs about 6 GB, and a heavily modded one 10 to 12 GB, so compare plans at those sizes. A cheaper plan with less memory will not run the server you want. ##### Can PC and console players share a DayZ server? No. DayZ has no crossplay, so PC, Xbox and PlayStation servers are separate. Console community servers are rented through Bohemia's licensed console partner and cannot run mods. ##### Do I really need to give a host my Steam password? The DayZ server cannot be installed anonymously, so a Steam account that owns the game has to log in. Give the host a spare account that owns DayZ and nothing else, never your main one, and change its password whenever admins or hosts change. ##### Is it cheaper to host DayZ at home? The hardware may already be paid for, but you need a CPU with a fast core, enough memory, upload bandwidth, port forwarding through a router that is not behind CGNAT, and a machine left on. [Hosting at home vs renting](https://www.renode.space/blog/self-hosting-a-game-server-at-home-vs-renting) compares the real costs. ##### Can I move my DayZ server to another host later? On PC, yes. Copy the mission folder including `storage_`, `serverDZ.cfg`, the `keys` folder and your mod list, then install the same game build and mods on the new host. Console servers cannot be moved off the partner's platform. ##### Should I start with the biggest plan? No. Start with the tier that fits your mod list, turn on `logMemory` and `logAverageFps`, and measure a full busy cycle. Move up if memory is close to the limit; if FPS is low with memory to spare, a bigger plan will not help. DayZ servers on RE:NODE run from 6 GB to 12 GB in Germany, with three port allocations, SFTP and an in-browser editor for the config and mission files, two backup slots on every tier and a Schedules tab for the restart cycle. The install waits on the Setup tab for your own Steam login, and moving up a tier keeps the server you already have. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ admin tools and BattlEye RCon Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/dayz-admin-tools-and-rcon-battleye Vanilla DayZ gives an administrator almost nothing in game. Remote administration comes from BattlEye RCon - configured in `BEServer_x64.cfg`, reached with an external client, good for listing players, kicking, banning, broadcasting and shutting down - and everything visual (teleport, spectate, spawn items, a map of players) comes from an admin mod such as VPP Admin Tools or Community Online Tools. Most servers end up running both: RCon for moderation that works even when nobody is logged in, and a mod for the things you can only do from inside the world. This guide sets up the first, explains its commands and ban files, compares the usual RCon tools, and shows how to add an admin mod without handing your server to whoever reads its config. If the server itself is not running yet, start with [the full DayZ server guide](https://www.renode.space/blog/dayz-server-and-mods); for the main config file, see [serverDZ.cfg explained](https://www.renode.space/blog/dayz-server-cfg-explained). #### The three layers of DayZ administration It helps to know which tool does what before installing anything, because each one has different credentials and a different blast radius. | Layer | Configured in | What it can do | | --- | --- | --- | | In-game `#login` | `passwordAdmin` in `serverDZ.cfg` | A few chat commands: kick, shut down | | BattlEye RCon | `BEServer_x64.cfg` | Players, kicks, bans, messages, shutdown, from anywhere | | Admin mod | The mod's own files in the profiles folder | Teleport, spectate, spawn, heal, ESP, map | The in-game layer is barely worth using: type `#login` and the `passwordAdmin` value into chat and you can kick a player or shut the server down, but you have to be connected and in the world to do it. RCon is the one you will use most. It works over the network, from your desktop or a phone, while the server is full and you are not playing. An admin mod is the only way to see and touch the world - a player stuck in a rock, a vehicle clipped under the map, a base that needs inspecting after a dispute. ```diagram title: Who talks to what on an administered DayZ server you = You | RCon client mod = Admin mod | in-game menu be = BattlEye server | RCon on UDP dayz = DayZ server | game on UDP 2302 logs = Profiles folder | .ADM, bans.txt you -> be : password, commands be -> dayz mod -> dayz : signed client + server dayz -> logs be -> logs : bans ``` #### Setting up BattlEye RCon BattlEye ships with the server and is on by default. Its working folder is created inside your profiles folder, so with `-profiles=profiles` on the launch line it is `profiles/BattlEye/`. A `-BEpath=` launch parameter can move it, which is worth knowing when you are looking for a file that is not where a guide says it is. The RCon settings live in a plain text file in that folder: profiles/BattlEye/BEServer_x64.cfg: ```text RConPassword a-long-random-password-without-spaces RConPort 2310 RestrictRCon 0 ``` | Line | What it does | | --- | --- | | `RConPassword` | The only authentication RCon has. No spaces | | `RConPort` | UDP port the RCon listener binds to | | `RConIP` | Optional: bind to one address instead of all | | `RestrictRCon` | `1` allows only BattlEye commands, not `#` server commands | There is no universal default port. Pick one that is actually allocated to your server and not used by anything else - on a panel host that means a port listed on the server's Network tab. The game uses `2302`, the query port is usually `2305`, so a free port in the same allocation is the natural choice. Two details catch people: - **The file is copied at start.** When the server starts, BattlEye works from a copy named `BEServer_x64_active_` followed by a random suffix, and removes it again on a clean stop. Edit the original `BEServer_x64.cfg`, with the server stopped. If a crash leaves stale `_active_` files behind, delete them before the next start so there is no doubt about which one is current. - **RCon is UDP.** A firewall rule that opens the port on TCP only does nothing. If your RCon client times out while the game itself is fine, check the protocol first. `RestrictRCon 1` is a reasonable setting when you hand RCon to moderators: they keep kicks, bans and messages but lose `#shutdown` and the other server commands. Most small servers leave it at `0` and keep RCon itself to the people who own the server. > [!WARNING] > RCon has no usernames and no second factor. The password is the whole of the authentication, the port is scanned constantly, and anyone who has it can ban your entire player base. Use a long random password, change it when a moderator leaves, and read [RCON safely](https://www.renode.space/blog/rcon-safely) before exposing it. #### BattlEye RCon commands These are the commands an RCon client sends. Most tools wrap them in buttons, but knowing the raw form makes every tool easier to use and lets you type them into a console when the buttons are missing one. | Command | What it does | | --- | --- | | `players` | Connected players: number, IP, ping, GUID, name | | `admins` | Connected RCon clients | | `say -1 ` | Broadcast to everyone | | `say ` | Message one player by their number | | `kick [reason]` | Kick player number `n` | | `ban [minutes] [reason]` | Ban a connected player, `0` minutes is permanent | | `addBan [minutes] [reason]` | Ban by GUID, player need not be online | | `bans` | List bans with their numbers | | `removeBan ` | Lift ban number `n` from that list | | `loadBans` | Re-read `bans.txt` after editing it | | `writeBans` | Write the current ban list to `bans.txt` | | `loadScripts` / `loadEvents` | Re-read BattlEye filter files | | `MaxPing ` | Kick players above this ping | | `#lock` / `#unlock` | Stop or allow new joins | | `#shutdown` | Stop the server cleanly | The player number `n` is the session number shown by `players`, not a permanent ID. It changes when the player reconnects, so run `players` immediately before a `kick` or `ban`, and never act on a number you read a few minutes ago - the slot may now belong to someone else. `#lock` is underrated. Locking the server a few minutes before a restart stops people joining into a session that is about to end, and locking it during an incident (a cheater who keeps reconnecting on new accounts) buys time while you sort out bans. #### GUIDs, bans.txt and ban workflow BattlEye identifies players by a GUID, a 32-character hexadecimal value derived from the SteamID64. It is not the SteamID and you cannot read one off a Steam profile. The reliable way to get it is from `players`, from the BattlEye section of the server log, or from an RCon tool that records every connection. Bans are stored in `bans.txt` in the BattlEye folder, one per line: profiles/BattlEye/bans.txt: ```text 0123456789abcdef0123456789abcdef -1 Cheating - aimbot, evidence in #bans fedcba9876543210fedcba9876543210 1767225600 Racism in global chat, 7 days ``` The second field is `-1` for a permanent ban or a Unix timestamp when the ban expires. The rest of the line is the reason, which the player sees when they are kicked - so write something you would be happy to see quoted in a Discord argument. A workflow that keeps bans defensible: 1. Before banning, find the evidence: the `.ADM` admin log in the profiles folder records connections, kills with weapon and distance, hits and positions. A ban without a timestamp from that file is a ban you cannot explain later. 2. Ban with a reason that names the rule and where the evidence is kept. 3. If you edit `bans.txt` by hand, run `loadBans` afterwards. If you ban through RCon, run `writeBans` if your tool does not do it for you, so the file and memory agree. 4. Keep a copy of `bans.txt` in your backups. Losing it after a reinstall means unbanning every cheater you ever caught. DayZ also has its own `ban.txt` of SteamID64s, read by the server rather than BattlEye. Most communities use the BattlEye list because RCon tools manage it directly; using both is fine as long as everyone on the staff knows which one is authoritative. [Server rules, moderation and staff](https://www.renode.space/blog/server-rules-moderation-and-staff) covers the human side of this - written rules and an appeal path matter more than the tool. #### Choosing an RCon tool Any client that speaks the BattlEye RCon protocol will work. The common choices fall into three groups: - **Desktop clients.** DaRT (DayZ RCon Tool) is the long-standing Windows client: player list, chat log, kick and ban buttons, ban list management. It runs on your own PC, so it is only connected while your PC is on. - **Hosted services.** BattleMetrics RCON and CFTools Cloud connect to your server from their infrastructure and stay connected, which gives you a permanent player history, ban lists shared across servers, scheduled messages and restarts, and a log of which staff member did what. They are the standard choice for public servers with several moderators. Both have free tiers and paid features; check their current terms. - **Discord bots.** Several bots wrap RCon so moderators can kick and ban from a channel. Convenient, and also a way to put your RCon password on a third-party service you know less about. Treat it accordingly. Whichever you choose, the RCon password is shared with that tool. If you use a hosted service, it holds a credential that can control your server - pick one with a track record, and give it the password for RCon only, never the account that owns the server. For staff access to files and the console, a separate panel account per person with only the permissions they need is safer than one shared login, as covered in [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege). On RE:NODE that is the people section of the panel: roles hold permissions, teams hold people, and every server has an activity log, so a moderator can be given console access without file or billing access. #### In-game admin mods An admin mod adds a menu inside the game for whoever is on its admin list: teleport, spectate, free camera, spawn items and vehicles, heal, repair, see players on the map, delete objects. Two are widely used. ##### VPP Admin Tools VPP Admin Tools (folder `@VPPAdminTools`) is a self-contained admin menu. It is a client-and-server mod, so it goes in `-mod=` and its `.bikey` goes into the server's `keys` folder like any other. After its first start it writes its configuration into the profiles folder, including a list of super admins by SteamID64: profiles/VPPAdminTools/Permissions/SuperAdmins/SuperAdmins.txt: ```text 76561198012345678 ``` From there you build permission groups for moderators who should be able to teleport but not spawn items, which is exactly the distinction you want on a public server. The rest of its login flow and its permission names change between versions; follow the mod's own Workshop notes rather than an old video. ##### Community Online Tools Community Online Tools (COT) is the other common choice. It depends on Community Framework, so the order is `-mod=@CF;@Community-Online-Tools;...`, with both keys copied. Its roles and per-player permissions are written into the profiles folder on first start. COT is popular with modded servers because many other CF-based mods integrate with it. ##### Rules for any admin mod - **Load it on the server you want administered, not on a whim.** Every admin mod is a privileged script running on your server. Install it from its official Workshop item only, never from a re-upload. - **Give permissions by role.** Spawning items is the permission most often abused by staff, and the one players notice first. Keep it to the owners. - **Log admin actions.** Both mods write logs of admin actions to the profiles folder. Read them occasionally - it is the only way you will find out that a moderator has been spawning gear for friends. - **Expect an update lag.** After a DayZ patch, admin mods need updating like any other mod, and until they are you may have only RCon. That is one more reason to set RCon up properly first. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) has the routine. #### Logs: where the evidence is Administration is mostly reading. The files in the profiles folder answer nearly every question you will be asked: | File | What is in it | | --- | --- | | `*.ADM` | Connections, kills, hits, positions, placements, build actions | | `*.RPT` | Engine and script output, errors, mod problems | | `server_console.log` | What the console printed, as named by `logFile` | | `BattlEye/` logs | Script and filter kicks, RCon activity | | Admin mod logs | Every action taken through the mod's menu | What goes into the `.ADM` file depends on the `adminLog*` keys in `serverDZ.cfg`. Turn on placement and build action logging if you enforce raid rules; without them a raid dispute becomes one player's word against another's. These files grow without limit. A daily scheduled task that deletes logs older than a few weeks keeps the disk from filling, and copying the ones you care about into a backup first keeps the evidence. The panel's file manager or SFTP is how you get them off the server; [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers both. #### Scheduled messages and restarts RCon tools can broadcast restart warnings, but DayZ also has a built-in way: `db/messages.xml` in the mission folder. Each entry can repeat on an interval, or count down to a shutdown: mpmissions/dayzOffline.chernarusplus/db/messages.xml: ```xml 180 1 Server restarts in #tmin minutes. 30 Rules and Discord: example.gg/server ``` `deadline` is minutes after start, `shutdown` makes the server stop when it is reached, and `#tmin` is replaced with the minutes remaining. With a host that restarts a stopped server automatically, or a scheduler that starts it again, this gives a clean three-hour cycle with warnings, entirely from the mission files. Check the shipped `messages.xml` in your build for the exact element names before relying on it. The alternative is to run restarts from the panel. On RE:NODE the Schedules tab takes a cron expression and an ordered list of tasks with delays, so one schedule can send `#lock` and a warning through the console, take a backup, and restart. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers how often is worth it; for DayZ the community norm is every three to four hours. #### Securing the whole setup A checklist, in the order that matters: 1. **Different passwords** for `passwordAdmin`, `RConPassword` and your panel account. Nothing shared, nothing reused from elsewhere. 2. **RCon password rotated** whenever someone with access leaves the staff. 3. **`RestrictRCon 1`** if moderators connect with their own tools and should not be able to shut the server down. 4. **Admin mod permissions by role**, with item spawning held back. 5. **Two-factor on the panel account.** Whoever controls the panel controls every file, including `BEServer_x64.cfg`. [Two-factor on your panel account](https://www.renode.space/blog/two-factor-on-your-panel-account) takes five minutes. 6. **Backups that include the profiles folder**, so bans and admin configuration survive a reinstall. If something does go wrong - an admin account abused, the RCon password leaked - [what to do when your server is hacked](https://www.renode.space/blog/what-to-do-when-your-server-is-hacked) has the containment order: change credentials first, then look for what was done. #### FAQ ##### Where is BEServer_x64.cfg on a DayZ server? In the `BattlEye` folder inside your profiles directory, so `profiles/BattlEye/BEServer_x64.cfg` with `-profiles=profiles`. If it is not there, check for a `-BEpath=` launch parameter that moves it, and create the file yourself if it does not exist yet. ##### Why does my RCon client connect but time out? Usually the port is wrong, not allocated to the server, or opened on TCP when RCon is UDP. Also check that you edited the original config with the server stopped, not a stale `_active_` copy. ##### How do I ban someone who is not online? Use `addBan` with their BattlEye GUID, a duration in minutes (`0` for permanent) and a reason. Find the GUID in your RCon tool's history or the server logs from when they last connected. ##### Is a BattlEye GUID the same as a SteamID? No. It is derived from the SteamID64 but is a different value. Bans in `bans.txt` use GUIDs; whitelists and most admin mods use SteamID64s. ##### Do I need an admin mod at all? Not for moderation - RCon covers kicks, bans and messages. You need one for anything inside the world: teleporting, spectating, fixing stuck players or vehicles, inspecting bases. Most public servers run one, held to a small group. ##### Can moderators have RCon without being able to shut down the server? Yes. Set `RestrictRCon 1`, which limits RCon clients to BattlEye commands and blocks the `#` server commands such as `#shutdown`. DayZ servers on RE:NODE come with three port allocations and more can be added on the Network tab for RCon, a console with history, per-person panel accounts with role-based permissions and an activity log, and a Schedules tab for warnings, backups and restarts. The install waits on the Setup tab for your own Steam login. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ custom maps: Deer Isle and Namalsk Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/dayz-custom-map-deerisle-namalsk A DayZ community map is two things that have to match: a terrain mod that every player downloads, and a mission folder that only the server has, holding that map's loot economy, spawn points and event positions. To run one you add the map's mods to `-mod=` with their keys, copy its mission folder into `mpmissions`, point `template` in `serverDZ.cfg` at that folder, and start on a fresh persistence folder. Deer Isle needs Community Framework plus the `@DeerIsle` mod and its `empty.deerisle` mission; Namalsk needs `@Namalsk Island` and `@Namalsk Survival` plus either the `regular.namalsk` or `hardcore.namalsk` mission. Everything else in this guide is how to do that without an empty map, a crash loop or a wipe you did not intend. The general mod mechanics - keys, load order, `-mod=` versus `-servermod=` - are in [the full DayZ server guide](https://www.renode.space/blog/dayz-server-and-mods). This post assumes you have a working vanilla server and want to move it to another map. #### What a community map actually consists of Every DayZ map, including the official ones, is a terrain plus a mission. On official maps you never notice the split because both ship with the game. On a community map they come from different places, and most failed installs are a mismatch between them. | Piece | Where it comes from | Where it goes | Who needs it | | --- | --- | --- | --- | | Terrain mod | Steam Workshop | Server root as `@Name`, and on every client | Everyone | | Supporting mods | Steam Workshop | Server root and clients | Everyone | | `.bikey` files | Inside each mod's `keys` folder | Server `keys` folder | Server | | Mission folder | The map author's download, often GitHub | `mpmissions/` | Server only | The terrain mod contains the world: heightmap, buildings, roads, textures. It is large - community maps commonly run to several gigabytes - and every player downloads it through the DayZ Launcher before they can join. The mission folder is small but carries all of the map's gameplay. Its `db/types.xml` decides what loot exists, its `mapgrouppos.xml` and `mapgroupproto.xml` decide where loot can be placed in each building, `cfgeventspawns.xml` lists the coordinates for vehicles and crash sites, and `cfgplayerspawnpoints.xml` decides where fresh characters appear. A Chernarus mission on a Namalsk terrain is a server where every spawn point is in the sea and every loot position belongs to a building that is not there. ```diagram title: What has to match for a community map to work workshop = Steam Workshop | terrain and deps github = Map author | mission download server = DayZ server | -mod= and keys mission = mpmissions folder | template line client = Player | DayZ Launcher workshop -> server : @Map folders github -> mission : copy whole folder mission -> server : serverDZ.cfg workshop -> client : same versions client -> server : join ``` #### Choosing a map The official maps need no mods at all: - **Chernarus** - mission `dayzOffline.chernarusplus`. The default, and the map most players know. - **Livonia** - mission `dayzOffline.enoch`. Smaller, denser forests, official DLC map. - **Sakhal** - the Frostline map, mission `dayzOffline.sakhal` in builds that include it. Cold-weather survival with its own mechanics. Check the store pages for what players need to own to join a DLC map. The community maps people most often ask for: - **Deer Isle** - a large island map with a lot of points of interest, popular for PvE and roleplay as well as PvP. Requires Community Framework. - **Namalsk** - a small, cold, harsh island by Sumrak, with its own survival layer in a second mod. Comes in a regular and a hardcore mission. - **Others** - Banov, Esseker, Takistan Plus, Chiemsee, Pripyat and Alteria all have active servers. The install pattern is the same; the folder names and dependencies are on each map's Workshop page. Two practical questions decide the choice more than the scenery. First, how big is the download - every new player has to fetch it before their first join, and a large map loses some players at the door. Second, does the map have a maintained mission and an active author. A map whose mission files were last touched three game versions ago will need you to fix its economy yourself. #### Installing Deer Isle 1. Stop the server and take a backup of the whole thing, including the current mission folder and its `storage_*` folder. 2. Download the Workshop items for Community Framework and Deer Isle and place them in the server root as `@CF` and `@DeerIsle`. On your own machine that is SteamCMD with the client app id `221100`; on a host, download them once and upload the folders over SFTP. 3. Copy the `.bikey` from each mod's `keys` folder into the server's `keys` folder. 4. Download the Deer Isle mission files from the map's official repository and copy the `empty.deerisle` folder into `mpmissions/`. 5. Set the template: serverDZ.cfg: ```cfg class Missions { class DayZ { template = "empty.deerisle"; }; }; ``` 6. Set the mod line, frameworks first: ```text -mod=@CF;@DeerIsle ``` 7. Start the server and watch the log. A healthy start loads the mission, initialises the economy and reaches the point where it accepts players. A failed one usually names a missing mod or a missing file within the first screen. The mission folder name in your download is the one to use. If the author renames it in a later release, `template` has to change with it - a template that names a folder which does not exist stops the server at start. #### Installing Namalsk Namalsk splits into a terrain mod and a gameplay mod, and both are required: 1. Stop and back up, as above. 2. Add the Workshop items as `@Namalsk Island` and `@Namalsk Survival` in the server root, and copy both keys into `keys`. 3. Download the official server files from Sumrak's repository. The mission folders are `regular.namalsk` and `hardcore.namalsk`; copy the one you want into `mpmissions/`. 4. Set `template = "regular.namalsk";` or `template = "hardcore.namalsk";`. 5. Set the mod line. The folder names contain a space, so quote the whole parameter if you are writing a launch line by hand: ```text "-mod=@Namalsk Survival;@Namalsk Island" ``` Check the order the map's own documentation gives - when one mod depends on the other, the dependency loads first, and the documentation for the version you downloaded is the authority. If you also run Community Framework or other CF-based mods, `@CF` goes at the front. The hardcore mission is genuinely harder: tighter loot, more dangerous weather, and Namalsk Survival's own mechanics such as its EVR storms and cold-weather pressure are pushed further. Pick it for a group that wants that, not because "hardcore" sounds better in a server name. You cannot switch between the two later without effectively starting again, because their economies differ. > [!TIP] > Folder names with spaces are the most common Namalsk install failure on Linux hosts. If the server reports a mod it cannot find, rename the folders without spaces (for example `@NamalskIsland`) and update the `-mod=` line to match. The folder name is yours to choose; only the contents matter. #### Persistence when you change map Persistence is stored per mission, in `storage_` inside the mission folder. A new mission folder therefore starts with no storage and a fresh world. That is what you want on a map change: bases, vehicles and stashes from Chernarus reference positions that mean nothing on Deer Isle. Characters are a different question. They live in `players.db` in the same storage folder, so by default they do not follow you to the new map either. Some admins try to copy `players.db` across so players keep their gear. It can work on a like-for-like move, but characters saved standing in a Chernarus town will load at those coordinates on the new terrain - in a field if you are lucky, under the ground or in the sea if you are not. For a map change, announce a character wipe; it is cleaner and players expect it. If you want to keep the old map available - to switch back, or to run both on two servers - keep the old mission folder as it is. A server pointed back at `dayzOffline.chernarusplus` finds its old `storage_1` untouched. Two servers running at the same time each need their own ports and their own `instanceId`; see [serverDZ.cfg explained](https://www.renode.space/blog/dayz-server-cfg-explained) for the keys. Wipes in general, including partial ones, are in [DayZ wipes and persistence](https://www.renode.space/blog/dayz-server-wipes-and-persistence). #### Loot, events and spawns on a community map A community mission comes with its own economy, and its defaults reflect the author's taste. Expect to tune it, using the same files and rules as on Chernarus. The detailed mechanics are in [the DayZ types.xml guide](https://www.renode.space/blog/dayz-types-xml-and-loot-economy); the map-specific points are these. - **Usage and value names differ.** Each map defines its own legal loot areas and tiers in `cfglimitsdefinition.xml`. A types entry copied from a Chernarus guide may name a tier the map does not use, and an entry that names nothing valid never spawns. Check the map's file before pasting anything. - **Event coordinates are per map.** Vehicles, helicopter crashes and other events spawn only at positions listed in the mission's `cfgeventspawns.xml`. Copying an event from Chernarus without new coordinates either does nothing or spawns cars inside rocks. - **Spawn points decide the first ten minutes.** `cfgplayerspawnpoints.xml` controls where fresh characters appear. Authors often spread them generously; if every new player is killed by the same coastal camper, this is the file to change. - **Buildings need loot positions.** A building only holds loot if the mission's `mapgroupproto.xml` describes positions for its class. New buildings added by later map versions need updated proto files from the author; you will not write those by hand. As with any economy work, keep your own changes in a custom folder registered in `cfgeconomycore.xml` rather than editing the author's files directly. When the map author ships a new mission version, you replace their files and your folder survives. #### Adding other mods to a community map Most popular DayZ mods are map-agnostic: weapons, clothing, base building, admin tools. They work on any terrain, with two catches. Items a mod adds need economy entries, and the entries have to use the map's usage and value names. A weapons pack whose types file was written for Chernarus may need its `usage` and `value` lines edited for Namalsk's tiers before anything appears. Mods that place things in the world - traders, safe zones, AI patrols, custom bases - carry coordinates, and coordinates are per map. A trader file written for Chernarus places the trader somewhere arbitrary on Deer Isle. Large frameworks such as DayZ Expansion publish mission files per map for exactly this reason; [the DayZ Expansion guide](https://www.renode.space/blog/dayz-expansion-mod-server) covers combining it with a map. Custom buildings of your own - a trader camp, a new military base - can be added without a mod. On recent builds, `cfggameplay.json` has an object spawner list that reads JSON files of objects and positions exported from a placement tool such as the community DayZ Editor. That keeps map additions in the mission folder, where they belong, instead of in a script you have to maintain. #### Updating a community map Maps update on their own schedule, and a terrain update has knock-on effects: - **Clients and server must match.** When the terrain mod updates on the Workshop, players get it automatically through the launcher, and a server still on the old version rejects them. Update the server's copy of the mod, and its key, the same day. - **Mission updates are manual.** A new mission release - new loot positions, new events - arrives as a download you merge. Compare it with your current folder before overwriting; your custom `ce` folder and your edited `serverDZ.cfg` stay as they are. - **Game updates come first.** After a DayZ patch, map mods often need rebuilding by their authors. Until they are, a modded server may not start. Do not auto-update a community-map server on patch day; [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) has the routine. Take a backup before every update. On RE:NODE, backup slots on DayZ plans are stored off the machine they protect and restore with a button, and a backup can be locked so scheduled rotation never deletes the one you took before the update. #### Resources and disk A community map costs more than the vanilla server in two places. Disk first: the server install is a few gigabytes, and a large community map with its dependencies can add as much again, before any other mods. Make sure the plan's disk covers the map, every other mod, logs and a couple of backups' worth of headroom. Memory and CPU second. Dense maps with many buildings and many loot positions cost more to simulate than open terrain, and the survival layers some maps add run their own scripts. A Deer Isle or Namalsk server for 30-40 players is comfortable where a similar vanilla server is comfortable, with a little more memory for the extra mods; a heavily modded community map belongs at the upper end of [the DayZ requirements table](https://www.renode.space/blog/dayz-server-and-mods). If the server slows when it fills, check logged server FPS before buying memory - [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) explains why. #### Troubleshooting **The server stops at start with a mission error.** `template` names a folder that does not exist, or the case differs. Compare it character by character with the folder in `mpmissions`. **Players are kicked with a signature error.** A map or dependency key is missing from `keys`, or a mod updated and shipped a new key. Copy all keys again. **Players spawn in the sea or die on arrival.** The mission does not match the terrain - usually a Chernarus mission left in place with a new map mod. Check `template`. **The map has no loot.** The economy did not load or does not fit the map. Read the `.RPT` log for XML errors, and confirm that any types you added use the map's usage and value names. **Vehicles never appear.** Their events have no valid positions in this mission's `cfgeventspawns.xml`, or the map's default nominal is low. **The launcher will not download the map for players.** The server is not advertising the mod, often because it is in `-servermod=` instead of `-mod=`. A terrain belongs in `-mod=`. #### FAQ ##### Do players need to download the map? Yes. The terrain mod and its dependencies are client mods; the DayZ Launcher downloads them when a player joins your server from it. Only the mission folder stays on the server. ##### Can I switch my server from Chernarus to Deer Isle without a wipe? Not meaningfully. The new mission starts with its own empty persistence, and copying characters across places them at Chernarus coordinates on the new terrain. Plan the change as a fresh start and announce it. ##### What is the difference between regular.namalsk and hardcore.namalsk? They are two missions for the same terrain. The hardcore one has a harsher economy and pushes Namalsk Survival's environmental mechanics further. Choose before launch; switching later means a new world. ##### Where do I get a community map's mission files? From the map author, usually linked on the Workshop page and often hosted on GitHub. Do not use a mission folder from a random re-upload; it may be outdated or modified. ##### Can I run two maps on one server? One server process loads one mission. To offer two maps, run two servers with separate ports and instance ids, each with its own mods. ##### Why does a mod's loot not spawn on the new map? Its types entries use usage or value names from another map. Check the names in the map's `cfglimitsdefinition.xml` and edit the mod's entries to match. DayZ servers on RE:NODE come with SFTP and an in-browser editor for mission files, NVMe storage, and backup slots that can be locked before an update. Plans start at 6 GB with three port allocations, and moving up a tier for a bigger map changes the limit on the server you already have. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ Expansion server: modules and traders Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/dayz-expansion-mod-server DayZ Expansion is a family of server-and-client mods that adds traders and a market, safe zones, spawn selection, territory and base-building changes, groups, a map with markers, AI, missions, quests and vehicles. It installs in a fixed order: Community Framework and Dabs Framework first, then the Expansion core and licensed packages, then either the Bundle (everything) or the individual modules you want, all in `-mod=` with their keys. You then replace your mission folder with Expansion's mission files for your map, start once on clean persistence so the mod writes its settings, and configure it through JSON files in your profiles folder and in the mission. Plan for more memory and disk than vanilla, and plan for the fact that Expansion turns DayZ into a different game - which is the point, but it is not something you bolt on halfway through a wipe. The basics of DayZ mods - keys, `-mod=`, Workshop downloads - are in [the full DayZ server guide](https://www.renode.space/blog/dayz-server-and-mods). This post is Expansion specifically. #### What Expansion is made of Expansion is published as several Workshop items rather than one, so that servers can take only what they want. The pieces fall into three groups. | Group | Items | Role | | --- | --- | --- | | Dependencies | Community Framework (`@CF`), Dabs Framework | Shared libraries other mods build on | | Expansion base | Expansion Core, Expansion Licensed | Shared Expansion code and licensed assets | | Content | Bundle, or single modules | The features players see | The modules you will see on the Workshop include Market (traders and currency), Vehicles (helicopters, boats and more), AI (patrols and NPCs), Missions (dynamic events such as airdrops), Navigation (map and markers), Book (the in-game information book), Groups (parties), Base Building and Territories, Spawn Selection, Quests, Hardline (reputation) and Personal Storage. The exact list changes as the team reorganises; the Workshop pages and the project's wiki are the current reference. The Bundle includes the common modules in one item. It is the easy choice and the usual one for a server that wants the full Expansion experience. Individual modules make sense when you want, say, traders and safe zones but not Expansion's vehicles or AI - every module you leave out is less for players to download and less for the server to run. #### Requirements and resource usage Expansion is not a light mod. Every module runs server-side scripts, the market tracks stock, and AI patrols are simulated characters with all the cost that implies. | Setup | RAM | CPU | Notes | | --- | --- | --- | --- | | Market, safe zones, map, 20-30 players | 6-8 GB | 2-2.5 cores | The common "traders and quality of life" server | | Full Bundle, 30-50 players | 8-10 GB | 2.5-3 cores | Vehicles and missions add steady load | | Full Bundle with many AI patrols | 10-14 GB | 3+ cores | AI count is the main dial | - **CPU** is still the limit that players feel first, through server FPS. Enable `logAverageFps` in `serverDZ.cfg` and watch it; the key is explained in [serverDZ.cfg explained](https://www.renode.space/blog/dayz-server-cfg-explained). AI is the largest controllable cost. - **Memory** grows with module count and with persistence. The market's stock and every placed trader object live in memory too. - **Disk**: the Expansion items together are several gigabytes on top of the base server, and any map you run it on adds its own. Keep headroom for logs and for the backups you will take before every update. #### Installing, in order Do this on a stopped server, with a backup, and ideally at a wipe. 1. **Download the Workshop items** for CF, Dabs Framework, Expansion Core, Expansion Licensed and either the Bundle or your chosen modules, and place each in the server root as an `@` folder. The Workshop client app id for downloads is `221100`. 2. **Copy every key.** Each item has a `keys` folder with a `.bikey`. All of them go into the server's `keys` folder. A missing one produces a BattlEye signature kick at the loading screen. 3. **Set the mod line in dependency order.** Frameworks first, Expansion base next, content last. The example below shows the shape. ```text -mod=@CF;@Dabs Framework;@DayZ-Expansion-Core;@DayZ-Expansion-Licensed;@DayZ-Expansion-Bundle ``` Folder names are whatever you named the folders. Names with spaces need the whole parameter quoted on a hand-written launch line, and are easier on Linux if you rename them without spaces. Check the order against the Expansion wiki for your version; when a dependency moves, the wiki is updated first. Then carry on: 4. **Install the mission files.** Expansion needs its own mission for your map - see the next section. 5. **Start on clean persistence.** Point the server at the new mission, which has its own empty storage, or clear the storage of the mission you are converting. 6. **Let it write its settings.** The first start creates the `ExpansionMod` folder in your profiles directory and the Expansion settings in the mission. Stop the server once it is fully up. 7. **Configure, then start again.** Edit the JSON with the server stopped, validate it, start, read the log. > [!WARNING] > Do not add Expansion to a running vanilla world and hope. Its base building, territories and vehicles change what persistent objects exist, and old persistence produces ghost items, broken bases and start-up errors. Install it at a wipe, on fresh storage. [DayZ wipes and persistence](https://www.renode.space/blog/dayz-server-wipes-and-persistence) covers the routine. #### Mission files Expansion's features need hooks in the mission: its own `init.c`, economy entries for its items, positions for its events and objects, and mission-side settings. The team publishes ready mission folders per map in a public repository linked from the wiki; take the one for your map rather than adapting a vanilla mission by hand. serverDZ.cfg: ```cfg class Missions { class DayZ { template = "Expansion.ChernarusPlus"; }; }; ``` Use whatever folder name your download actually has - the line above is an example of the pattern, and the case must match exactly. On a community map, use Expansion's mission for that map if one exists; otherwise you are merging two missions by hand, which is possible but is a project in itself. The general map-change process is in [running Deer Isle or Namalsk](https://www.renode.space/blog/dayz-custom-map-deerisle-namalsk). If you already had economy changes of your own, keep them in a custom folder registered in the mission's `cfgeconomycore.xml`, exactly as you would on vanilla. [The DayZ types.xml guide](https://www.renode.space/blog/dayz-types-xml-and-loot-economy) covers custom `ce` folders. That way the next Expansion mission release can be dropped in and your folder survives. #### Where the settings live Expansion splits its settings into two places, and knowing which file is where saves a lot of searching. | Location | What is there | | --- | --- | | `profiles/ExpansionMod/Settings/` | Server-wide settings: AI, airdrops, chat, general, logs, market categories and traders settings, missions, notifications, party, quests, raids, territories, vehicles | | `mpmissions//expansion/settings/` | Map-specific settings: base building, map markers, market, safe zones, spawns, AI patrols and locations, personal storage | | `profiles/ExpansionMod/Traders/` | One JSON per trader type: what it buys and sells | | `profiles/ExpansionMod/Market/` | Market categories: items, price and stock ranges | | `mpmissions//expansion/traders/` | `.map` files that place trader NPCs in the world | The logic of the split is that anything tied to coordinates - where safe zones are, where people spawn, where traders stand - belongs to the mission, and everything else belongs to the server profile. That means a server can change map and keep its market, but its safe zones and traders have to be redone for the new terrain. Every settings file carries a version number, and Expansion migrates older files when it updates. The project's own advice is to review your settings after every Expansion update. In practice: back up the `ExpansionMod` folder and the mission's `expansion` folder before updating, then compare after the first start. Editing a dozen interlinked JSON files by hand is error-prone. The community tool DayZeEditor exists specifically to manage Expansion settings and mission economy files, and is worth trying if you run a large market. Whatever you use, validate JSON before you restart; a trailing comma in one file can stop that whole module from loading. #### Traders and the market Traders are the module most servers install Expansion for, and they have three parts that have to agree. **Market categories** in `ExpansionMod/Market/` define groups of items with prices and stock. Each item entry names a class and a range of prices and stock levels - the price moves between its minimum and maximum as stock falls and rises, which is how Expansion models supply and demand. The exact field names have changed between versions, so open the files Expansion generated for you and edit those rather than pasting an example from an old guide. **Traders** in `ExpansionMod/Traders/` are named JSON files that list which categories (and optionally which individual items) a trader deals in, and whether each is buy, sell or both. A weapons trader, a vehicle trader and a general store are three files. **Trader NPCs** are placed in the world by `.map` files in the mission's `expansion/traders/` folder, one line per NPC: mpmissions//expansion/traders/Green_Mountain.map: ```text ExpansionTraderDenis.Weapons|11833.576 140.605 12469.492|110 0 0|Jeans_Blue,TSHirt_Blue ``` The line reads as: NPC class, a dot, the name of a trader file (without `.json`), then position, orientation and the clothing and gear the NPC wears, with attachments joined by `+`. The trader file name links the NPC to `ExpansionMod/Traders/Weapons.json`. A typo there gives you a trader who stands in the world and sells nothing. Trader zones - the areas whose stock is shared between the traders inside them - and the safe zones around trader camps are mission-side settings, because they are coordinates. A trader camp on a PvP server without a working safe zone is a killing field within a day. Pricing is the part that decides whether the economy works. Two rules of thumb: - **Sell prices well below buy prices.** If players can buy an item and sell it back for nearly the same price, loops appear. The spread is your inflation control. - **Control the money supply at the source.** Currency enters the world through loot, missions and selling. If everyone is rich after a week, look at what the traders buy, not at what they sell. #### AI, missions and other modules worth configuring - **AI** patrols and NPCs are set in the server's AI settings and the mission's patrol and location files. Each patrol is a group of simulated characters; add them deliberately and measure server FPS after each change. A map with AI at every military base is a different game and a different CPU budget from one with a few roaming groups. - **Missions** such as airdrops and contaminated zones are timed events with their own loot. Their frequency is the main knob. - **Spawn selection** lets players choose a spawn point from a list on death. It changes the pace of PvP a lot; decide as a community whether fresh spawns should be able to pick the coast next to their base. - **Territories and base building** replace or extend vanilla territory rules. Their limits (objects per territory, territory radius, members) are a performance setting as much as a gameplay one. - **Notifications** can schedule restart warnings and server messages, overlapping with vanilla's `messages.xml`. Use one or the other, not both. #### Admin tools alongside Expansion Expansion is not an admin tool. Most Expansion servers also run Community Online Tools or VPP Admin Tools, plus BattlEye RCon for moderation from outside the game. COT is the common pairing because it is also built on CF. Load the admin mod after the frameworks and before or alongside the Expansion content, with its key copied like any other. Setup, permissions and ban workflow are in [DayZ admin tools and BattlEye RCon](https://www.renode.space/blog/dayz-admin-tools-and-rcon-battleye). #### Updating Expansion safely Expansion updates often, and DayZ patches break it until the team rebuilds. A routine that avoids most bad evenings: 1. **Do not auto-update on patch day.** When DayZ updates, wait until Expansion and every other mod on your list has been updated for the new build. 2. **Back up first**: the `ExpansionMod` folder in profiles, the mission folder with its `expansion` subfolder, and the storage folder. Lock that backup so rotation cannot remove it. 3. **Update all mod folders and keys together.** A new Expansion version may ship new keys; copy them all again. 4. **Start once and read the log.** Settings migrations are logged. Errors naming a JSON file are usually a field that changed. 5. **Compare settings** with your backup and re-apply anything the migration reset. If an update goes wrong, restore and wait rather than debugging on a live server. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) has the full routine, and [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) covers keeping a mod list from rotting over time. On RE:NODE a backup can be locked against rotation and restored with a button, and an in-browser editor with syntax highlighting makes the JSON edits less error-prone. #### Troubleshooting **Players are kicked with a signature error.** A key is missing from `keys`, often for Dabs Framework or the Licensed item, which people forget because they never think of them as "the mod". Copy every key again. **The server stops at start with script errors.** Load order is wrong, a dependency is missing, or a mod is out of date for the current game build. Read the first errors in the `.RPT` log; they name the mod. **Traders stand there but sell nothing.** The trader file name in the `.map` line does not match a file in `ExpansionMod/Traders/`, or that file's categories do not exist in `ExpansionMod/Market/`. **Settings changes do nothing.** You edited while the server was running and it wrote its own copy back, or the JSON failed to parse and Expansion used defaults. Stop, edit, validate, start. **Ghost items and broken bases after installing.** Expansion was added to existing persistence. Restore the backup or wipe. **Server FPS drops as the evening goes on.** AI and missions. Reduce patrol counts, check how many mission events overlap, and restart on a schedule. #### FAQ ##### Do I need the whole Expansion Bundle? No. The Bundle is the simplest install, but individual modules let you take only what you use - for example market and safe zones without Expansion's AI or vehicles. Every module needs the shared dependencies and Expansion Core. ##### What is Dabs Framework and why is it required? It is a shared library that Expansion depends on, like Community Framework. Both must be loaded before Expansion, and both keys must be in the server's `keys` folder. ##### Can I use Expansion on Deer Isle or Namalsk? Yes, if there is an Expansion mission for that map or you merge one yourself. Coordinate-based settings - traders, safe zones, spawns, AI patrols - have to be made for that terrain. ##### Where are the trader prices set? In the market category files in `profiles/ExpansionMod/Market/`. Each item has price and stock ranges; the trader files in `ExpansionMod/Traders/` decide which categories each trader handles. ##### Do I need to wipe to install Expansion? It is strongly advised. Expansion changes base building, territories and vehicles, and old persistence causes ghost items and start-up errors. Install it at a wipe on clean storage. ##### Why did my settings change after an update? Expansion migrates settings files to new versions on start, which can reset or add fields. Back up the settings folders before updating and compare afterwards. DayZ plans on RE:NODE go up to 12 GB for Expansion-sized mod lists, with NVMe storage, SFTP and an in-browser JSON and XML editor, and backup slots you can lock before an update. Moving up a tier changes the limit on the server you already have. The install waits on the Setup tab for your own Steam login. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ serverDZ.cfg settings, line by line Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/dayz-server-cfg-explained `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](https://www.renode.space/blog/dayz-server-and-mods), 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: ```bash $ ./DayZServer -config=serverDZ.cfg -port=2302 -profiles=profiles ``` The 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 `.RPT` file 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 serverDZ.cfg: ```cfg 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](https://www.renode.space/blog/dayz-admin-tools-and-rcon-battleye). 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](https://www.renode.space/blog/dayz-server-and-mods), and [how many players fit on a server](https://www.renode.space/blog/how-many-players-fit-on-a-server) covers the general reasoning. #### Anti-cheat, builds and client restrictions serverDZ.cfg: ```cfg 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 serverDZ.cfg: ```cfg 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 serverDZ.cfg: ```cfg 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](https://www.renode.space/blog/dayz-server-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](https://www.renode.space/blog/dayz-types-xml-and-loot-economy). #### Login queue, ping and messages serverDZ.cfg: ```cfg 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](https://www.renode.space/blog/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 serverDZ.cfg: ```cfg 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 = 1` limits hit logging to hits on players, which shrinks the file on servers with many infected. - `adminLogPlacement = 1` records every placed object - tents, traps, fences. Essential for settling arguments about who built what where. - `adminLogBuildActions = 1` records building, dismantling and destroying base parts. Turn it on if your rules care about raiding. - `adminLogPlayerList = 1` writes 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](https://www.renode.space/blog/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 serverDZ.cfg: ```cfg 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](https://www.renode.space/blog/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: serverDZ.cfg: ```cfg 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](https://www.renode.space/blog/dayz-custom-map-deerisle-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: cfggameplay.json: ```json { "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: serverDZ.cfg: ```cfg 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 > [!WARNING] > Every line needs its semicolon. A missing one at the end of `hostname` can make the parser read the next line as part of the name, and the server starts with your admin password in its browser title. Read the log after every edit. - **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.chernarusplus` and `dayzOffline.chernarusplus` are different folders there. - **Two copies of one setting.** A value set in both `serverDZ.cfg` and `cfggameplay.json` leads to arguments about which one wins. Set it in one place. - **Editing the wrong file.** If the launch line says `-config=serverDZ_live.cfg`, editing `serverDZ.cfg` changes 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. DayZ servers on RE:NODE start at 6 GB with three port allocations, an in-browser editor with syntax highlighting for `serverDZ.cfg` and the mission files, SFTP, and backup slots on every tier. The install waits on the Setup tab for your own Steam login, so bring a spare account that owns the game. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ server wipes: full and partial resets Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/dayz-server-wipes-and-persistence Everything a DayZ world remembers between restarts lives in one folder: `storage_` inside the mission folder, so `mpmissions/dayzOffline.chernarusplus/storage_1/` on a default Chernarus server. Characters are in `players.db` in that folder; tents, bases, stashes, vehicles and the economy's own state are in the binary files under `data/`. A full wipe is deleting the folder's contents with the server stopped. A character-only wipe is deleting `players.db`. A world wipe that keeps characters is deleting `data/` and leaving `players.db`. Everything else - base decay, flag timers, what survives a restart at all - is set in a handful of XML files, and getting those right means you need fewer wipes in the first place. This post covers persistence end to end. Loot spawning itself is in [the DayZ types.xml guide](https://www.renode.space/blog/dayz-types-xml-and-loot-economy), and the config key that selects the storage folder is explained in [serverDZ.cfg explained](https://www.renode.space/blog/dayz-server-cfg-explained). #### What persists and where The persistence folder is chosen by `instanceId` in `serverDZ.cfg`: instance 1 reads and writes `storage_1`, instance 2 `storage_2`, always inside the mission folder named by `template`. Change either value and the server starts a fresh world - the old one is still on disk, simply not loaded. Inside it you will typically find: | Path | What it holds | | --- | --- | | `players.db` | Characters: position, health, inventory, stats | | `data/dynamic_*.bin` | Player-placed and dynamic objects: tents, stashes, items on the ground | | `data/building.bin` | Building state such as opened and locked doors | | `data/events.bin` | Event objects, including vehicles | | `data/types.bin` | The economy's bookkeeping for item types | | `data/vehicles.bin` | Vehicle state, on builds that split it out | Treat the list of `.bin` files as indicative rather than fixed. Bohemia has changed how persistence is split between files over the game's life, and the names on your server are the ones that matter. List the folder before you delete anything. `players.db` is an SQLite database. That matters for two reasons: it can be opened with any SQLite browser if you ever need to inspect or remove a single character, and it must never be copied or edited while the server is running, because the copy may be taken mid-write. The mission files themselves - `types.xml`, `events.xml`, `cfgeconomycore.xml` and the rest - are configuration, not persistence. Editing them does not wipe anything. Deleting `storage_1` does not reset them. Keeping that line clear is most of the job. #### What decides what gets saved Which categories are saved and loaded at all is set in `db/economy.xml`. The vanilla file looks like this: db/economy.xml: ```xml ``` | Attribute | Meaning | | --- | --- | | `init` | Spawn this category when the world is first created | | `load` | Read its saved state at start | | `respawn` | Let the economy replace what is used up | | `save` | Write its state to storage | Animals and infected are not saved: they respawn fresh at every start, which is why restarts clear zombie trains. Dynamic objects, vehicles, buildings and players are. Compare your file with this one before you start debugging persistence - a mod or an old guide may have changed a flag, and `load="0"` on `player` makes every character start fresh at each restart while looking like a bug. Those flags can be used for a deliberate one-off reset as well: start once with `load="0"` on a category, let the server write a clean state, then set it back. It works, but it is easy to forget the second half, and deleting files with a backup in hand is more predictable. Keep the flags at their vanilla values unless you have a specific reason. #### Lifetimes, decay and territory flags Persistent does not mean permanent. Every object has a lifetime, and the cleanup system removes anything untouched for that long. That is how abandoned bases disappear without a wipe. - **Items and containers.** Each type's `lifetime` in `types.xml`, in seconds, is how long it survives without interaction. Tents, barrels and buried stashes have long lifetimes in the vanilla files, on the order of weeks. Interacting with a container - opening it, moving items in it - resets its timer. - **Base parts and territory flags.** A raised territory flag keeps base parts within its radius alive. The flag has to be refreshed by a player: `FlagRefreshFrequency` and `FlagRefreshMaxDuration` in `db/globals.xml` set how often a refresh is possible and how long a fully raised flag protects the base. - **Global cleanup.** `globals.xml` also holds `CleanupLifetimeDefault`, `CleanupLifetimeDeadPlayer`, `CleanupLifetimeDeadInfected`, `CleanupLifetimeRuined` and similar values for things without their own lifetime. db/globals.xml (excerpt): ```xml ``` With those vanilla values a flag can be refreshed every five days and holds a base for up to forty. Raise them and abandoned bases linger, filling the map and the persistence files; lower them and active players lose bases when they take a holiday. Most servers leave them alone. If yours runs on a monthly wipe cycle, the decay system matters less; if it never wipes, it is the only thing keeping the world from silting up. > [!NOTE] > Persistence growth is a performance issue as much as a gameplay one. Thousands of persistent objects cost load time at every start and server FPS during play. A server that has run for a year without a wipe or sensible lifetimes is usually slower for that reason alone. #### When the world is actually saved DayZ writes persistence periodically while running and once more on a clean shutdown. A process that is killed - a hard stop, a crash, the machine losing power - loses whatever changed since the last write, and in the worst case leaves a file half-written. That has three practical consequences: 1. **Always stop cleanly.** Use the panel's Stop or Restart, `#shutdown` through RCon, or a shutdown message in `db/messages.xml`. On RE:NODE the Restart button sends a clean stop, so persistence is written before the process exits. A kill is for a server that has already hung. 2. **Keep `storageAutoFix = 1;`** in `serverDZ.cfg`. It lets the server repair a damaged file at start instead of refusing it. Without it, one bad shutdown can leave a server that will not boot. 3. **Watch memory.** If a server reaches its memory limit, it is stopped by force - on RE:NODE the container is stopped and restarted clean rather than left to swap, which is the right behaviour but is still not a clean save. A server that keeps hitting its limit is losing progress each time. [Why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) covers how to tell. #### The kinds of wipe Every wipe follows the same safety routine: announce it, stop the server cleanly, take a backup, then delete. The difference is what you delete. | Wipe | Delete | Keep | | --- | --- | --- | | Full | Everything in `storage_` | Mission files, config, bans | | Character only | `players.db` | `data/`, so bases and stashes stay | | World only | `data/` contents | `players.db`, so characters keep their gear | | Single player | One character in `players.db` | Everything else | | Map change | Nothing - the new mission has its own storage | The old folder, in case you switch back | ##### Full wipe The standard monthly or seasonal reset. Stop the server, back up, delete the contents of `storage_1` (or rename the folder, which doubles as a quick local backup), start. The server creates fresh storage, the economy populates the map from scratch, and every player starts as a fresh spawn. Mission files, `serverDZ.cfg`, BattlEye bans and admin mod configuration all live elsewhere and are untouched. The first start after a full wipe takes longer than usual while the economy spawns the whole map's loot. Give it time before judging whether loot looks right. ##### Character-only wipe Deleting `players.db` resets every character to a fresh spawn while every tent, base and vehicle stays where it is. This is what admins use after a duplication exploit has flooded inventories, or at the start of a new season on a server where bases are the long-term investment. Expect bases to be raided quickly by fresh characters who know where they are - announce it. ##### World wipe, characters kept Delete the contents of `data/` and keep `players.db`. The world resets - bases, stashes, vehicles, the economy's state - while characters keep what they were carrying. Useful after a broken mod left the world full of invalid objects, or when you want to reset bases without punishing players for their gear. Characters load at their saved positions, which is fine on the same map. ##### Removing one player There are two routes. If your admin tooling can delete or reset a character, use it, with the player offline. Otherwise, stop the server, back up, and open `players.db` in an SQLite browser; characters are stored with an identifier for the player, and removing that row resets them. Do this only with a backup in hand, and only with the server stopped. ##### Vehicles only There is no supported "vehicles only" wipe. On builds that keep vehicles in their own file, deleting it with the server stopped resets them to fresh spawns. On builds where vehicles live with other event objects, you will reset crash sites and other events too. Test on a copy of the folder first, as with any partial wipe that depends on file names. #### When a wipe is required Most changes do not need one. Changing nominals, lifetimes, time of day or almost anything in `serverDZ.cfg` takes effect at the next restart with the world intact. Changes that do need a wipe, or at least a careful one: - **A different map or mission.** A new mission has its own storage anyway - see [running a community map](https://www.renode.space/blog/dayz-custom-map-deerisle-namalsk). - **Removing a mod that adds persistent objects.** Base-building mods, storage mods and vehicle mods leave objects in persistence that no longer have a class. The server may log errors, delete them, or refuse to start. Remove such a mod at a wipe. - **Large framework changes.** Adding or removing something like DayZ Expansion changes what the world contains; its own guidance is to start on clean storage. See [the DayZ Expansion guide](https://www.renode.space/blog/dayz-expansion-mod-server). - **Corruption that `storageAutoFix` cannot repair.** If the server will not start and the logs point at persistence, the choice is a backup or a wipe. A game update rarely requires a wipe on its own, though Bohemia has occasionally recommended one after major changes. Read the patch notes before deciding. #### Backups and a wipe schedule A wipe deletes data, so the backup before it is not optional - it is the undo button for the day you discover a bug in the new setup, or a player proves their base vanished because of your mistake. What to back up: - The whole `storage_` folder, together with the mission folder it belongs to. Restoring one without the other gives you persistence that disagrees with the economy. - `serverDZ.cfg`, the BattlEye folder with `bans.txt`, and admin mod configuration in the profiles folder. - Not the server binaries or Workshop mods - those can be downloaded again. Back up with the server stopped, or at least straight after a clean restart; a copy of `players.db` taken mid-write may not open. On RE:NODE, backup slots come with every DayZ plan, are stored off the machine they protect and restore with a button, and the Schedules tab can chain a warning, a clean restart and a backup on a cron expression - [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) has patterns for that. And restore one occasionally to prove it works: [testing a restore before you need it](https://www.renode.space/blog/testing-a-restore-before-you-need-it) explains how. For the schedule itself, communities settle on one of three rhythms: | Rhythm | Suits | Trade-off | | --- | --- | --- | | Monthly full wipe | Busy PvP servers | Fresh competition; long-term builders leave | | Seasonal, every 2-4 months | Mixed communities | Time to build; the map fills up | | Never, decay only | PvE and roleplay | Continuity; relies on good lifetimes | Whichever you choose, publish it and keep it. A wipe announced a week ahead is a fresh start; an unannounced one is how communities lose their regulars. The same principles from another game are in [Rust wipes without losing your players](https://www.renode.space/blog/rust-wipes-without-losing-your-players). #### Troubleshooting **The world reset on its own after an update.** `instanceId` or `template` changed, so the server is reading a different storage folder. The old one is still there; put the value back. **Characters reset at every restart.** `load` or `save` is `0` for `player` in `economy.xml`, or `players.db` cannot be written. Check the flags, then the log. **The server will not start after a crash.** A damaged persistence file. Confirm `storageAutoFix = 1;`, read the `.RPT` log for the file it names, and restore that storage folder from a backup if the fix fails. **Bases disappeared that should have survived.** The territory flag was not refreshed within `FlagRefreshMaxDuration`, or the items had short lifetimes. Check `globals.xml` and the `lifetime` of the relevant types. **Start-up takes several minutes.** Very large persistence. Lower lifetimes on junk, keep decay working, and plan a wipe. **A partial wipe broke something.** Restore the backup you took before it - and next time, test the deletion on a copy. #### FAQ ##### Does editing types.xml wipe my DayZ server? No. The economy files are configuration. Persistence is in the `storage` folder and is only reset by deleting it, changing `instanceId`, or switching mission. ##### How do I wipe characters but keep bases? Stop the server, take a backup, and delete `players.db` from `storage_`. Every character becomes a fresh spawn and the world stays as it was. ##### How do I reset the world but let players keep their gear? Stop the server, back up, and delete the contents of `data/` in the storage folder while leaving `players.db`. Bases, stashes and vehicles reset; characters load with their inventory. ##### How long do bases last without a wipe? As long as their territory flag is refreshed. In vanilla `globals.xml` a fully raised flag protects the base for up to forty days, and it can be refreshed every five. Unprotected objects follow their own `lifetime` values. ##### Can I undo a wipe? Only from a backup taken before it. That is why the backup is part of the wipe routine, not an optional extra. ##### Why does the first start after a wipe take so long? The economy is spawning the whole map's loot, vehicles and events from scratch. Later starts load saved state instead and are quicker. DayZ servers on RE:NODE come with backup slots stored off the machine they protect, restored with a button and lockable against rotation, a clean Restart that saves persistence first, and a Schedules tab for warnings, restarts and backups. The install waits on the Setup tab for your own Steam login. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ server RAM: players, mods and economy Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/how-much-ram-does-a-dayz-server-need A DayZ server needs 4 to 6 GB of memory for a private group of ten to twenty on vanilla, 6 to 8 GB for the common 30 to 40-slot public server, 8 to 10 GB for a busy 40 to 60-slot vanilla server, and 10 to 12 GB for a heavily modded server with Expansion-scale mods, traders and AI. Memory grows with the mod list and with what persists on the map far more than with the player count: a 30-slot server carrying a large mod pack uses more than a 60-slot vanilla one. The resource that usually runs out first on DayZ is not memory at all but server FPS - one busy core - so prove which one you are short of before buying more of either. #### What a DayZ server holds in memory DayZ's server simulates a 225 square kilometre map (Chernarus; Livonia is smaller) with a persistent economy. Its memory has four large parts. - **The map and engine floor.** Terrain, buildings, the navigation data for infected and animals, and the engine itself. This is paid before anyone joins and depends on the map. - **The central economy.** Every item that exists on the map is an object. The economy's job is to keep the number of each item type near its target, so a server with the vanilla `types.xml` holds tens of thousands of items at any moment - in buildings, on infected, on the ground, in players' inventories. - **Persistent objects.** Tents, barrels, crates, base-building walls and gates, buried stashes and vehicles survive restarts through the persistence system. Everything inside them persists too. This is the part that grows over the life of a server. - **Mods.** Every mod's scripts, configs and assets loaded into the server, and every item they add to the economy. Players themselves cost comparatively little: their character, inventory and network state. What they cost indirectly is everything they build, hoard and leave lying around. #### RAM by slots and mod list | Server | RAM | vCPU | Notes | | --- | --- | --- | --- | | 10-20 slots, vanilla | 4-6 GB | 2 | Comfortable for a private group | | 30-40 slots, vanilla | 6-8 GB | 2-3 | The common public server | | 40-60 slots, vanilla | 8-10 GB | 3+ | Server FPS becomes the limit, not memory | | 30-50 slots, heavily modded | 10-12 GB | 3+ | Expansion-scale lists, traders, AI | | Community map (Namalsk, Deer Isle and similar) | add 1-2 GB | - | Depends on the map's size and density | How to read it: - **Mods move you down the table faster than slots.** A server running Expansion with its market, vehicles and AI modules, plus base-building and weapon packs, is a different machine from a vanilla server with the same slot count. - **Age moves you down too.** A server that never wipes persistent storage accumulates bases and stashes, and their contents. A server three months into a wipe uses noticeably more than it did in week one. - **The CPU column matters as much as the RAM column.** DayZ's simulation runs on a main thread. A 60-slot server is limited by server FPS long before it runs out of memory. The [DayZ server and mods guide](https://www.renode.space/blog/dayz-server-and-mods) uses the same figures and covers the install end to end. #### The central economy is a memory setting DayZ's loot is controlled by the central economy files in the mission folder, `mpmissions/dayzOffline.chernarusplus/` for vanilla Chernarus. Two of them set the numbers that matter for memory. ##### types.xml Each item type has a target count (`nominal`), a minimum (`min`), a `lifetime` in seconds before an untouched item despawns, and a `restock` time: types.xml: ```xml 8 14400 0 4 -1 -1 100 ``` The sum of `nominal` across every type is roughly how many items the economy tries to keep in the world. Doubling loot by multiplying nominals - a very common change on community servers - roughly doubles that part of memory, and adds CPU for the economy to manage it. Long `lifetime` values mean dropped and abandoned items stay longer. Mods that add weapons and gear add their own entries, and some mod packs ship generous nominals. [types.xml and the loot economy](https://www.renode.space/blog/dayz-types-xml-and-loot-economy) explains every field. ##### globals.xml Global caps and cleanup timers live in `db/globals.xml`. These are the memory-relevant ones: | Variable | Typical default | Effect | | --- | --- | --- | | `ZombieMaxCount` | `1000` | Infected alive across the map at once | | `AnimalMaxCount` | `200` | Animals alive at once | | `CleanupLifetimeDeadPlayer` | `3600` | Seconds a player's body stays | | `CleanupLifetimeDeadInfected` | `330` | Seconds an infected body stays | | `CleanupLifetimeDeadAnimal` | `1200` | Seconds an animal carcass stays | | `CleanupLifetimeRuined` | `330` | Seconds a ruined item stays | Raising `ZombieMaxCount` for a harder server is common and costs memory and CPU in proportion. Lengthening cleanup lifetimes keeps bodies and ruined gear on the map longer, and on a busy PvP server that is hundreds of extra objects with full inventories. Check the values in your own file; mission files are updated with the game and some community missions change them. > [!TIP] > If your server has run out of memory since you raised loot, do not cut players first. Bring the `nominal` multipliers back towards vanilla for the item types that matter least - clothing variants, food tins, common ammunition - and watch the graph for a few restarts. #### Persistence: the part that grows Persistent storage lives in the mission folder's `storage_1` directory (the number is the `instanceId` in `serverDZ.cfg`). Every tent, barrel, wall, gate, buried stash and vehicle is written there and loaded on every start, with its contents. That gives DayZ the same slow climb as any base-building survival game: - **Week one** is mostly the economy and the map floor. - **Month two** adds every base on the map, every stash nobody remembers burying and every vehicle someone parked in a barn. - **Abandoned bases** do not leave by themselves unless territory flags and their refresh rules are in play. On vanilla, a flag that is not refreshed eventually lets the base decay; on servers where flags are not used, persistent items rely on their own lifetimes. A full persistence wipe resets all of it and is usually done with a map update or on a fixed schedule. [DayZ server wipes and persistence](https://www.renode.space/blog/dayz-server-wipes-and-persistence) covers what a partial wipe can remove and what a full wipe removes. #### Proving it with the server's own logs DayZ can log its own memory and FPS to the server's `.RPT` file, which is the easiest way to get real numbers over a whole session. Add these to `serverDZ.cfg`: serverDZ.cfg: ```cfg logAverageFps = 60; logMemory = 60; logPlayers = 60; ``` Each value is an interval in seconds. With these set, the RPT log gains periodic lines with the average server FPS, the memory in use and the player count. Leave it running through a full restart cycle on a busy evening and you have exactly the data the sizing decision needs. What to look for: 1. **Memory across the cycle.** It rises from the start as the economy fills and players spread out. If it is within about 10% of your limit before the next scheduled restart, you are short. 2. **Server FPS under load.** If FPS sags towards single digits as the server fills while memory has room to spare, the limit is CPU. More memory will not help; fewer infected, less loot, fewer AI and fewer heavy mods will. 3. **The relationship between them.** A server whose FPS falls steadily across a session, alongside rising memory, is the classic case for a shorter restart interval rather than a larger plan. [CPU or RAM: which one is holding your server back](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) explains the general method, and [game server CPU requirements](https://www.renode.space/blog/game-server-cpu-requirements) covers what to do when it is the core. #### Launch parameters that touch memory and CPU The DayZ server's launch line carries a few parameters worth knowing for sizing: ```bash $ ./DayZServer -config=serverDZ.cfg -port=2302 -profiles=profiles \ -cpuCount=2 -limitFPS=60 -dologs -adminlog -freezecheck \ "-mod=@CF;@Dabs Framework;@DayZ-Expansion-Core" ``` What each of the relevant ones does: - **`-cpuCount`** tells the engine how many cores to plan its worker threads around. Set it to match the cores you actually have; a value higher than the allocation only creates threads that compete with each other. - **`-limitFPS`** caps the server's simulation frame rate. A cap stops the server burning CPU on frames nobody benefits from, which leaves headroom for the moments that need it. - **`-mod` and `-serverMod`** list the mods loaded on both sides and on the server only. Every entry is memory at start; server-only mods (admin tools, logging, anti-cheat helpers) are no exception. - **`-freezecheck`** makes the server stop itself if it hangs, which is better than a frozen process holding players for minutes. On a panel-based host these are Startup variables rather than a line you type, and the mod list is usually its own field. #### Mods: the biggest single variable DayZ's modding community is large and its big frameworks are substantial. The cost depends on what a mod does: - **Framework and admin mods** - Community Framework, admin tools, logging - add modest memory and are often dependencies of everything else. - **Content packs** - weapons, clothing, vehicles - add assets and economy entries. Each new item type that spawns is more objects on the map. - **Systems mods** - Expansion's market, AI, quests, territories and vehicles; trader mods; base-building overhauls - add the most, because they add running systems and persistent state, not just items. Expansion is modular, so a server can run its core and base-building modules without its AI and market, and the difference in memory and CPU is substantial. Install the modules you will actually use. [The DayZ Expansion mod server guide](https://www.renode.space/blog/dayz-expansion-mod-server) covers the modules and their setup order. #### A worked example: 40 slots with Expansion A community wants a 40-slot Chernarus server with Expansion's core, base-building, vehicles and market modules, a weapons pack, a clothing pack and a handful of admin and quality-of-life mods. Their loot is vanilla with weapons raised by half. Here is how to size it without guessing. 1. **Start from the table.** Forty slots vanilla is 6 to 8 GB. Expansion's systems and two content packs put it in the modded row, 10 to 12 GB. Begin with 10 GB and the expectation of moving up. 2. **Measure the floor.** Start the server with the full mod list, nobody connected, and `logMemory` on. Wait for the economy to finish spawning loot - this takes a while after start - and note the figure. That is the floor for this mod list and loot setting. 3. **Measure a full evening.** Let the server run a whole restart cycle at peak time with thirty-plus players. Note memory at the end of the cycle, just before the scheduled restart, and the lowest server FPS. 4. **Decide.** If the end-of-cycle figure is under about 85% of the plan and FPS stays healthy, the plan is right. If memory is close to the limit, either move up a tier or shorten the restart interval from four hours to three. If FPS sags while memory is fine, the answer is fewer AI, fewer infected or a lighter market, not more memory. 5. **Repeat after the first month.** Persistence will have grown with every base, so the end-of-cycle figure in week five is the one that matters for the long run. In practice a server like this usually settles between 9 and 11 GB at the end of a cycle in its second month, which is why 12 GB is the comfortable plan and 10 GB the tight one. The numbers on your server will differ; the method will not. #### Restarts are part of the design DayZ servers restart on a schedule, typically every three to four hours. It is not an admission of failure: server FPS degrades over a long session, memory climbs as the economy and players spread across the map, and the restart writes persistence cleanly and returns the server to its floor. The restart is also when loot and infected redistribute, and players have come to expect it. The mission's `db/messages.xml` can announce restarts and shut the server down at a set uptime, and a panel schedule can run the restart and a backup on a cron expression. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers choosing the interval. On RE:NODE the Restart button is a clean stop, so persistence is written before the process ends; a server that hits its memory limit is stopped and restarted clean rather than left to swap. That is safe for the node and abrupt for players, which is one more reason to keep a margin under the limit rather than running at the edge. DayZ plans on RE:NODE start at 6 GB with three port allocations, from $19 a month, up to 12 GB at the top of the ladder - the right shape for a 40-slot vanilla server at the bottom and a big Expansion server at the top. The install needs a Steam login that owns the game, entered on the Setup tab; a spare account is the sensible choice. #### FAQ ##### Is 6 GB enough for a DayZ server? For a 30 to 40-slot vanilla server or a lightly modded one, yes. For a heavily modded server with Expansion's systems, traders and AI, plan on 10 to 12 GB. Turn on `logMemory` in `serverDZ.cfg` and read a full cycle before deciding. ##### Does DayZ use more RAM with more players? Directly, not much. Each player costs some network and inventory state. Indirectly, more players build more bases, hoard more items and spread further across the map, and that is where the memory goes. Mods have a larger effect than slots. ##### Why does my DayZ server get slower before each restart? Server FPS degrades over a long session as objects, bodies and player activity accumulate, and memory climbs with it. That is why DayZ servers restart every few hours. If it gets bad within an hour of a restart, look at loot multipliers, infected count and heavy mods. ##### Will doubling the loot use more memory? Yes. The central economy keeps item counts near their `nominal` targets, so doubling nominals roughly doubles the number of loot objects on the map. It also adds work for the economy and for persistence. Raise the item types players want, not everything. ##### How much RAM does DayZ Expansion need? Plan on 10 to 12 GB for a server running most of Expansion's modules with 30 to 50 players. The AI, market and vehicle modules add the most. Running only the modules you use, and keeping trader stock and AI counts sensible, keeps it towards the lower end. DayZ servers on RE:NODE run from 6 GB to 12 GB with three port allocations, backup slots on every tier and a Schedules tab for the restart and backup cycle. The console graphs memory and CPU against the plan's limits, and moving up a tier raises them on the server you already have. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ types.xml: editing the loot economy Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/dayz-types-xml-and-loot-economy DayZ does not scatter loot randomly. Every item on the map is placed by the central economy, a bookkeeping system that counts what exists, compares it against a target, spawns what is missing into positions that match, and deletes what nobody has touched for long enough. `types.xml` is the ledger it works from: one entry per item class, with a target count, a floor, a lifetime, a restock timer and a list of the places the item is allowed to appear. Once you know that, most loot complaints have obvious answers. A town is bare because the items that belong there are already on the map somewhere else, or because their entry never had a matching usage. A mod's guns do not spawn because the mod's items were never added to the economy at all. And a server that emptied out overnight usually did not lose its loot - it lost a closing tag, and the file stopped parsing. This is the detailed version of [a DayZ server that survives its own mod list](https://www.renode.space/blog/dayz-server-and-mods). It covers the files, the fields, events, mod items, and a routine for editing that will not cost you a wipe. #### Where the economy files live Everything is inside the mission folder, which for standard Chernarus is `mpmissions/dayzOffline.chernarusplus/`. Livonia is `dayzOffline.enoch` and other maps follow the same pattern; the mission in use is set by `template` in `serverDZ.cfg`. | File | What it holds | | --- | --- | | `cfgeconomycore.xml` | Which economy files to load, including your own | | `db/types.xml` | Every item: counts, lifetimes, where it may spawn | | `db/events.xml` | Vehicles, helicopter crashes, dynamic spawns | | `db/globals.xml` | Global limits and timers for the whole economy | | `db/economy.xml` | Which persistence categories load and save | | `db/messages.xml` | Timed server broadcasts, and usually the restart | | `cfgspawnabletypes.xml` | Attachments and cargo on spawned items | | `cfgrandompresets.xml` | Named cargo and attachment presets | | `cfgeventspawns.xml` | The coordinates each event may use | | `cfglimitsdefinition.xml` | The legal names for category, tag, usage and value | | `cfgplayerspawnpoints.xml` | Where players arrive | | `storage_1/` | Persistence: the world state that survives a restart | Two of those are more useful than their names suggest. `cfglimitsdefinition.xml` is the authoritative list of what you are allowed to write in a `usage` or `value` element on your map, which saves a great deal of guessing. And `cfgeconomycore.xml` is how you add files of your own without editing anyone else's, which is the single best habit in DayZ administration. The economy files are read when the mission starts. Nothing here is live. Every change means a restart, and a change made while the server is running is a change made to a file the server has already finished reading. #### How the central economy actually decides The economy runs in passes. On each pass it does roughly this: ```diagram title: One pass of the central economy count = Count on map | the flags decide compare = Compare | against min and nominal queue = Spawn queue | restock gates rate place = Loot position | usage and tier match clean = Cleanup | lifetime expired count -> compare compare -> queue : below min queue -> place place --> count : next pass clean --> count ``` Three consequences follow, and they explain most of what looks like broken loot. **`nominal` is a target, not a promise.** The economy will not create an item it has nowhere to put. If an item's `usage` list does not match any building on the map, or its `value` tier does not exist in any region, the nominal can be 500 and you will never see one. **Items already in the world count against the target.** That is what the flags are for, and it is why a server where everyone has a full tent can have empty towns. The economy is doing exactly what you told it: the guns exist, so it is not making more. **Nothing happens instantly.** `restock` gates how often a type may be topped up, and `lifetime` decides when an untouched item is cleaned away to free the slot. Raising a nominal does not fill the map in five minutes; it raises the ceiling that the next few hours of restocking will climb towards. #### Reading a types.xml entry A full entry looks like this. Every field is optional except the name and the counts, but a well-formed entry has all of them: db/types.xml: ```xml 15 14400 1800 8 -1 -1 100 ``` | Field | What it means | | --- | --- | | `nominal` | The target number on the map when the counting flags allow | | `min` | The floor. Below this the economy starts putting more back | | `lifetime` | Seconds an untouched item survives before cleanup | | `restock` | Seconds before this type may be topped up again, `0` for as soon as possible | | `quantmin` / `quantmax` | Fill percentage for anything with a quantity, `-1` for the default | | `cost` | Spawn priority, 0 to 100, when several candidates fit one slot | | `category` | Broad group: weapons, clothes, containers, explosives, food, tools | The flags decide what counts towards `nominal`, and they are the most under-used tool in the file: | Flag | Set it to 1 when | | --- | --- | | `count_in_map` | Items lying loose in the world should count. Almost always 1 | | `count_in_cargo` | Items inside containers on the ground should count | | `count_in_hoarder` | Items in tents, barrels and buried stashes should count | | `count_in_player` | Items carried by players should count | | `crafted` | The item is one players make, not one the economy places | | `deloot` | The item may appear at dynamic events such as crash sites | If a high-value item feels far too common on a long-lived server, the usual cause is `count_in_hoarder` and `count_in_player` sitting at `0`. Every rifle players squirrel away is invisible to the economy, so it keeps producing replacements until there are hundreds in tents and fifteen on the map. Setting both to `1` for weapons and ammunition ties supply to what actually exists, and it is the closest thing DayZ has to a loot economy that behaves like an economy. `lifetime` is the other lever people forget. A short lifetime on junk keeps positions free for things worth finding. A long one on rare items means they sit in the woods where somebody dropped them, occupying a slot that could have held a new one. #### usage, value and tag: where an item may appear Three elements control placement, and all three are repeatable. An entry with several `usage` lines may appear in any of those area types. - **`usage`** names the kind of building or area: `Military`, `Police`, `Medic`, `Firefighter`, `Industrial`, `Farm`, `Hunting`, `Office`, `School`, `Prison`, `Town`, `Village`, `Coast`. - **`value`** names the loot tier, which is roughly how far from the coast and how dangerous the region is. Chernarus has been through several tier reworks, and newer maps have more tiers than older ones. - **`tag`** names the kind of loot position: `floor`, `shelves`, `ground`. Do not take that list as gospel for your map. The names that are legal are defined in `cfglimitsdefinition.xml` in your own mission folder, and `cfglimitsdefinitionuser.xml` lets you group them under names of your own. Open both before you invent a usage. A usage or value that does not exist is not an error you will be shown; it is an item that never spawns. Bohemia's own reference for the whole system is the [Central Economy mission files](https://community.bistudio.com/wiki/DayZ:Central_Economy_mission_files_modding) page, and it is the only external document worth having open. An entry with no `usage` at all cannot be placed by the building loot system. That is deliberate for items that only arrive through an event or as cargo inside something else - and it is the answer when a perfectly valid entry with a healthy nominal produces nothing. #### events.xml and the things that are not loot Vehicles, helicopter crashes, police cars, boats and the dynamic infected that come with them are not items. They are events, defined in `events.xml`: db/events.xml: ```xml 4 2 5 1800 0 500 500 1500 fixed mixed 1 ``` `saferadius` keeps an event from spawning on top of a player. `distanceradius` keeps two of the same event apart. `cleanupradius` is how close a player must be before the event's leftovers are removed. `position` is `fixed` for events placed at coordinates and `player` for ones that spawn near someone. `active` is the on switch. The `children` are the classnames the event may actually place, with how many of each. The coordinates themselves are in `cfgeventspawns.xml`, one block of positions per event name. Adding more cars to a map therefore means two edits: raising `nominal` in `events.xml`, and making sure there are enough spawn points listed for it in `cfgeventspawns.xml`. Raising the nominal alone gets you nothing, because the economy has run out of places to put them. Vehicles have one more wrinkle. A wreck still counts unless the event's `remove_damaged` flag clears it, so a server where players have destroyed every car can reach its nominal without a single drivable vehicle existing. #### Custom ce folders, and mod items that never spawn A mod adds classnames. It does not add economy entries, and the economy will not spawn a class it has never heard of. That is the whole explanation for the most common DayZ support question: the mod is loaded, the guns are in the files, and nothing spawns them. Most mods ship their own types file. The correct place for it is a folder of your own, registered in `cfgeconomycore.xml`: cfgeconomycore.xml: ```xml ``` Create `custom/` in the mission folder, drop the mod's files in, and list each one with the right `type`. The custom types file is an ordinary `` document containing only the mod's entries. Why bother, rather than pasting the entries into `types.xml`? Because a DayZ update replaces the mission files. Anything you added to `types.xml` is gone; anything in your own folder survives, and re-registering it is one line. Keep your own additions in your own files and you will lose an afternoon to updates instead of a weekend. Two follow-ups when a mod item still behaves oddly: - **It spawns empty.** A rifle with no magazine and no optic needs an entry in a spawnabletypes file, which is where attachments and cargo are defined. - **It appears everywhere.** The mod author set a generous nominal and a wide usage list to make sure you would notice it. Those are your numbers to change now, and a mod's defaults are a suggestion rather than a balance decision. Keeping the mod list and the economy in step is most of the work on a modded server, which is also the theme of [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean). #### A routine for editing without emptying the map The economy has no validation step that a player will ever see. A malformed file is not an error at the join screen; it is a server that starts, runs, and contains nothing. 1. **Keep a pristine copy of the mission folder.** Before the first edit, copy it somewhere off the server. This is the only thing that makes step 6 possible. 2. **Edit one file at a time**, with the server stopped. The panel's in-browser editor with syntax highlighting is enough, and it will show you a tag that does not close; [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers pulling the whole folder down instead. 3. **Validate the XML before you restart.** Any validator will do. Most broken DayZ economies are one missing `/` in a closing tag. 4. **Restart, and read the log.** The server writes an `.RPT` file in its profiles folder at every start, and economy parse failures are in it, named by file. 5. **Give it time before judging.** Restock timers and lifetimes mean a change takes hours to be visible, not minutes. Do not make a second change while waiting to see the first. 6. **If the map is empty, put the pristine copy back** and redo the edit. Do not debug a live wipe. > [!WARNING] > Lowering a nominal does not remove the items that already exist. They stay until their lifetime expires or a player destroys them, so a server that was too generous stays too generous for a while after you fix it. Raising a nominal, equally, fills in over hours. Judge an economy change the next day, not the same evening. #### Persistence, storage and wipes `storage_1/` holds everything the world remembers: the `.bin` files that record dynamic objects, vehicles and built structures, and `players.db` with the characters. The economy's own state lives alongside them. - **Deleting `storage_1` is a full wipe.** Tents, vehicles, bases, characters, all of it. - **Deleting only `players.db`** resets characters and leaves the world standing, which is the "character wipe" people usually mean. - **`storageAutoFix = 1;` in `serverDZ.cfg`** lets the server repair a damaged persistence file at start instead of refusing it. Set it. The alternative to an automatic repair is not an intact file, it is a manual one. A structural change to the economy - a new map, a mod that changes item classes, a rework of tiers - generally wants a wipe, because the old persistence refers to a world that no longer exists. A tuning change to nominals does not. Restarts themselves are part of DayZ administration rather than an interruption to it. Most servers restart every three or four hours, both to clear accumulated state and because several economy behaviours only reset at mission start. `db/messages.xml` broadcasts the warnings on a timer and, in current versions, can carry the shutdown itself. The alternative is a scheduler outside the game: on RE:NODE that is the Schedules tab, where a cron expression runs ordered tasks with delays, so one schedule can send a warning, take a backup and then restart the server. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers how often is too often, and [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) has the rest of the list. Back up the mission folder and `storage_1` together, because restoring one without the other gives you an economy that disagrees with the world. Backup slots on RE:NODE's DayZ plans are stored off the machine they protect and restore with a button, which is what you want at the point where the map has gone empty and nobody is sure which edit did it. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is the argument for testing that before the bad day. #### Troubleshooting **The whole map is empty after an edit.** The file failed to parse. Check the `.RPT` for the filename, or just restore your pristine copy and redo the change. **A mod's items never spawn.** No economy entry. Register the mod's types file in a custom `ce` folder. **I raised the nominal and nothing changed.** Restock timers, or no matching loot positions. Confirm the `usage` and `value` names exist in `cfglimitsdefinition.xml` for your map. **Towns are bare but the players have everything.** Working as configured. Set `count_in_hoarder` and `count_in_player` to `1` on the item types you care about, and the economy will stop replacing what is already out there. **Military loot is everywhere it should not be.** Check `usage` and `value` on those entries rather than nominal. An item with `Town` in its usage list will appear in towns no matter how low you set the count. **Vehicles do not come back.** They are events. Check the event's `nominal`, whether `cfgeventspawns.xml` has enough positions, and whether destroyed wrecks are still counting. **The server starts but the log is full of economy warnings.** Usually a duplicate type name across two files, which happens when a mod's entries were pasted into `types.xml` and also loaded from a custom folder. Keep each class in exactly one place. #### FAQ ##### What is the difference between nominal and min in types.xml? `nominal` is the target number the economy aims for. `min` is the floor that triggers restocking. When the counted number drops below `min`, the economy starts adding more until it reaches `nominal`, subject to the `restock` timer. ##### Why does an item with a high nominal still never spawn? Either nothing counts it, or nothing can place it. Check `count_in_map` is `1`, then check that the `usage` and `value` names on the entry actually exist for your map in `cfglimitsdefinition.xml`. An entry with no `usage` cannot be placed as building loot at all. ##### Do I need to restart the server after editing types.xml? Yes. The economy files are read once, when the mission starts. Nothing in `types.xml`, `events.xml` or `cfgeconomycore.xml` applies to a running server. ##### How do I add a mod's items to the loot economy? Put the mod's types file in a folder of your own inside the mission, then register it in `cfgeconomycore.xml` with a `ce` block and `type="types"`. Attachments and cargo need a spawnabletypes file registered the same way. ##### Will editing the economy wipe my server? Tuning counts and lifetimes will not. Changing the map, or changes that alter which item classes exist, generally will, because the saved world refers to objects that are no longer defined. Back up `storage_1` and the mission folder together before either. ##### How long until a loot change is visible? Hours rather than minutes. Existing items have to reach the end of their lifetime before their slots free up, and restock timers pace how fast replacements appear. Make one change, wait a day, then judge it. DayZ servers on RE:NODE come with SFTP and an in-browser editor with syntax highlighting, which is what this game is actually administered with, plus backup slots stored off the machine they protect and a Schedules tab for the restart cycle. The install waits on the Setup tab for your Steam login, so bring a spare account. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### DayZ server setup, mods and economy Published 2026-07-24, updated 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/dayz-server-and-mods DayZ has two systems that new administrators meet in the wrong order: mods, which everybody starts with, and the central economy, which decides whether the map contains anything worth finding. A perfectly modded server with an untouched economy is an empty one. Getting both right needs roughly 6 GB of memory for a 40-slot server, three UDP ports, a Steam account that owns the game, and a willingness to edit XML and restart. This guide covers the whole path: install, `serverDZ.cfg`, ports, mods and their keys, the economy files, administration, and the failures that fill support tickets. #### What you are actually running The DayZ server is a separate Steam application - `DayZ Server`, app id `223350` - and unlike most games it is **not** available to an anonymous SteamCMD login. You need a Steam account that owns DayZ, and SteamCMD will ask it for Steam Guard confirmation the first time. Hosts that install DayZ for you are doing so with your credentials for exactly this reason. Use a spare account that owns the game and nothing else valuable; a game-server install has no business holding the account you buy things with. What the server gives you out of the box is thinner than people expect: - **One mission folder** under `mpmissions`, which is both the map and the economy. Chernarus is `dayzOffline.chernarusplus`, Livonia is `dayzOffline.enoch`, and the later maps have their own folders - read the directory rather than guessing the name. - **A config file**, `serverDZ.cfg`, holding around forty settings. - **BattlEye**, which handles anti-cheat, bans and remote administration. - **No in-game admin menu at all.** There is no spectate, no teleport, no item spawning, no player list. Every administrative tool you have ever seen on a DayZ server is a mod or an external RCon client. - **A persistent world** stored separately from the mission files, so you can edit the economy without wiping player bases - most of the time. The mission folder is the important idea. When you edit loot, you are editing files inside `mpmissions/dayzOffline.chernarusplus/`, and those files are read at start-up. Nothing you change there takes effect until the server restarts, which is why DayZ administration has a rhythm of edit, restart, look, edit again. #### Requirements and resource usage DayZ is a heavy server for its player count. It simulates infected, animals, vehicles and an item economy across a 225 square kilometre map, and it leans hard on one thread. | Players | RAM | CPU | Notes | | --- | --- | --- | --- | | 10-20, vanilla | 4-6 GB | 2 cores | Comfortable; good for a private group | | 30-40, vanilla | 6-8 GB | 2-3 cores | The common public server | | 40-60, vanilla | 8-10 GB | 3+ cores | Server FPS becomes the limit, not memory | | 30-50, heavily modded | 10-12 GB | 3+ cores | Expansion-scale mod lists, traders, AI | - **CPU** decides how a full server feels. The metric to watch is server FPS, logged if you set `logAverageFps`. Healthy is above 30; below about 15 players start reporting rubber-banding, desynced loot and doors that open twice. - **Memory** grows with the mod list far faster than with the player count. A vanilla 60-slot server uses less than a 30-slot server carrying a large Expansion build. - **Disk**: the server install is roughly 3 GB, and each mod adds its own. A mod list of twenty is easily another 10-15 GB, which is why DayZ plans start with more disk than a game this old suggests. - **Network** is modest, a few hundred kilobytes per second per player, but it is UDP and latency-sensitive. The general rule in [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) applies here more than in most games: people buy memory when the thing that is actually saturated is one core. DayZ plans on RE:NODE start at 6 GB with three port allocations, which is the right shape for a 40-slot vanilla or lightly modded server. A big Expansion server wants the top of the ladder. #### Installing the server and the launch line On your own machine, SteamCMD with a real login: ```bash $ steamcmd +force_install_dir /home/dayz/server +login \ +app_update 223350 validate +quit ``` The server is then started with a long parameter line. These are the parameters that matter, and on a panel they appear as fields on the Startup tab rather than as text you type: | Parameter | Purpose | | --- | --- | | `-config=serverDZ.cfg` | The config file to read | | `-port=2302` | Game port | | `-profiles=profiles` | Where logs, BattlEye and crash dumps are written | | `-mod=@CF;@Mod2` | Client-and-server mods, semicolon separated, order matters | | `-servermod=@AdminTool` | Server-only mods that clients must not have | | `-doLogs` | Write the script and error logs | | `-adminLog` | Write the `.ADM` player activity log | | `-netLog` | Network traffic logging, useful once, noisy forever | | `-freezeCheck` | Dump a log if the server hangs | | `-cpuCount=2` | How many cores the engine is allowed to use | Put `-profiles` somewhere you can reach over [SFTP or the file manager](https://www.renode.space/blog/sftp-and-the-file-manager), because that folder is where every answer to "why did it do that" lives. If you are new to SteamCMD, app ids and the difference between `validate` and a plain update, [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers it. > [!WARNING] > Keep the Steam account you install with separate from your main one, and change its password if you ever hand the server to someone else. Credentials given to a host are stored as typed, everywhere, by everyone. #### serverDZ.cfg, key by key The file is a list of `key = value;` lines, semicolons included, with a mission block at the end. The values below are the ones shipped in Bohemia's example file, and they are a reasonable starting point rather than a recommendation. serverDZ.cfg: ```cfg hostname = "Chernarus - vanilla, no KOS in trader"; password = ""; passwordAdmin = "a-long-random-string"; maxPlayers = 60; verifySignatures = 2; forceSameBuild = 1; disableVoN = 0; vonCodecQuality = 20; disable3rdPerson = 0; disableCrosshair = 0; serverTime = "SystemTime"; serverTimeAcceleration = 12; serverNightTimeAcceleration = 1; serverTimePersistent = 0; loginQueueConcurrentPlayers = 5; loginQueueMaxPlayers = 500; instanceId = 1; storageAutoFix = 1; steamQueryPort = 2305; respawnTime = 5; timeStampFormat = "Short"; logAverageFps = 300; logMemory = 300; logPlayers = 300; logFile = "server_console.log"; adminLogPlayerHitsOnly = 0; enableDebugMonitor = 0; allowFilePatching = 0; multithreadedReplication = 1; speedhackDetection = 1; class Missions { class DayZ { template = "dayzOffline.chernarusplus"; }; }; ``` The ones worth thinking about rather than copying: - `verifySignatures = 2` refuses any mod whose `.bikey` is not in the server's `keys` folder. Leave it at 2. Dropping it to 0 is how servers end up running somebody else's modified PBOs. - `forceSameBuild = 1` rejects clients on a different game build. Turning it off does not make an out-of-date client work; it makes it fail later and less clearly. - `allowFilePatching = 0` blocks clients launched with `-filePatching`, which is how a lot of casual cheating arrives. Only mod developers need it on. - `serverTimeAcceleration` multiplies the in-game clock. `12` gives a two-hour day. `serverNightTimeAcceleration` multiplies again during the night, so `serverTimeAcceleration = 12` with `serverNightTimeAcceleration = 4` gives a long day and a short night - the single most requested change on any public server. - `serverTimePersistent = 1` makes the world clock survive a restart instead of resetting to `serverTime`. With four restarts a day and it set to 0, your server has the same morning four times. - `instanceId` selects the persistence folder, `storage_1` for instance 1. Two servers sharing a machine must not share an instance id. - `disableVoN = 0` keeps in-game voice. Turning it off is a bigger change to how the game plays than most settings in the file. #### Ports and connecting | Port | Protocol | Purpose | | --- | --- | --- | | `2302` | UDP | Game traffic, set by `-port=` | | `2303-2304` | UDP | Reserved beside the game port; hosts allocate the block | | `2305` | UDP | Steam query, set by `steamQueryPort` | | RCon port | UDP | BattlEye RCon, set in `BEServer_x64.cfg` | The query port is the one that catches people. The game runs, you can connect by IP, and the server never appears in the DayZ Launcher list - that is `steamQueryPort` blocked or wrong. Both are UDP; a firewall rule that only opens TCP does nothing at all here. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) goes through why a query port exists separately from the game port and what each failure looks like. Almost nobody joins a modded DayZ server from the in-game browser. They use the DayZ Launcher, which reads the mod list the server advertises, subscribes to those Workshop items, and launches the game with a matching `-mod=` line. That is the whole reason mod load order and keys have to be right: the launcher automates the client side and gives up loudly when the two sides disagree. ```diagram title: What has to line up before a modded player can join launcher = DayZ Launcher | reads the mod list query = Query port | 2305 UDP server = DayZ server | 2302 UDP be = BattlEye | signature check keys = keys/ folder | one .bikey per mod launcher -> query : finds the server launcher -> server : connect server -> be : verifySignatures 2 be -> keys : key must be present ``` #### Mods: keys, load order and the two flags Workshop mods are downloaded with SteamCMD against the **client** app id, `221100`, not the server's: ```bash $ steamcmd +force_install_dir /home/dayz/server +login \ +workshop_download_item 221100 1559212036 +quit ``` Then three things have to happen, and missing any one of them produces a different confusing symptom: 1. The mod folder, named `@SomeMod`, sits in the server root. 2. Its `keys/*.bikey` file is copied into the server's `keys` folder. Miss this and clients are kicked by BattlEye at the loading screen with a signature error, even though everything else is correct. 3. The folder is listed in `-mod=`, in dependency order. Frameworks first: `-mod=@CF;@DayZ-Expansion-Core;@DayZ-Expansion-Bundle`. Community Framework (`@CF`) is a dependency of a great many mods and must load before them. Use `-servermod=` for anything the client should not have: admin tools, loot spawners, server-side tweaks. Mods in `-servermod=` are not advertised to the launcher, so players are not asked to download them. Putting a server-only mod in `-mod=` by mistake makes every joining player download something they have no use for. Two habits save entire servers. First, pin your mod list and update it deliberately rather than automatically - a DayZ patch invalidates every mod until its author rebuilds, and a server that auto-updates on patch day is a server nobody can join on patch day. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is worth reading before you need it. Second, keep a copy of the working mod folder and your XML before every update. [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers) covers how Workshop downloads behave server-side across games. #### types.xml and the central economy This is the part that decides whether your server is worth playing. Loot is not scattered at random. The central economy holds a target population of every item on the map and refills toward it, and the rules live in XML inside your mission folder. | File | What it controls | | --- | --- | | `db/types.xml` | Every item: how many exist, how long they last, how fast they come back | | `db/events.xml` | Vehicles, helicopter crashes, infected and animal spawns | | `db/globals.xml` | World-wide limits such as `ZombieMaxCount` and cleanup timers | | `db/messages.xml` | Scheduled broadcasts, including the one that shuts the server down | | `db/economy.xml` | Which economy subsystems load at all | | `cfgeconomycore.xml` | Which XML files are read, including your own custom ones | | `cfgspawnabletypes.xml` | What attachments and cargo an item spawns with | | `cfgeventspawns.xml` | The coordinates events are allowed to use | | `cfgplayerspawnpoints.xml` | Where fresh spawns and respawns appear | A `types.xml` entry looks like this. The numbers are illustrative - read the shipped file for the real ones: db/types.xml: ```xml 8 7200 1800 4 -1 -1 100 ``` Each element does a specific job, and five of them decide almost everything: - `nominal` is the target number on the map. `min` is the floor: when the live count drops to it, the economy queues more. - `lifetime` is how many seconds an untouched item survives before cleanup takes it. Picking it up and putting it down resets the clock. - `restock` is the delay before the economy is allowed to replace what was taken. `0` means as soon as it can. - `cost` is a spawn priority between 0 and 100 - which of the eligible items gets the slot. - `usage` and `value` decide where it can appear: `usage` is the building type (Military, Police, Medic, Farm, Industrial, Town, Village, Hunting), `value` is the loot tier, higher tiers being further from the coast. An item with no usage and no value spawns nowhere, which is the single most common self-inflicted wound in DayZ administration. - The `flags` attributes decide what counts against `nominal`. `count_in_cargo="1"` means items inside containers count, so a hoarding clan can starve the map of an item without anything being broken. Three consequences follow from that mechanism. A town that feels bare is usually a `nominal` problem, not a spawn-rate setting you cannot find. Raising `nominal` across the board does not multiply loot forever, because the total is also bounded by the loot points on the map. And an item whose `lifetime` is short disappears from a base you left for a week - use a container, which has its own lifetime. Mods that add items need their entries too. A weapons mod that appears to do nothing is almost always a mod whose items were never registered with the economy: the mod is loaded, the guns exist in the game files, and nothing spawns them. The right fix is not to paste the mod's entries into the vanilla `types.xml`, which a game update will overwrite. Register a custom folder in `cfgeconomycore.xml` instead: cfgeconomycore.xml: ```xml ``` Now your additions live in `mpmissions/dayzOffline.chernarusplus/custom/mod_types.xml` and survive being patched over. [types.xml and the loot economy](https://www.renode.space/blog/dayz-types-xml-and-loot-economy) takes the whole system apart in detail. Persistence is separate from all of this. Player bases, stashes, vehicles and character data live in `storage_` beside the mission folder. Editing the economy does not wipe them. Deleting that folder does - that is a wipe, and it is the only reliable one. Keep a copy first, and keep it somewhere other than the server: [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) exists because a backup nobody has restored is a hypothesis. #### Administration: RCon, logs and restarts Administration is BattlEye RCon plus whatever admin mod you chose. `passwordAdmin` in `serverDZ.cfg` should be long and random even though vanilla gives you almost nothing to do with it; the RCon password is separate and lives in `BEServer_x64.cfg` in the BattlEye folder inside your profiles directory. BattlEye's own command set, typed into an RCon client or the panel console, is small: | Command | Effect | | --- | --- | | `players` | Connected players with their IDs and pings | | `kick ` | Kick by session id | | `ban ` | Ban a connected player, 0 for permanent | | `addBan ` | Ban someone who is not connected | | `bans` / `removeBan ` | List and lift bans | | `say -1 ` | Broadcast to everyone | | `loadBans` / `loadEvents` | Re-read the BattlEye files without a restart | | `#shutdown` | Stop the server | Bans are stored in `bans.txt` as BattlEye GUIDs, which are derived from the SteamID and are not the SteamID. Copy them out of the logs rather than converting them by hand. If you are exposing RCon at all, read [RCON safely](https://www.renode.space/blog/rcon-safely) first - the protocol is UDP, the password is the whole of the authentication, and DayZ servers are scanned constantly. The logs in your profiles folder are the other half of the job: - `server_console.log` - everything the console printed, which is where start-up errors in your XML appear. - `*.ADM` - the admin log: connects, disconnects, positions, deaths, hits, who killed whom and with what. This is the file you read after every argument about a base raid. - `script*.log` - script errors, including from mods. - `crash_*` and `*.mdmp` - what to send a mod author. DayZ servers are restarted on a schedule, typically every three to four hours, because server FPS degrades as the session goes on and because a scheduled restart is a controlled save. You can do it purely in `db/messages.xml`, where a message entry can carry a shutdown, and the panel's Schedules tab can run the restart plus a backup with a cron expression - see [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) for what interval is actually worth it. On RE:NODE the Restart button is a clean stop, a watcher notices a server that keeps restarting by itself and opens a ticket rather than leaving it in a loop, and a server that hits its memory limit is stopped and restarted clean instead of being left to swap. #### Troubleshooting **The server runs but is not in the DayZ Launcher list.** Query port. Check `steamQueryPort` matches an allocated UDP port and that nothing else on the machine claims it. **Players are kicked with a BattlEye signature error.** A `.bikey` is missing from the `keys` folder, or a mod updated and shipped a new key. Copy every mod's key again after every mod update. **"You cannot play/edit this mission; it is dependent on downloadable content that has been deleted."** The client's mod list does not match the server's - usually a mod the launcher did not download, or a version mismatch. Have the player verify through the launcher, not through Steam. **Loot did not change after editing `types.xml`.** Either you did not restart, or the file failed to parse and the economy fell back. Read `server_console.log` from the top: a malformed XML file is named there with the element that broke it. **An added mod's items never spawn.** They have no economy entries, or they have entries with no `usage` and no `value`. See above. **Everything is slow when the server fills.** Check logged server FPS before buying memory. High infected counts, large mod lists and dozens of persistent vehicles all cost CPU rather than RAM. **Bases vanished after an update.** Persistence in `storage_` was reset or the instance id changed. There is no recovery without a backup of that folder. **The world clock resets every restart.** `serverTimePersistent = 0`. #### FAQ ##### Can I run a DayZ server without owning DayZ? No. The server application is not available to an anonymous SteamCMD login, so a Steam account that owns the game has to be used for the install. Use a spare account rather than your main one. ##### How many players can a DayZ server hold? `maxPlayers` goes well past 60, but the practical limit is CPU. Most public servers run 40-60 and start losing server FPS above that, especially with a large mod list. Player count is rarely what breaks a DayZ server; the mod list is. ##### Do I have to restart every few hours? Not strictly. The server will keep running. But server FPS drifts down over a long session, a restart is a clean save, and most mod-heavy servers are visibly better after one. Three to four hours is the community norm; announce it with `db/messages.xml` so nobody loses a raid to it. ##### Does editing the loot economy wipe the map? No. Loot and persistence are separate. Editing `types.xml` and the other economy files changes what spawns from the next restart; player bases, stashes and characters in `storage_` are untouched. A wipe means deleting that storage folder deliberately. ##### Why does the mod work for me but not for anyone else? You have the mod locally and the server does not advertise it, or it is in `-servermod=` when it needs to be in `-mod=`. Client-and-server mods belong in `-mod=` with their key in `keys`; only genuinely server-side mods belong in `-servermod=`. ##### Where do I look first when something is wrong? `server_console.log` and the `.ADM` file in your profiles folder, in that order. Half of DayZ administration is XML, and the other half is reading the log that tells you which line of it you got wrong. DayZ servers on RE:NODE start at 6 GB with three port allocations, SFTP and an in-browser file editor for the XML this game is configured in, backup slots on every tier, and a Schedules tab for the restart cycle. The install needs your own Steam login, which you enter on the Setup tab after the server is created. [See DayZ plans](https://www.renode.space/game-servers/dayz) ## Rules for the assistant - Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead. - Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository. - An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port. - On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker. - Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak. - Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository. - Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current. - For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one. - If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.