Change the map on a DayZ PC server

By Niko Catarino

Updated 3 October 2026

A DayZ map change needs a matching mission and its terrain content. Set the active configuration’s mission template to the installed mission directory. For a Workshop map, also install and load the map packages and their required dependencies on the server and clients.

Start with a vanilla server you can join. Rehearse the new map on a test copy with its own saved state before switching your community.

For the original Namalsk packages, use the Namalsk installation procedure for mission presets, Survival initialization and economy checks.

Preserve the old world

Stop the server and take a recoverable backup of the configuration, launch arguments, missions, persistence, profiles and mod-owned data. Record any custom -mission or -storage argument, as well as -config.

Keep the original mission directory and data intact. A map switch is not a supported way to transport old bases, vehicles or player inventories into another terrain. Do not copy Chernarus persistence into a new Namalsk mission.

On managed hosting, check whether the map-selection control installs or replaces files before using it. Preserve the old world through the provider’s supported backup/export workflow.

Select a shipped mission

For a vanilla mission, identify the directory actually present under mpmissions. Common names are:

Map	Mission directory	Player content required
Chernarus	dayzOffline.chernarusplus	DayZ base game
Livonia	dayzOffline.enoch	DayZ base game; Livonia is included
Sakhal	dayzOffline.sakhal	DayZ base game and Frostline

Scroll to see all columns →

Bohemia included Livonia with DayZ in update 1.25. Players joining Sakhal need Frostline, as stated in the official expansion release announcement. Installing the Sakhal server mission does not establish that a player can join it.

Use the matching files for your installed build. Bohemia maintains reference mission files; a reference is useful for comparison, but should not overwrite your edited mission without review.

In the server configuration selected by -config, locate class Missions and its existing mission class. Change the template value to the chosen directory name. For example, to select an installed Livonia mission:

template = "dayzOffline.enoch";

This is one field inside the existing mission class. Keep its quotes and semicolon. Do not add a second mission block. If startup supplies a separate -mission path, reconcile that override with the intended mission rather than editing a configuration that never takes effect.

Bohemia’s server configuration reference defines the mission selection and startup parameters.

Install a Workshop terrain and mission

Use the map author’s Workshop listing and linked server repository. Read dependencies, installation instructions and the mission choices before downloading. A map package and a ready-to-run mission are different things.

For example, the Namalsk author’s server repository documents these packages for its supplied missions:

Package	Workshop ID	Role in the default mission
Namalsk Island	2289456201	Terrain content
Namalsk Survival	2289461232	Survival systems used by the supplied mission scripts

Scroll to see all columns →

The author supplies mission files and a default configuration in Namalsk Survival’s Extras folder. Prefer those files from your installed release, then check the repository for instructions and changes. A repository being accessible today does not establish compatibility with every new DayZ build.

1. Install the terrain and the packages required for your chosen mission. For the unmodified Regular Namalsk example, install both packages above and copy their supplied sumrak.bikey into the server’s keys directory. Follow the PC mod procedure for folders, signature checks and load order.
2. Extract the chosen mission so its actual directory sits directly inside mpmissions. The Namalsk choices are regular.namalsk and hardcore.namalsk. Avoid nesting the mission inside the ZIP’s repository wrapper folder.
3. Review the author’s default server settings against your own. Keep your address, ports, credentials and other service-specific values.
4. Change the active mission template to the installed directory name. For the author’s Regular Namalsk mission, that is regular.namalsk.
5. Load client-required terrain packages through the normal -mod list, following the author. Do not move them into -serverMod to hide the download from players.

Namalsk Island can be used separately, but that needs an adapted mission. The supplied Regular mission’s init.c calls Survival’s event manager and adds its starter items. Removing Survival requires reviewing those scripts and the economy includes; removing one XML include alone is not a complete conversion.

Review the map’s licence before operating a commercial community. The Namalsk author forbids server monetisation, including paid priority queues. Donations are permitted only when donors receive nothing in return. Apply the author’s rules before enabling purchases for that map.

Namalsk also uses economy settings that differ from vanilla terrain. Start with its supplied mission and migrate selected edits after testing. An old types.xml, trader layout or coordinate list may reference classes and locations absent from the new map.

Check a Nitrado PC map change

With the server stopped, use the service’s file access to install the map package, keys and extracted mission. Check the package’s folder name against the additional-mod list, save the list and select the matching mission in the supported configuration workflow.

Re-download the live configuration and inspect the saved template before starting. If a panel regenerates serverDZ.cfg, change the panel’s supported source instead of relying on an SFTP edit it will replace.

The September tutorial linked below demonstrates an Esseker installation on Nitrado PC. Its title lists other terrains, but the footage does not test each one. Its controls do not establish that another provider has the same automatic installer or map list. In VXPanel, follow the configuration and mod management procedures for the controls your service exposes.

Verify the new terrain and saved state

Start the test server and check logs for the selected mission, missing packages and script errors. Join through the launcher with the map’s required client content.

Check these results before scheduling a live switch:

• The loading screen and in-game terrain match the intended map.
• A fresh player appears on usable ground with the expected starter equipment.
• Natural loot, infected and mission-specific systems operate in several areas.
• A returning player retains its state after a restart within the new test mission.
• The old world backup can still be restored with its matching launch settings and packages.

An admin-spawned item proves the class can load; it does not prove the map’s natural economy is configured. If the old map starts, check the active -config, mission template, any mission override and panel-generated settings. If startup fails, check mission nesting, terrain content, dependencies and the author’s script requirements.

Keep the old world parked while accepting the new one. For rollback, stop the server and restore the matching old configuration, package set and data. Do not merge the two persistence trees.