VPP Admin Tools (Vanilla++ AdminTools in the DayZ mod list) gives you an in-game admin menu for player management, item spawning, teleporting, ESP, weather and time control, bans and more. Installing it takes three things: add it alongside Community Framework in Workshop Mods, start the server once so it writes its config files, then set an admin password and add your Steam64 ID before restarting again.

That two-restart sequence is not optional and it is where almost everyone gets stuck — the mod cannot read the files it created until the next boot, so the first start always ends with nobody having access. Work through the steps in order and it takes about twenty minutes.

Before you start

• A provisioned server here, stopped. If you are brand new, start with getting started with the control panel.
• Your own Steam64 ID — the 17-digit number beginning 7656. Find it with steamid.io or any Steam ID lookup.
• A password you will use to log in to the admin menu in game. It must be 32 characters or fewer.
• Access to the File Browser or SFTP tab, since two config files need editing by hand.

1. Add VPP Admin Tools and Community Framework

Open your server, go to Workshop Mods, and add both mods. Paste each Workshop URL or ID into the box and click Lookup & add:

• Community Framework — search the Steam Workshop for Community Framework (often abbreviated CF).
• VPP Admin Tools — Workshop ID 1828439124, or search for VPP Admin Tools.

Community Framework must load before VPP Admin Tools. Use the arrows in the Order column so CF sits above it in the list.

2. Start the server once to generate the config files

Go back to Overview and click Start. This first boot exists purely so the mod can create its folder structure — you will not be able to log in yet, and that is expected.

Watch Live Logs with the Stream dropdown set to rpt. Once the mission has loaded, stop the server again.

3. Find the generated files

The mod writes everything into your server's profile folder. In the panel that is the profiles share — open File Browser and switch the Share dropdown to profiles, then open VPPAdminTools.

You should see:

4. Set your admin password

Open Permissions/credentials.txt with View/Edit. It contains only comment lines beginning with //. Delete everything and put your password on the first line, on its own:

MySecretPassword123

Everyone who logs into the admin menu uses this one password, whether they are a superadmin or in a staff group. If you ever lose it, empty the file, write a new password, and restart.

5. Add yourself as a superadmin

Open Permissions/SuperAdmins/SuperAdmins.txt. It contains a single placeholder sentence. Delete that line and replace it with your Steam64 ID:

76561198000000000

Add more admins one per line, with nothing else on the line:

76561198000000000
76561198000000001

Superadmins bypass every permission check, so keep this list to people you genuinely trust. Staff who need only some tools should get a user group instead, which you set up in game in step 7.

6. Restart and log in

Start the server again. This is the boot where the mod actually reads both files, hashes your password and loads your admin list.

Join your server, then use the two-step login. These are separate keys and the order matters:

1. Press End to log in. A password prompt appears — enter the password from credentials.txt.
2. Press Home to open the admin menu.

Your password is remembered on your own machine after the first successful login, so later sessions only need End then Home.

7. Learn the default keybinds

Beyond the two login keys, these are bound out of the box. All of them can be changed under Options → Controls in the vpp category.

The menu itself has thirteen sections: Player Manager, Items Spawner, Teleport Tools, ESP Tools, Console, Server Settings, Weather Editor, Object Builder, Bans Manager, Permission Editor, Webhooks, XML Editor and Spectate. You only see the buttons your permissions allow.

There are also chat commands, each with its own permission: /heal, /kill, /strip, /bring, /goto, /return, /tpt, /tpp, /ammo, /spawncar, /refuel, /unban and a few more.

8. Give your staff access without making them superadmins

Open Permission Editor in the admin menu. A default group called Admins already exists at permission level 1. Create groups, set which of the thirteen sections each can use, and add members by Steam64 ID. Changes made here save immediately — no restart needed.

Two things that surprise people:

• You will not find yourself in the Permission Editor. Superadmins live in SuperAdmins.txt, not in the group system, and cannot be added to a group.
• If a group has the forced name option enabled, members are locked out whenever their in-game name stops matching the name stored on their entry. Update the entry after anyone renames.

Everyone still logs in with the same password from credentials.txt; the group only decides what they can do once they are in.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• installing Steam Workshop mods
• connecting with SFTP

Every DayZ server restart kicks every connected player — there is no way around that, and any host who tells you otherwise is selling something. What you can control is whether players are warned in time to reach somewhere safe and whether they are disconnected cleanly, because a clean disconnect is what makes DayZ write each character to persistence. That is the whole difference between a routine restart and a wave of tickets about lost gear.

In the DZSERVERS.HOST panel that job belongs to Controlled Restart on the Overview tab: it broadcasts a countdown, locks the server with #lock so nobody joins mid-shutdown, kicks everyone through RCON, then stops and starts the instance while you watch an eleven-step timeline. This guide walks the whole sequence and shows what to do when it goes wrong.

Before you start

• The server must be Running. Controlled Restart is greyed out on a stopped instance — there is nothing to warn anyone about.
• The Start / stop / restart permission. Instance owners have it; sub-users need it granted under Members.
• A working admin and RCON password. The warnings, the lock and the kick all travel over BattlEye RCON, so if that password is wrong the restart cannot finish. Set it in Settings → Server & RCON Authentication — see getting started with the control panel.
• Ideally, backups already switched on in the Backups tab, so a bad night is recoverable rather than permanent.

1. See who is online, then pick a warning window

Open the Players tab and switch to Online to see who is actually connected right now. An empty server needs no ceremony — a plain Restart is fine. Twenty people mid-raid need the longest warning you can give them.

Controlled Restart offers three windows, and each one fires a different ladder of in-game broadcasts:

Ten minutes is the sensible default for a populated server. Five is enough for a quiet one. Fifteen is for when you know a big fight or a base build is in progress and you would rather not be the reason it ends badly.

2. Start the Controlled Restart

Go to the instance Overview tab. In the power control bar you will find Start, Stop, Restart, Controlled Restart and Update. Click Controlled Restart and a small menu drops down headed Warn players, then restart in: with three choices: 5 minutes, 10 minutes and 15 minutes.

Pick one. The button briefly reads Queuing… and you get a confirmation such as Controlled restart queued (10 min warning). A live timeline card appears directly above the Overview card and stays there for the whole run.

The button is unavailable in four situations, and the tooltip tells you which:

• Server is not running — start it first.
• A controlled restart is already in progress — only one can run per instance at a time.
• Cannot restart while an update is in progress — wait for the game-data update to finish.
• Instance not provisioned — the instance is not ready yet.

3. Tell your players what to do with the warning

The broadcasts go out over BattlEye as global chat messages, so they land in the in-game chat box and nowhere else. Players with chat scrolled away, or sitting in a menu, can miss one. That is why the ladder repeats rather than announcing once.

The default wording is deliberately plain — Server restart in 10 minutes. down through Server restart in 30 seconds., followed at zero by Server restart is starting now. You will be kicked shortly.

Put this in your rules channel once and point at it forever. When a player sees a restart warning they should:

1. Break contact. Do not start a fight, a raid or a heli crash run inside the warning window.
2. Finish whatever is in their hands — a half-completed craft or an open inventory transfer is the easiest way to lose an item.
3. Move somewhere they are happy to reappear: away from other players, away from infected, off a roof, out of the water.
4. Log out normally before the kick if they want certainty. A manual disconnect and the panel’s kick both produce a clean disconnect, but leaving voluntarily means they choose the moment.

The reason the panel kicks players rather than simply killing the process is that a kick is a normal disconnect as far as the DayZ server is concerned. The server runs its usual disconnect path and writes the character out. Pull the process instead and there is no disconnect to run, so the character falls back to the last state the server committed — position, health and inventory included.

4. Watch the eleven-step timeline

The card is headed Controlled restart with a note of who triggered it — (manual) for a button press or (scheduler) for a scheduled task. While the countdown is running it shows Restart in and a live clock such as 4m 05s. Once the lock is in place a locked badge with a padlock appears next to the title.

Underneath, every stage of the process is listed in order. Completed stages turn green, the current one spins amber, and a failure marks the stage it died on in red.

Expand Step log for the timestamped detail: which warning went out when, the result of the lock and kick step, and the exact reason for any failure. Two extra states never appear in the list because they replace it: Failed and Aborted.

5. Abort while you still can

An Abort button sits at the top right of the timeline card during the first four steps only: Queued, Preparing, Sending warnings and Final warning. Click it and the run stops where it is, the card reads This restart was aborted before the destructive phase. and the server keeps running with everyone still connected.

The moment the process reaches Locking server the button disappears, and the API will refuse a late attempt with The restart has entered its destructive phase and can no longer be aborted. That boundary is deliberate: once the lock and the kicks are in flight, stopping halfway would leave you with a locked, empty, still-running server, which is worse than either outcome.

6. Confirm the server is back, then clear the card

Watch the last three steps. Starting server and Waiting for online are where a modded server takes its time; the panel allows roughly two minutes for the stop, three for the start and five more for the server to answer, and it gives up and reports a failure rather than hanging forever.

You are back in service when the timeline reaches Completed, the Server Status pill reads Running and Server FPS on the Overview tab reports a number again. Click Dismiss to clear the finished card.

If it ended in Failed instead, the reason is printed at the top of the card and repeated in Step log. Read it before touching anything — Server did not stop in time. and Lock/kick step failed or timed out. point at completely different problems.

7. Check the Audit Log trail

Every controlled restart writes itself into the Audit Log tab under the Scheduler category, so you can prove after the fact what happened and when. Filter to Scheduler and you will see the chain:

• Restart Queued
• Restart: Locking Server
• Restart: Kicking Players
• Restart: Stopping Server
• Restart: Starting Server
• Restart Completed, or Restart Failed / Restart Aborted

This is the record that settles arguments. When a player insists they lost a backpack “in the restart”, the audit trail shows whether a controlled restart ran at all, whether it completed, and whether it was a member of staff who pressed the button. Actions taken by sub-users are attributed to them by name — see staff permissions and API keys.

8. Automate it so you rarely do this by hand

Doing this manually is for one-off maintenance. Routine restarts belong in the Scheduler tab: click New task, set Task type to Restart (controlled) and give it a daily time or two. Scheduled runs use exactly the same eleven-step engine and show the same live timeline, and the Next run column tells you when the next one lands.

A scheduled restart task exposes more control than the three-option dropdown does. Under Restart process you can:

• edit the Warning broadcasts (before restart) ladder outright — change the offsets, rewrite the text, or Add warning for extra checkpoints;
• set the Final warning (at restart time) message;
• set the Kick reason players see, and the Post-kick delay (s) breathing room before the stop;
• turn off Lock the server (#lock) before kicking players, though there is rarely a good reason to.

Set the times to your quiet hours and you will mostly stop thinking about restarts. Full detail, including how the schedule handles time zones, is in automatic restarts with the Scheduler.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• Automatic restarts with the Scheduler
• RCON, bans, whitelist and priority queue

Your DayZ server is created automatically the moment your order completes, so there is no server to build and no wizard to run — it is already waiting for you in the panel under Instances. The five things worth doing on day one are: name it, set an admin and RCON password, add any mods you want, start it, and schedule a nightly restart.

This guide walks through that first run in order and points at the deeper guides for each area. Budget about fifteen minutes.

Before you start

• A completed order. Provisioning happens on its own straight afterwards, so if you have just paid, give it a minute and refresh.
• Your panel sign-in. Use your community account through Login via Frontend, or the local username and password you were sent.
• DayZ installed on your own PC if you want to connect and test — you will need it for the final step.

1. Sign in and open your server

Go to the control panel and sign in. If your account came from the community site, use Login via Frontend — that hands you straight over without a second password. Otherwise sign in with the local username and password you were issued.

You land on Instances. Click your server to open its Overview tab, which is the hub for everything else: the power controls, the live status, the connection details and the tab bar for every other feature.

2. Read the Overview tab

Before changing anything, get your bearings. The Overview tab shows you:

• Server Status — Running, Stopped or Updating. A brand new server reads Stopped.
• The connection block: IP, Game Port, Query Port and RCON Port. Your RCON port is always the game port plus three.
• Max Slots, Mission (the map, dayzOffline.chernarusplus by default) and Template (the game build).
• Connect with a Copy button, plus Direct Connect and List on DZSA Launcher links for sharing.
• Live CPU, RAM and Disk meters, Uptime and Server FPS once it is running.

Note the Auto game updates toggle. Leave it on: when Bohemia ships a new DayZ build, the panel stops your server, updates it and starts it again on its own, which is usually what you want.

3. Name your server and set the basics

Click Settings in the tab bar to open the Instance Settings panel. This is a proper editor for serverDZ.cfg — every field maps to a real config value, so you never hand-edit the file for routine changes.

At minimum, set:

1. Host Name — what players see in the server browser. Make it searchable: the map name and your key features help far more than decoration.
2. Description — one line, up to 255 characters.
3. Max Players — capped at the slot count you bought.
4. Password — leave empty for a public server.

Everything else has a sensible default. When you are ready to tune loot, day length, third-person or the admin logs, work through every serverDZ.cfg setting explained rather than guessing.

Click Save. You should see Changes Saved!.

4. Set your admin and RCON password

Scroll to Server & RCON Authentication in the same panel. This one password covers two things: the in-game admin login (passwordAdmin) and BattlEye RCON (RConPassword), which is what the panel’s own RCON console and any external admin tool authenticate with.

Click Regenerate for a strong value, or type your own. The engine is strict here:

• 4 to 10 characters, no more
• letters and numbers only — A-Z, a-z, 0-9

Hit Save password, then Copy and store it in your password manager. You will need it for RCON, bans and the whitelist.

5. Add mods now, if you want any

If you plan to run mods, add them before your first start so the world generates with them in place. Open Workshop Mods, paste a Steam Workshop URL or its numeric id, and click Lookup & add.

The panel resolves the mod’s dependencies for you and installs those first, which is the single most common cause of a modded server failing to boot. Load order, server-only mods and auto-updates all matter and all have real consequences, so work through installing Steam Workshop mods rather than improvising.

Running vanilla for now? Skip this entirely. You can add mods at any time later.

6. Start the server and connect

Back on Overview, click Start. First boot takes longer than later ones because DayZ generates the persistence storage. Watch the Live Logs card underneath and switch the Stream dropdown to rpt to follow along.

You are up when Server Status shows Running, the Server Info panel fills in with your name and player count, and Server FPS reports a number.

Now test it from the game. Use Copy next to Connect to grab your ip:port, then in DayZ open the server browser, go to Community, paste it into the search box, and join. Your admin password is what logs you in in-game.

7. Set up a nightly restart and backups

Two pieces of housekeeping make the difference between a server that stays healthy and one you end up firefighting.

Nightly restarts. DayZ servers degrade over long uptimes. Open Scheduler, click New task, choose Restart (controlled) and set it to repeat daily at a quiet hour. The default warning ladder broadcasts at 10, 5, 3 and 1 minutes and again 30 seconds out, so players get a chance to log out somewhere safe. That is exactly what prevents the rollbacks and lost gear covered in restarting without rollbacks.

Backups. Open Backups and pick a frequency — Daily suits most servers. Backups are kept for 30 days and you can restore Players DB, World Data and mission XMLs independently, which matters when you only want to undo one of them. See automatic backups and restore.

Troubleshooting

Frequently asked questions

Related guides

• Restarting without rollbacks
• every serverDZ.cfg setting explained
• installing Steam Workshop mods
• connecting with SFTP
• Automatic backups and restore

Every serverDZ.cfg value you are likely to want is already a typed field in the panel: open Instances → your server → Settings and the Instance Settings editor lists all thirty of them, each with its own help line underneath. This guide documents every field — the serverDZ.cfg key it writes, its accepted range and a recommended value — plus the two things people get wrong most often: how time acceleration maps to real day length, and what changing the map does to your persistence.

The editor only saves while the instance is Stopped, so plan a stop or a Controlled Restart before you start editing. Nothing here takes effect until the server boots again.

Before you start

• An instance you can stop. Save is disabled while the status pill reads Running.
• The Edit settings permission. Sub-users without it do not see the Settings button at all, and changing the map needs the separate Change mission permission — see staff permissions and API keys.
• Nothing else. You never need to open serverDZ.cfg by hand for any field listed below, although you can read it in File Browser under the config share if you want to check the panel’s work.

1. Stop the instance and open the editor

On Overview, click Stop and wait for the status pill to read Stopped. With players online, warn them with a Controlled Restart first — see restarting without rollbacks — then stop it.

Now click Settings in the tab bar. A dialog opens titled Instance Settings with your instance id beneath it. It contains, in order:

1. A two-column grid of all thirty serverDZ.cfg fields, each with its help text under it.
2. Edit Mission — the map selector, covered in step 7.
3. Server & RCON Authentication — the admin and RCON password, covered in getting started with the control panel.

Two behaviours are worth knowing before you touch anything. Grey placeholder text in a numeric or text box is DayZ’s own default, not a value you have set. And clearing a field removes that key from serverDZ.cfg entirely, which hands the setting back to the engine default rather than writing a zero. That is the correct way to undo a change you no longer want.

2. Identity and access: name, description, password and slots

These four are the only fields most servers ever change, and they are what a player sees before deciding whether to join. Treat Host Name as a search result rather than a title: the map name and your headline features earn far more clicks than decoration.

Max Players is the one field with a hard ceiling above it. Its help line tells you yours — Maximum amount of players. This instance's provisioned cap is 60. with your own number. Anything from 1 up to that cap is allowed; above it the save fails. The agent also re-checks the value before every launch and clamps it back down, so editing serverDZ.cfg by hand will not get you extra slots.

3. Time of day, and how long a day actually lasts

This is the group that generates the most confusion, because the two acceleration fields multiply together rather than acting independently.

Work the arithmetic through once and it stops being mysterious. Take a 24-hour in-game cycle split evenly into 12 hours of daylight and 12 of night; the real split shifts with the map and the date, but even is close enough to plan with. With Server Time Acceleration at 8 and Server Night Time Acceleration at 4:

• Daylight runs at 8×, so 12 in-game hours take 90 real minutes.
• Night runs at 8 × 4 = 32×, so 12 in-game hours take 22.5 real minutes.
• A full cycle is therefore just under two real hours, of which players spend about 20 minutes in the dark.

The general form: real minutes per cycle = (daylight hours × 60 ÷ acceleration) + (night hours × 60 ÷ (acceleration × night acceleration)). Written into the file, that example is:

serverTime = "SystemTime";
serverTimeAcceleration = 8;
serverNightTimeAcceleration = 4;
serverTimePersistent = 1;

Server Time Persistent matters more than it looks. With it off, every restart re-reads Server Time, so a server pinned to a literal timestamp lands on the same hour forever. With it on, the clock carries across restarts and keeps moving through the week.

4. Gameplay restrictions

Every field in this group is a checkbox that writes 0 or 1. Read the labels carefully: most of them are phrased as disable, so ticking the box removes the feature rather than adding it.

Building a first-person server? Tick Disable 3rd Person and Disable Crosshair together and say so in Host Name — players searching for first person read the browser text, they do not filter on the key.

5. Admin logging: what lands in the ADM log

These four checkboxes control how much detail the engine writes to its admin log. The panel always launches your server with -adminlog and a profiles directory, so the .ADM file always exists — you can read it live from the Live Logs card on Overview by setting the Stream dropdown to adm, or open it in the profiles share.

Turn all four on. The log is the only record of what happened once players have logged off, and it cannot be reconstructed retroactively — a setting you left off yesterday tells you nothing about yesterday.

6. Networking, view distance and object streaming

Everything in this group trades server CPU and bandwidth for what players can see and how quickly the world appears around them. The defaults are Bohemia’s and they are well chosen; change them one at a time and watch Server FPS on Overview afterwards.

Heavily modded servers are usually better served by leaving these alone and managing mod load order instead. Loot volume belongs in types.xml and the loot economy, not here.

7. Enable CfgGameplay File, and changing the map

Two controls reach outside serverDZ.cfg, so they behave a little differently.

Enable CfgGameplay File is the last checkbox in the grid and writes enableCfgGameplayFile = 1;. With it on, the engine also reads gameplay values from cfggameplay.json inside your mission folder — things serverDZ.cfg cannot express, such as stamina and base-building rules. The panel neither edits nor validates that file, so check it exists in File Browser → mpmissions → your mission before ticking the box, and read the rpt stream on the next start. It is JSON: one stray comma is enough to break it.

Edit Mission sits under the field grid and is how you change map. Pick from the Preset dropdown or type into the Value box:

Then click Save mission. Clear only empties the box on screen; you still have to save, and a blank value resolves back to dayzOffline.chernarusplus. Both buttons are disabled while the server is running, and this one save is governed by the Change mission permission rather than Edit settings.

8. Save, start and check your work

Click Save at the bottom of the dialog. You want Changes Saved! in a green banner. Anything else is telling you something:

• No changes required. — the editor compared your fields against what it loaded and found nothing different.
• Stop the instance to change settings. — the instance is not stopped.
• A red message naming one field, such as 'hostName' too long (max 96). — fix that field and save again. Nothing was written.

Edit Mission and Server & RCON Authentication have their own buttons and save independently of the main Save, so if you changed the map or the password, make sure you pressed Save mission or Save password too. Close the dialog with Cancel, the Close icon in its top corner, or the Escape key.

Now go back to Overview and click Start. Watch the Live Logs card with Stream on rpt through the first boot — a bad value that the panel accepted will show up there rather than in the panel. Once it is up, your changes are live: check the day length against the clock, or open config/serverDZ.cfg in File Browser and read the keys back.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• Editing types.xml safely
• installing Steam Workshop mods

You install Steam Workshop mods on a DZSERVERS.HOST server from the Workshop Mods tab: paste the mod’s Workshop URL or numeric id, click Lookup & add, accept its required dependencies, then restart. The panel builds the -mod= and -servermod= launch arguments from that list on every start, in the order the rows appear — so the order in that table is what decides whether a modded server boots.

This guide covers the tab end to end: dependencies, load order, server-only mods, auto-update, Verify Files and safe removal. New here? Start with getting started with the control panel.

Before you start

• An instance you can manage mods on. The tab is permission-gated; without it the page tells you to ask the owner for the Manage Mods permission.
• The Workshop page or numeric id of each mod. Browse Workshop on the tab opens the DayZ Workshop in a new tab.
• A current backup if players are already on the server — mod changes can invalidate stored objects. See automatic backups and restore.
• Ideally a stopped server. You can add mods while it runs, but the install waits for the next restart and reinstall, update, verify and remove are all disabled.

1. Look the mod up on the Workshop Mods tab

Go to Instances → your instance → Workshop Mods. The Add a mod card takes either identifier: the numeric id on its own, such as 1559212036, or the full address, https://steamcommunity.com/sharedfiles/filedetails/?id=1559212036.

Paste one into the Steam Workshop URL or numeric ID box and click Lookup & add. The panel fetches the item’s title, size, last-updated date and declared dependencies from Steam and opens the Add Workshop Mod panel. Nothing has been added yet — this is a preview.

2. Choose how the mod loads

The Add Workshop Mod panel shows the thumbnail, title, Last updated date and Size, and flags two things worth stopping for: a banned Workshop item, and a mod already in this server’s list. Then three decisions:

1. Load as server-only mod (uses -ServerMod=) — passes the mod in -servermod= instead of -mod=, so players do not need it to join. Leave it off unless the mod’s description says it runs server-side only.
2. Install immediately after adding — on by default. While the server is running the same checkbox reads Download now, install on next restart: the download starts against the node’s Workshop cache at once, and the mod is copied into your instance automatically at the next start.
3. Auto-update this mod when new versions are published — the panel watches Steam and applies new versions unattended. If the server is up it broadcasts a short warning, stops, updates and starts again, recording each step in the Audit Log.

Then click Add to server.

3. Accept the required dependencies

If the mod declares required items, a Required dependencies card lists each with a pre-ticked checkbox. Anything already in your list is greyed out and marked (already added).

Leave them ticked. Checked dependencies are added and installed before the main mod — the panel puts their rows ahead of the parent in load order and queues their downloads first, so the files DayZ needs exist before the mod that reads them is parsed. Getting this wrong is the most common reason a modded DayZ server will not boot, and it is handled for you.

If the mod declares nothing, the panel says so. That is not a guarantee: plenty of authors document dependencies in prose and never declare them, so read the Workshop description before assuming a mod stands alone.

4. Read the mod table while it installs

Rows with queued work grow a progress strip and refresh themselves when the command finishes; Refresh in the header is there if you want it sooner. The table has eight columns:

• NotInstalled — in your list, nothing on disk. Queued then Installing — the agent is working on it.
• Installed — on disk and current. Update available — the author published a newer version.
• Installs on restart — added while the server ran; downloaded and waiting for the next start.
• Removing — a removal is in flight. Failed — the last install did not complete, with the reason under the mod name.

5. Set the load order, then save your row changes

DayZ reads its mod list left to right and resolves each mod against what is already loaded. Anything a later mod builds on — a framework, a shared library, a base mod whose classes get extended — must appear earlier. The same rule settles conflicts: when two mods define the same thing, the one loaded later wins.

So: frameworks and dependencies first, content mods next, override or tweak mods last. Use the arrows in the Order column to move a row. Reordering is written immediately, with no save step, and takes effect at the next start. Your list becomes launch arguments shaped like this:

"-mod=@Dependency;@BigContentMod;@TweaksThatOverrideIt" "-servermod=@AdminToolsServerSide"

The three checkbox columns behave differently. Enabled, Server-only and Auto-update are drafts: clicking one outlines the box and adds the row to a banner counting your unsaved rows. Nothing reaches the server until you click Save on that row. Reset discards one row, Discard all discards every pending change. Saved toggles apply at the next launch and can be saved even while the server is running.

6. Restart, then publish your mod list

Nothing on this tab is live until the server relaunches, because the list only becomes command-line arguments at start. Use Start on Overview, or Controlled Restart if players are on, and watch the Live Logs card on the rpt stream. A first boot with new mods is slower than usual.

Then deal with the client side, because this is where the complaints come from: every mod not marked server-only must be installed on each player’s PC too, or they cannot join.

• Build a Steam Workshop collection with exactly your client-side mods and pin it in your Discord and server description.
• Share the List on DZSA Launcher link from Overview — launcher users are least likely to get this wrong.
• Announce every client-side mod you add or remove. Players joining with a stale mod set get bounced and will blame the server.

Mod settings live in the mod’s own config files, usually under profiles — the Settings editor still governs vanilla options only. See every serverDZ.cfg setting explained.

7. Keep mods up to date

The panel polls Steam for new versions. When it finds one, the pill turns to Update available, the Mod cell shows the newer publish date in amber, and the row’s button changes from Reinstall to Update.

• Sync all updates in the header queues every out-of-date enabled mod at once; the number in brackets is how many it will touch.
• Update on a row does that one only.
• Auto-update on a row means you do nothing: the panel warns players, stops, updates and starts the server itself, and logs each step in the Audit Log.
• Verify Files is the repair tool — it discards the cached copy, re-downloads from Steam and prunes files the item no longer ships, so disk matches the Workshop exactly. Use it when a mod is installed but misbehaving.

8. Remove a mod safely

Stop the server, then click Remove on the row. The Remove mod dialog offers Also delete the mod files from this instance's directory, ticked by default; clearing it drops the row but leaves the files. If other mods declare this one as a dependency, the dialog becomes Other mods depend on this one, names them, and makes you choose Remove anyway deliberately.

The reverse holds too: adding a large content or map mod to a server that already has bases can change which stored objects are valid. Schedule that kind of change for a quiet hour with a fresh backup.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• every serverDZ.cfg setting explained
• Automatic backups and restore

Everything that decides what spawns on your DayZ server lives in the mission’s XML files, and you edit them from the File Browser tab: set the Share dropdown to mpmissions, open your mission folder, then db, and click View/Edit on types.xml. The editor checks your XML as you type and refuses to save a file with a syntax error, which is the main thing standing between a small loot tweak and a server that boots with no loot at all.

This guide takes the safe route: keep a copy, understand what each attribute actually does, save clean, then restart to apply. Budget twenty minutes for your first edit.

Before you start

• An instance you can restart. The central economy is read once when the mission loads, so nothing you save takes effect until then.
• Read files and Write files permission on the instance. Owners have both; sub-users need them granted under Members.
• Somewhere to keep a copy of the file before you change it — your own disk is fine.
• A rough idea of which item you are changing. Class names in types.xml are exact and case-sensitive.

1. Keep a copy before you change anything

The editor writes straight over the file. There is no version history, no diff, and the moment you click Save the modal closes and the editor’s Ctrl + Z history goes with it.

Pick whichever of these fits the size of the job:

• One file. Click Download on the types.xml row before you open it. That gives you the exact bytes you started from, and you can paste them back into the editor if you need to.
• The whole mission. Pull mpmissions down over SFTP — see taking your own backup over SFTP. This is what you want if you are about to work through several economy files.
• Rely on the automatic backups. Mission XML is captured in the XMLs & JSONs & other(s) category and kept for 30 days. It works, but a restore rolls the whole category back and the server has to be stopped for it — see automatic backups and restore.

A downloaded copy costs you one click. Take it.

2. Open the File Browser on the mpmissions share

Go to Instances → your server → File Browser. The page opens on the profiles share, which is not where you want to be.

Use the Share dropdown at the top right and choose mpmissions. The badge under it changes to Share: mpmissions and the breadcrumb resets to (root). Switching shares always returns you to that share’s root, so you never end up looking at a path that belongs to a different share.

Four shares are exposed, and each one holds something different:

Worth expanding once: the File Browser Help & Tips card at the top of the page lists every action the browser supports, including drag-to-move and folder uploads.

3. Find the right mission folder, then open db

The mpmissions root holds one folder per mission, and a stock instance usually ships with more than one. Only the folder named on the Overview tab’s Mission pill is actually loaded — typically dayzOffline.chernarusplus.

Click into the mission folder. What you are looking at:

Open db. The economy files are all there, all small, and all editable in the panel.

4. Open types.xml in the editor

Find the types.xml row and click View/Edit. A modal opens, titled Edit: followed by the file’s path inside the share, with a real code editor in it: line numbers, code folding, syntax colouring and a lint gutter down the left.

Two things about the editor that save time:

• types.xml is long — several thousand lines on a vanilla mission. Do not scroll. Press Ctrl + F, type the class name, and press Enter to jump straight to it.
• The Editor Shortcuts card sits under the editor, collapsed. Click Expand once and you have the full keymap: Ctrl + H for find and replace, Ctrl + Alt + G to jump to a line number, Alt + Up and Alt + Down to move a line, Ctrl + Z to undo.

The status bar under the editor shows Ln 1, Col 1 and a character count, then the validation pill on the right. When the file parses, the pill reads XML: valid in green. A JSON file such as cfggameplay.json gets exactly the same treatment and reads JSON: valid.

5. Read the entry before you change it

Each item is one <type> block. Here is a rifle entry, and every number in it is doing a specific job:

<type name="AKM">
    <nominal>15</nominal>
    <lifetime>7200</lifetime>
    <restock>0</restock>
    <min>10</min>
    <quantmin>-1</quantmin>
    <quantmax>-1</quantmax>
    <cost>100</cost>
    <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="0" deloot="0"/>
    <category name="weapons"/>
    <usage name="Military"/>
</type>

The flags block is the part people miss. Each count_in_* flag decides whether copies in that place count towards nominal. In the entry above only count_in_map is set, so the economy counts AKMs lying in the world — and ignores every AKM in a player’s hands, backpack, tent or stash. That is why a heavily looted server keeps producing rifles: the hoarded ones are invisible to the count.

• count_in_cargo — count copies inside containers and bags on the ground.
• count_in_hoarder — count copies stashed in tents, barrels and other hoarder storage.
• count_in_map — count copies lying loose in the world. Set on virtually everything.
• count_in_player — count copies in players’ inventories.
• crafted — the item only exists through crafting, so the economy never spawns it.
• deloot — the item comes from dynamic events only, not from ordinary loot points.

Turning count_in_hoarder and count_in_player on for high-value gear is the standard way to stop a server drowning in hoarded rifles. It is also the change most likely to surprise you, so make it on one or two types first and watch what happens over a couple of days.

6. Let the validator clear you before you save

As you type, the editor parses the file. Two things react:

1. The lint gutter on the left marks the line the parser choked on, and the offending text is underlined in the body.
2. The status pill flips from XML: valid to XML: 1 error, and a red bar appears above the buttons naming the problem, for example Cannot save: this XML file has a syntax error followed by the parser’s own message. XML parsers stop at the first fault they hit, so fix that one and the next hidden one appears.

While the pill is red, Save is disabled. That is deliberate.

Format at the bottom right re-indents the whole file at two spaces per level, which makes an unbalanced block obvious at a glance. It only works on a file that already parses, so treat it as a tidy-up rather than a repair tool — on a broken file it just tells you it cannot format.

When the file is broken, a Save anyway (ignore format errors) checkbox appears next to the buttons and ticking it re-enables Save.

Once the pill is green, click Save. A Saved. toast confirms it and the modal closes.

7. Restart to apply, then confirm the economy loaded

The central economy is read once, while the mission loads. Saving types.xml on a running server changes nothing that players can see, and a running server will happily keep going for days on the old numbers.

Back on Overview:

1. Nobody online? Restart is fine.
2. Players on? Use Controlled Restart and pick 5, 10 or 15 minutes so they are warned and can log out somewhere safe. See restarting without rollbacks.

When the status pill returns to Running, open the Live Logs card, set Stream to rpt and read the first part of the boot. Economy complaints are logged there, and an unknown class name or a bad usage value shows up as a named error you can search for. A clean boot ends with the mission loaded and no economy errors.

Then check it in game. If you raised nominal, give the economy a few minutes — it feeds items in gradually rather than dumping them the instant the server starts.

8. Know when to stop using the browser and use SFTP

The web File Browser is the right tool for one file at a time. Past that it starts to fight you.

SFTP runs on port 2022 with a username derived from your panel account and a separate SFTP password, and it exposes the same four shares. Full setup is in connecting to your server with SFTP.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• connecting with SFTP
• Automatic backups and restore

Everything you need to connect to your DayZ server over SFTP sits on one page: open your instance, click the SFTP tab, and the Connection card gives you the Host, the Port (2022) and your Username, each with a Copy button. The Password card below holds a dedicated SFTP password, separate from your panel login.

This guide sets up WinSCP and FileZilla step by step, explains the unusual username format, and covers the two mistakes that cost real time: editing files while the server runs, and regenerating the password without updating saved sessions.

Before you start

• A provisioned instance and a panel account with the Allow SFTP access permission on it. Instance owners have it automatically.
• An SFTP client. This guide uses WinSCP and FileZilla, both free on Windows.
• Outbound TCP on port 2022 allowed by your own network — some corporate and school networks permit only 80 and 443.

1. Open the SFTP tab and read the Connection card

Go to Instances → your instance → SFTP. The header reads SFTP Access followed by your instance name, and the Connection card lists three values, each with its own Copy button:

• Host — the machine your instance runs on. Depending on the node this is either a hostname or the same IP you connect to in game.
• Port — 2022, not the usual 22. Leave your client on the default and it will fail to connect.
• Username — your panel username, a dot, and eight hexadecimal characters, for example yourname.4f2a91c0.

That trailing block is the first eight characters of the instance’s internal id, and it is how the SFTP server knows which instance you want. One account with three servers therefore has three different SFTP usernames. Copy it verbatim — a login built from your panel username alone is rejected.

2. Generate or copy your SFTP password

Scroll to the Password card. Its badge reads Set or Not set, and the subtitle gives the date it was last set. The first time you open this tab with no password on file, the panel generates one immediately and confirms with SFTP password generated. — so usually there is nothing to do but reveal it.

Use Show to unmask the value and Copy to take it, then store it in your password manager. For a fresh one, click Regenerate password.

Two other states exist. Not set with an empty field means none exists yet — click Generate password. The message This password was set before it could be shown here. Generate a new one to view and copy it. means yours predates the panel storing a displayable copy: it still works if you know it, but cannot be shown.

3. Connect with WinSCP

WinSCP opens its Login dialog on launch; if it does not, use Session then New Session. Fill in four fields:

Click Save if you want the session kept, then Login. The first connection asks you to accept the server’s host key fingerprint — normal, and once per machine. You then land in a directory holding your four folders.

4. Connect with FileZilla

FileZilla’s Quickconnect bar defaults to plain FTP, which will not work here, so use the Site Manager:

1. Open File → Site Manager and click New site. Name it after your instance.
2. Set Protocol to SFTP - SSH File Transfer Protocol.
3. Paste the panel’s Host into Host, and 2022 into Port.
4. Set Logon Type to Normal, then paste the full Username into User and your SFTP password into Password.
5. Click Connect and accept the host key when prompted.

To avoid storing the password, choose Ask for password as the logon type instead.

5. Find your way around the four folders

SFTP shows the same four shares as the panel’s File Browser, and nothing else:

• profiles — server logs (.ADM, .RPT, script_*.log) and profile data: full log history, rather than the live tail.
• mpmissions — the mission folder, holding both your economy XMLs and your persistence.
• config — serverDZ.cfg, the BattlEye keys directory, and the whitelist.txt, ban.txt and priority.txt lists.
• mods — installed Workshop mods.

Persistence lives at mpmissions/<world>/storage_*/. players.db (with its -wal and -shm companions) holds every character and inventory; the rest of the folder holds built structures, vehicles and other world state. Pull these down before anything risky — see taking a manual backup over SFTP.

Loot and economy editing happens one level up, in mpmissions/<world>/: types.xml, events.xml, cfgspawnabletypes.xml. There is no GUI for these, so SFTP plus a text editor is the workflow — editing types.xml and the loot economy covers them.

6. Upload and download without breaking anything

SFTP exists mainly to lift the size ceiling: the web File Browser accepts uploads up to 300 MB, SFTP up to 2.5 GB.

The same logic applies more gently to configuration: serverDZ.cfg and the economy XMLs are read once at boot, so a mid-session edit does nothing until the next start.

Two structural limits round it off. Renaming is blocked in config and mods, which hold template-managed files, so upload under the final name instead. And serverDZ.cfg, the keys directory, whitelist.txt, ban.txt, priority.txt and the top-level mod folders cannot be deleted at all — overwrite those.

7. Give staff SFTP access without sharing your password

Because the password is tied to a panel account, handing yours to a helper gives them your whole account. Add them under Members instead and let them generate their own.

Two layers apply. Allow SFTP access decides whether they can log in; the Files permissions decide what they can do once in. Read files is the floor — SFTP access without it is refused at login — while Write files adds upload, overwrite and folder creation, and Delete files adds deletion. The rights match the File Browser exactly, so SFTP is not a back door.

A member without access sees You don't have SFTP access to this instance. Ask the instance owner to grant it from the Members page. Successful logins are recorded in the Audit Log under the SFTP category with the account and the file rights it was granted; client IP addresses are deliberately kept out.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• Making a manual backup over SFTP
• Editing types.xml safely

Backups on your DZSERVERS.HOST server run automatically on a frequency you choose, are kept for 30 days, and restore one category at a time — so you can roll back a griefed base without resetting a single player’s character, or put back only your economy XMLs after a bad edit. Everything lives on the Backups tab of your instance: a Backup schedule card, a Backup history list, and a restore panel where you tick which parts of which world to put back.

This guide covers that automatic side. There is no create-now button and no download button on the tab, which is deliberate: a copy on your own disk is a separate job over SFTP.

Before you start

• An instance and the Manage backups permission. The Backups tab only appears in the tab bar if you have it.
• The Start / stop / restart permission too if you intend to restore — a restore needs the server stopped, and both the panel and the node refuse otherwise.
• A rough idea of when the problem started, so you pick the right entry. History timestamps are shown in your own local time.

1. Open the Backups tab

Go to Instances → your instance → Backups. The page opens with two cards, Backup schedule and Backup history. Refresh re-reads both; Back to Instance returns you to Overview.

A message reading You don't have permission to manage backups on this instance. means you are a sub-user without the Manage backups permission, which the owner grants under Members.

2. Choose a backup frequency

The Backup schedule card holds one dropdown. Pick a value and click Save; a toast confirms it, such as Backup frequency set to Daily. Discard appears beside Save while a change is unsaved.

The interval runs from the last backup attempt, not against the clock, so Daily means about every 24 hours and drifts slightly forward each day; there is no field to pin it to a set hour. Backups need no downtime either: the node takes a Volume Shadow Copy snapshot first, so players.db is captured cleanly while DayZ holds it open and players are online.

3. Know what is in a backup, and what is not

A backup captures your mission folder under mpmissions — persistence and mission config — split into three independently restorable categories:

• Players DB — player characters and inventory: players.db plus players.db-wal and players.db-shm.
• World Data — built structures, vehicles and other persisted world state. Everything else in the storage_* folder.
• XMLs & JSONs & other(s) — mission-level config: types.xml, events, spawn configs and the rest of the mission folder outside storage_*.

mpmissions/
  dayzOffline.chernarusplus/       one "world" in the restore tree
    db/                            XMLs & JSONs & other(s)
    cfgeconomycore.xml             XMLs & JSONs & other(s)
    cfgspawnabletypes.xml          XMLs & JSONs & other(s)
    storage_1/
      players.db                   Players DB
      players.db-wal               Players DB
      players.db-shm               Players DB
      data/                        World Data

Every mission folder under mpmissions is captured separately, so if you have switched maps you will see more than one world in the restore tree.

4. Read the backup history

Backup history lists entries newest first. On a new instance it reads No backups yet. They'll appear here once the schedule runs.; the first arrives after one interval has elapsed.

Each row shows a status pill, the creation time in your local timezone, the compressed size, and whether it was Scheduled or Manual. Everything the schedule produces is Scheduled; Manual only appears on an entry created from our side, for instance while a support ticket is being worked.

Restore opens the restore panel — greyed out unless the entry is Available and the server is stopped, and hovering it names the blocking condition. Delete removes the backup file from the node. Entries are deleted automatically 30 days after creation, so Every 6 hours carries roughly 120 restore points and Weekly roughly four.

5. Stop the server before you restore

While the instance is up, Backup history shows a banner reading The server is running. Stop it before restoring a backup. and every Restore button is disabled with the tooltip Stop the server first.

That is not a formality. A running DayZ server holds players.db open and flushes persistence as it goes and again on shutdown, so restoring underneath it either fails on a locked file or gets overwritten the moment the server next saves — burning the outage without fixing anything. The panel and the node both refuse outright.

Click Stop on Overview. If players are online, use Controlled Restart first so they are warned and can log out somewhere safe — restarting without rollbacks explains what an abrupt kill costs them. Back on Backups, the banner clears a few seconds after the instance reports Stopped.

6. Restore only the parts you need

Click Restore on the entry you want. A panel headed Restore backup opens, subtitled with that backup’s timestamp, and states plainly: Choose which parts to restore. Existing files will be overwritten.

Below is a checkbox tree, one group per world. The group header is the mission folder name — dayzOffline.chernarusplus — with (Persistence) beside it, and ticking it toggles all of its categories. Each category shows its size and file count, so you can see that Players DB is a few megabytes while World Data may be hundreds.

That separation is the whole point:

• A group blew up someone’s base overnight. Tick World Data only: structures and vehicles go back to last night, and everyone keeps the character and gear they have now.
• A bad types.xml edit broke your economy. Tick XMLs & JSONs & other(s) only: loot config reverts, no base or character is touched. Editing types.xml and the loot economy covers avoiding the next one.

The confirm button counts your ticks — Restore 1 part for one category, Restore 3 parts for three — and stays disabled until a box is checked. Cancel changes nothing.

7. Watch it finish, then start the server

Confirming queues the work on the node. The pill switches to Restoring and a progress strip appears under that row, polled every second or two until it settles on Done or Failed; Dismiss clears it. The backup file is never modified, so the row returns to Available either way — and if it failed, the reason is appended after the size. Read that before retrying.

Now click Start on Overview and verify before announcing you are back: Server Status reads Running, Server FPS reports a number, and the thing you restored looks right in game. If you restored Players DB, tell players first — a silent character rollback reads as a bug.

8. Keep your own copy for anything older than 30 days

This tab is 30 days of node-side history, not an archive, and its entries are only ever restored in place. Two situations need more:

• A copy off the node. Pull mpmissions/<world>/storage_* down over SFTP. That is the whole persistence set, and it is yours to keep — see making and downloading a manual backup over SFTP.
• Something risky right now — an economy rewrite, a mod that touches persistence, a map change. Do not wait for the schedule: stop the server, copy the mission folder down, then make the change. Connecting with SFTP covers credentials and clients.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• Making a manual backup over SFTP
• Restarting without rollbacks

A manual DayZ backup is a copy of your mission folder pulled down over SFTP with the instance stopped: open the SFTP tab for the credentials, connect on port 2022, then download mpmissions/<world>/ including the whole storage_* folder and all three of players.db, players.db-wal and players.db-shm. That is the entire persistence set, and once it is on your own disk it is yours indefinitely.

The Backups tab cannot do this for you. It has no create-now button and no download button, and its history is only 30 days, so an off-site archive, a snapshot taken minutes before a risky change, or a copy to load onto a test server is a job you do by hand. This guide covers doing it correctly — and the one mistake that turns the whole exercise into a corrupt file.

Before you start

• Your SFTP details: the Host, Port (2022) and Username from the SFTP tab, plus your SFTP password. Connecting with SFTP covers getting them and setting up a client.
• The Start / stop / restart permission as well as Read files. A copy taken while the server is running is not a backup, so you need to be able to stop it.
• A maintenance window. The instance stays down for the length of the copy — usually a few minutes, longer on a mature world.
• Free disk space locally, and somewhere sensible to keep the copy. A mature storage_1 folder is commonly a few hundred megabytes.

1. Stop the instance before you copy anything

This is the whole guide in one instruction. Do it first, and everything else is straightforward.

Click Stop on Overview. If players are online, run a Controlled Restart first so they are warned and can log out somewhere safe, then stop the instance once it is back up — restarting without rollbacks explains what an abrupt kill costs them.

Wait for the status pill. DayZ flushes persistence as it shuts down, so a copy started while the process is still exiting can catch the world mid-write. Stopped means the handles are closed and the files on disk are the truth.

2. Connect over SFTP and find your world folder

Go to Instances → your instance → SFTP and take the Host, Port and Username from the Connection card — each has its own Copy button. The username is your panel username, a dot, and eight hexadecimal characters identifying this instance, so copy it verbatim rather than retyping it.

Your session lands in a root holding exactly four folders: profiles, mpmissions, config and mods. Open mpmissions.

Inside is one folder per mission world. The one you want is the value shown as Mission on Overview — dayzOffline.chernarusplus on a default Chernarus instance. If you have ever switched maps you will see more than one, and only the current mission is live; the others are old worlds sitting dormant.

Open your world folder and you will find the mission configuration alongside a storage_* folder, normally storage_1. That storage folder is your persistence.

3. Download the whole world folder

You can cherry-pick, but the reliable move is to drag the entire world folder to your local machine in one transfer. That captures all three of the things a restore might need, in the same layout the server expects them back in:

Laid out on disk it looks like this:

mpmissions/
  dayzOffline.chernarusplus/       download this whole folder
    db/                            types.xml, events.xml, globals.xml
    cfgeconomycore.xml
    cfgspawnabletypes.xml
    storage_1/
      players.db                   characters and inventory
      players.db-wal               writes not yet folded into players.db
      players.db-shm
      data/                        bases, vehicles, tents, stashes

Drop it into a local folder named for the instance and the moment you took it — myserver-chernarus-2026-07-30-0300 — and leave the structure exactly as it came down. Do not rename anything, and do not delete the -shm file because it looks like scratch data. A copy that mirrors the server is one you can put back with a plain overwrite.

4. Take serverDZ.cfg and a record of your mod list too

Persistence is the part you cannot recreate, but two more things are worth five seconds each while you are connected.

serverDZ.cfg. It lives in the config share. The panel writes this file for you from the typed Instance Settings editor, so it is reproducible — but a copy is a plain-text record of every value you tuned, and it is the first thing another host or a local test server will want. Grab whitelist.txt, ban.txt and priority.txt alongside it if you use them. All of these are protected files: you can download and overwrite them, but not delete or rename them over SFTP.

Your mod list. There is no export button, so make your own record. The Workshop Mods tab shows an Order column and each mod’s numeric Workshop ID — a screenshot of that table does the job, and the mods share gives you the same list as one @ModName folder per installed mod.

5. Verify the copy before you start the server again

The instance is still stopped, which means this is the only moment you can re-take a bad copy for free. Spend a minute on it.

1. Compare counts and sizes. Put the remote and local panes side by side on the same folder; the file count and total size should match. Most clients flag a transfer that finished with skipped files — treat any skip as a failed backup, not a warning.
2. Confirm all three database files. players.db, players.db-wal and players.db-shm must be present locally if they are present on the server. After a clean shutdown the -wal may be zero bytes or absent, which is fine — what is not fine is it existing on the server and not in your copy.
3. Check the storage folder is not empty. storage_1/data should hold real files. An empty storage folder means you copied a shell.
4. Open one of the XMLs. db/types.xml in a text editor proves the text files came down intact rather than truncated.
5. If you zip it, open the zip. Confirm the archive lists the storage_1 folder and the database files. An archive nobody has opened is not a backup.

Once you are satisfied, click Start on Overview and confirm Server Status reads Running and Server FPS reports a number before you tell anyone the server is back.

6. Decide how many copies you keep, and for how long

The Backups tab is your short window — 30 days of node-side history, restored in place. Your own copies are the long window, and they only help if taking them is a habit.

• A rolling set. Three recent copies suits most communities. Take one, delete the oldest, keep moving.
• One before every risky change. An economy rewrite, a mod that writes to persistence, a map change, a version upgrade. Take it minutes before, not last night — the value is that it predates the change by as little as possible.
• One a month, kept. The copy that outlives the 30-day retention, and the one you will be glad of when something went wrong six weeks ago and nobody noticed.
• One before you leave. Moving hosts means taking a full copy while you still have SFTP access — see migrating a DayZ server to a new host.

Store them in two places, one of which is not your gaming PC, and label each copy with the date, the world and the mod set. Sizes are modest — even a large world is usually a few hundred megabytes zipped — so a year of monthly archives fits on any cloud drive.

7. Put your own copy back when you need it

Restoring your copy is the download in reverse, with the same rule at the front of it.

1. Stop the instance on Overview and wait for Server Status to read Stopped.
2. Connect over SFTP and navigate to mpmissions/<world>/ — the same world folder you took the copy from.
3. Upload your saved folder over the top, letting your client overwrite. Take players.db, players.db-wal and players.db-shm together, from the same copy, in the same transfer.
4. Click Start and check the thing you restored actually looks right in game before you announce that you are back.

Two limits shape the upload. SFTP takes single files up to 2.5 GB; the web File Browser stops at 300 MB, and a mature storage folder routinely exceeds that, so the browser uploader will reject exactly the files you most need to put back. And nothing on the server unpacks archives — there is no extract feature in the File Browser or over SFTP — so upload the unzipped folder tree, not the zip.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• Automatic backups and restore
• connecting with SFTP

You can move a DayZ server from another host to DZSERVERS.HOST and keep your world, your players’ bases and their characters. What carries all of that is one directory: your mission folder, with its storage_* persistence inside it. The order of work is: set the matching mission under Settings → Edit Mission, rebuild the mod list in the same load order under Workshop Mods, re-enter your serverDZ.cfg values in Instance Settings, then upload the mission over SFTP while the new instance is Stopped.

Some things do not come with you, and it is cheaper to know that now than to discover it mid-cutover: bans, whitelist and priority queue have to be re-imported, your admin and RCON password is replaced, and mods run at whatever version the Steam Workshop publishes today. This runbook covers both halves.

Before you start

• File access to the old server that you still control — its panel, FTP or SFTP. Get your copy before you cancel anything; plenty of hosts delete the files the moment a service lapses.
• A provisioned instance here. It is created automatically when your order completes, so there is nothing to build — see getting started with the control panel.
• Your SFTP details from the SFTP tab: host, port 2022, the per-instance username and the SFTP password. Connecting with SFTP sets that up.
• The same map on both ends. Bases and characters are stored per world, so moving from Chernarus to Livonia is a fresh start, not a migration.
• Somewhere with room to hold the download. A long-lived server’s persistence is commonly hundreds of megabytes.

1. Inventory the old server while you still have access

Write five things down first. Every later step depends on one of them, and once the old service is gone none of them can be recovered.

1. The mission folder name, exactly. Something like dayzOffline.chernarusplus. Copy the spelling and capitalisation from the folder listing, not from memory.
2. The mod list, in load order. The authoritative source is the old host’s startup line: the -mod= and -servermod= arguments, read left to right. Note each mod’s numeric Steam Workshop id, because folder names are not always unique or searchable.
3. The slot count the old server ran, so you can tell whether your new plan matches.
4. A copy of serverDZ.cfg. You will not upload this file, but you will read values out of it in step 5.
5. The list files from the old server root: ban.txt, whitelist.txt and priority.txt, if you used them.

2. Stop both servers, then download the mission folder

Stop the old server first. Then download, from the old host, the entire mission folder — not a selection of files inside it.

This is what you are after, and roughly what it looks like:

mpmissions/
  dayzOffline.chernarusplus/      <- take this whole folder
    db/                           globals.xml, economy.xml, types.xml, events.xml
    cfgeconomycore.xml
    cfgspawnabletypes.xml
    cfgplayerspawnpoints.xml
    cfggameplay.json
    init.c
    storage_1/                    <- the persistence: bases, vehicles, characters
      players.db
      players.db-wal
      players.db-shm
      data/

Two files are easy to miss and matter: players.db-wal and players.db-shm are the write-ahead log and shared-memory index for players.db. Take the database without them and you can lose the most recent writes — which is to say, the last session everybody played.

3. Point the new instance at the same mission

With the instance stopped, click Settings in the tab bar and scroll to Edit Mission. The Preset dropdown offers the three stock missions:

Picking a preset just fills the Value box, and that box is free text. So if your old host ran a custom or renamed mission, type its exact folder name in Value instead of using a preset. Click Save mission. Clear empties the field and falls back to dayzOffline.chernarusplus.

4. Rebuild the mod list in the same load order

Open Workshop Mods. In the Add a mod card, paste a Workshop URL or its numeric id and click Lookup & add. The Add Workshop Mod panel opens, lists any Required dependencies pre-ticked, and Add to server queues the mod and its dependencies ahead of it. Repeat for every mod on your inventory list.

Then fix the order. The arrows in the Order column set the sequence, lowest first, and it must match what the old server ran: frameworks and dependencies first, content mods next, override and tweak mods last. Reordering saves immediately. The Enabled, Server-only and Auto-update checkboxes are drafts instead — click Save on the row to commit them. Installing Steam Workshop mods covers it in detail.

5. Re-enter your serverDZ.cfg values by hand

Open Settings again and work down the Instance Settings fields with the old serverDZ.cfg beside you: Host Name, Description, Max Players, Password, the time acceleration values, Disable 3rd Person, the Admin Log toggles, the network ranges. Every field maps to one real config key. Every serverDZ.cfg setting explained is the reference if a value needs interpreting. Click Save and look for Changes Saved!.

These lines belong to the panel and are rewritten on every single start, whatever the file says:

hostIp         = "...";     // your instance's bind IP
hostPort       = ...;       // your game port
a2sport        = ...;       // your query port
a2sIpAddress   = "127.0.0.1";
steamQueryPort = ...;       // your query port
maxPlayers     = ...;       // clamped to the slot count you purchased
passwordAdmin  = "...";     // from Settings > Server & RCON Authentication

Anything the editor does not cover is yours to edit directly. Keys such as instanceId, the VoN settings, the login queue values and respawnTime are left untouched by the panel, so set them in serverDZ.cfg from the File Browser (Share → config) and they will stick.

Last, set your admin password. In Server & RCON Authentication, type a value or click Regenerate, then Save password — 4 to 10 characters, letters and digits only. The old host’s password does not come across, and this one value covers both the in-game admin login and BattlEye RCON, so update any external admin tool you use.

6. Upload the mission and persistence over SFTP

Confirm Server Status still reads Stopped, then connect with your SFTP client and open the mpmissions folder.

Use SFTP, not the web File Browser, for this step: the browser caps uploads at 300 MB against 2.5 GB over SFTP, and storage_* alone usually exceeds 300 MB on any server that has been played on. Create the mission folder under its final name and upload into it, rather than uploading and renaming afterwards.

Then reconcile the storage folder number. DayZ picks which one it loads from instanceId in serverDZ.cfg: instanceId = 1 loads storage_1. If the old host used a different value your download arrives named storage_5 or similar, and the new server will ignore it and generate an empty world beside it. Either name the incoming folder to match the storage_* folder your instance already has, or set instanceId to the old number.

7. Boot it once and read the RPT before telling anyone

Click Start on Overview. The first boot after a migration is slower than normal: mods install, and the engine reads a persistence set it has never seen. Open the Live Logs card, set Stream to rpt and actually read it. What you are checking for:

• The mission loads. A run that ends without reaching the mission usually means the Mission value and the folder name disagree.
• No mod load failures. Cross-check any complaint against the Workshop Mods table for a Failed status or a Missing dependencies card.
• No flood of unknown-type errors. Those are types.xml entries naming items from a mod that is not in your list — a sign the mod list is incomplete rather than that the XML is broken. Editing types.xml and the loot economy explains the file.

You are up when Server Status reads Running and Server FPS reports a number. Now verify in game rather than by inspection: copy your address with Copy next to Connect, join, and check three things — your own character arrived with its inventory, a base you know the location of is standing, and vehicles are where they were. Open the Live Map tab and confirm you show up on it.

8. Re-import your lists, rebuild your schedule, then cut over

Bans, whitelist and priority queue do not travel with the mission folder, and they are the last thing standing between you and an unmoderated server.

1. Upload the old ban.txt, whitelist.txt and priority.txt into the config share, overwriting the empty ones already there.
2. Open Players and click Import existing. The confirmation is titled Import existing lists? and explains what it reads; confirm with Import & adopt. Nothing is deleted — entries already on disk are pulled into the panel so the two agree from now on.
3. If you ran a whitelist, enable enforcement on the Whitelist tab. It applies at the next restart.

Two pieces of housekeeping do not migrate either. Recreate your restart schedule in Scheduler with New task → Restart (controlled) — see automatic restarts with the Scheduler — and pick a frequency on Backups, where Daily suits most servers and everything is kept for 30 days (automatic backups and restore).

Only then cut over. Your address has changed, so update wherever players find you: your community listing, your Discord, any launcher collection, and your DNS record if you use one. Overview gives you Direct Connect and List on DZSA Launcher links to share. Announce the new ip:port clearly, and leave the old host running with a message-of-the-day pointing at it for as long as you are paying for it.

Troubleshooting

Frequently asked questions

Related guides

• Getting started with the control panel
• Making a manual backup over SFTP
• installing Steam Workshop mods