Change the map on a DayZ PC server

By Niko Catarino

Updated 8 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.

Follow the Bitterroot or Banov and BanovFrost procedure when choosing those missions. Check the author’s economy and seasonal files as part of the map selection.

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. Test a player’s join as well as the Sakhal mission installation.

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.

Recover a missing Sakhal mission

If mpmissions/dayzOffline.sakhal is missing, first confirm you are inspecting the installation your service actually starts. Sakhal arrived with DayZ 1.26; a server copy from before that release won’t supply the terrain by changing its template name.

Back up the existing missions and saved worlds, then update the actual server installation on the branch your players use. Check the update result and look for the complete Sakhal mission again. On an already current installation, investigate missing or misplaced files and use the documented repair/validation procedure after preserving local edits. Don’t rename a Chernarus folder to dayzOffline.sakhal or treat the reference economy repository as a substitute for the game’s terrain files. Select Sakhal only after the matching server files and mission are present.

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. Check compatibility with your DayZ build; an accessible repository alone won’t tell you whether its files still work.

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.

Name a generically labelled mission folder

An author’s download may call its source folder Mission or mission. Confirm the intended <MissionName>.<TerrainName> from that author’s server configuration or installation readme before placing it under mpmissions. The part after the dot identifies the engine terrain; the Workshop title is not a reliable substitute. Bohemia documents this format in its mission-template setting.

Once you have the confirmed full name, give the extracted mission folder that name and set the existing template value to match. Keep init.c and the other mission files directly inside it, without another wrapper directory. If the author doesn’t provide a selector, obtain it before starting; renaming the folder alone cannot identify an unknown terrain. A No world with name error also warrants checking whether the map package loaded, rather than repeatedly guessing suffixes.

Check the Esseker mission before startup

Start with Esseker, Workshop item 2462896799, and the server repository linked by its author. The repository’s Mission Files/dayzOffline.Esseker directory contains the mission. Keep the Mission Files wrapper outside mpmissions when preparing a test copy, and match the template to the actual mission directory.

Before starting that copy, follow the mission XML check. In the reviewed revision, cfgrandompresets.xml contains decorative comments that fail strict XML parsing. Correct the comments in a working copy, preserve the item definitions and parse it again. Keep the original file and your diff.

That repository revision dates to July 2021 and describes DayZ 1.13 compatibility changes. Confirm the mission, current map package and dependencies support your installed game build before proceeding. Use the signing key supplied with the matching map package. Passing the XML check alone does not establish current compatibility or a successful player join.

Choose the Valning patch for your game version

Check your installed DayZ version before adding Valning Map, item 1880753439. Its Required Items list includes Valning Compatibility Update, item 3812913919, but the patch author specifies DayZ 1.30 only and says to leave it out on 1.29. Read that version condition even if a mod manager offers to install the dependency automatically.

For a 1.30 test instance, the patch author instructs you to load the compatibility update after the original Valning package on both the server and clients, and copy its supplied Valning_Compatibility_Update.bikey into the server’s keys directory. The patch supplies navmesh and object fixes; you still need the original terrain and its mission. The author says this patch requires no additional mission changes or configuration.

The original map’s description directs server owners to its Discord #server-files channel for the base mission. Obtain those files and their instructions before selecting a template; don’t guess a directory name from the Workshop title. Check the original map’s current key and dependencies as well as the patch’s, then use the terrain, spawning and restart checks below.

These two sections used AI-assisted research and drafting on 8 October 2026. Esseker’s saved XML matches the author’s current repository revision, and the comment defect was reproduced locally. Valning’s instructions come from the two linked descriptions; its current mission, package contents and runtime behavior have not been verified here. Neither map received a game test.

Prepare the Siberia mission and dependencies

Use SiberiaMapPublic, item 3615434235, and the mission repository linked from its description. The checked download contains empty.Siberia. Place that directory directly under the test server’s mpmissions, then match the mission template to it. Keep the test instance’s profiles and saved world separate from your existing map.

The repository’s September 2026 mission and profile archives match the files in the author’s earlier repository. That repository’s README lists SiberiaMapPublic, WindstridesClothingPack, Namalsk Survival, VPPAdminTools, TeleportTerminal, SpawnerBubaku, CF and BuilderItems. Check those packages against the release you intend to run; a checklist for another Siberia package may describe different features.

The supplied init.c calls Namalsk Survival’s event manager and creates its watch items. Keep Survival for this mission unless you deliberately adapt those scripts and their related configuration. Follow CF and VPPAdminTools installation, with CF before VPP in the normal mod list. SpawnerBubaku’s author specifies server-only loading through -servermod=@SpawnerBubaku. Follow each remaining package’s own instructions; TeleportTerminal’s public description does not establish its loading scope, so confirm that before completing your launch list.

The earlier README names RedhunterSiberiaPublicKey.bikey. Check the key supplied with your installed map and retain the required dependency keys too. Review the mission’s cfggameplay.json before enabling it: the supplied file includes custom object references and placement settings that affect gameplay. Some creatures and other features described in the README require the author’s private content. Check missing classes against the packages you actually have before expecting those features to work.

Review Siberia’s supplied teleport profiles

Siberia’s profiles.rar contains SpawnerBubaku and TB_TeleportMod directories. Its teleport configuration belongs to TeleportTerminal, item 3666057845. The supplied TB_TeleportMod/Config/TeleportConfig.json disables all six terminal locations, while TeleportTriggerConfig.json enables four separate trigger zones. An absent terminal therefore doesn’t tell you whether the trigger system is running.

Both supplied files declare version 1.1. The current author’s examples use terminal version 1.3.1 and trigger version 1.1.2, with additional settings. Prepare them as follows:

1. After confirming the mod’s installation requirements, let the installed release generate settings in the test instance’s profiles directory. Stop the test server and back up those files alongside the untouched Siberia archive.
2. Compare the generated files with Siberia’s two teleport files. Transfer the intended positions and behavior into the current structure, leaving ConfigVersion under the mod’s control. Check the newer destination, object, requirement and damage-protection fields. Validate the JSON; the author’s web examples include comments, and the reviewed terminal example also lacks a comma after CooldownTime.
3. Inspect each trigger and destination on the installed terrain before admitting players. Check arrival height, clear space, orientation, return access and behavior after a restart. The author defines a zero Y-coordinate as ground-height detection; roofs and bunkers need their actual height. Keep unused terminal entries disabled until their positions are checked.

Review the SpawnerBubaku files separately against its installed version. Replacing the whole profiles directory would also replace unrelated settings and data.

Check Siberia’s SpawnerBubaku files

Keep the supplied profiles archive intact and work on a test copy. It contains three SpawnerBubaku files with different jobs:

File	What the supplied copy contains
SpawnerBubakuV2.json	44 trigger locations, with spawn classes and counts nested under bubakProps
SpawnerBubaku.json	15 locations using the older, flat field layout
StaticBubakSpawner.json	The author’s default Prison and Skalisty static-spawn examples

Scroll to see all columns →

The June 2026 configuration loader selects SpawnerBubakuV2.json when there is no choice of V2 files. When several names match SpawnerBubakuV2*.json, it chooses one randomly. Keep backups outside that directory; SpawnerBubakuV2-backup.json would match too. This loader doesn’t select the legacy SpawnerBubaku.json. Renaming that older file would leave its fields in the wrong structure.

Compare your installed release’s generated configuration with the V2 file before merging changes. Keep spawn classes, inventory, counts and damage settings together under bubakProps. Check the trigger position, shape, delay and spawn positions for each location you retain. The supplied V2 file uses 34 distinct classnames, including SiberiaClown and DemonBoss; establish which installed package supplies each one. A name in this JSON doesn’t supply the creature or prove you have access to the author’s private content.

Review the static file separately. Its two entries exactly match the examples in the author’s configuration source, so check their positions on Siberia before using them. To omit these examples from your test setup, keep a valid StaticBubakSpawner.json and set its BubakObjectLocations array to []. Deleting the file instead makes this loader generate its defaults again. This change only clears the static entries; the V2 triggers remain separate.

Check repeated spawns as well as the first activation. In the reviewed trigger implementation, the count used by onlyfilluptobubaknum tracks objects derived from ZombieBase. It doesn’t provide the same limit for spawned weapons or keys. Leave and re-enter a test trigger after its delay, inspect the remaining objects, then repeat after a restart. Choose counts and delays from those results. Check SpawnerBubaku/SpawnerBubaku.log under the active profiles directory alongside the RPT and script logs when the selected file or spawned content differs from what you expect.

These Siberia sections used AI-assisted research and drafting on 8 October 2026. We compared the author’s archive files, TeleportTerminal instructions and ten SpawnerBubaku source files. The GitHub source has not been matched to an installed Workshop package; configuration migration, creature spawns and teleport destinations have not been tested in-game.

Carry retained mods into the new mission

Changing the template selects another mission directory. Your old mission’s economy registrations, scripts and map-specific settings remain there. Rebuild the setup for each retained mod in the new mission instead of copying the old mission over the map author’s files.

1. List the packages you will keep and check their support for the new terrain and game build. Remove the previous terrain and its exclusive companion packages from the new instance’s -mod list where they are no longer required. Preserve dependencies still needed by retained mods, and give players the revised client list.
2. Start from the new map’s complete mission. Copy each retained mod’s supported economy XML into it and add its registrations to that mission’s cfgeconomycore.xml. Check for duplicate registrations and adapt tier, usage and position references to the new terrain. Bohemia’s economy-extension reference explains why these registrations belong to the selected mission.
3. Merge required initialization into the new mission’s existing init.c, preserving its date, weather and event setup. Review player spawns, vehicle events, static objects and other coordinates on the new terrain. An old trader camp or teleport destination can point into water, underground or outside a useful play area.
4. Check both mission and profiles settings for each mod. Expansion, for example, separates mission objects and traders from many profiles settings. Use settings generated for the new mission as the starting point, then reapply compatible choices and verified positions. Don’t bring old world databases or territory state across just because their filenames match.
5. Check the files, start with separate storage and join as a normal player. Test the retained mod’s actual feature as well as natural loot and player spawning. Add changes in small groups so you can identify which one breaks the working map.

For a move to Sakhal, this includes rebuilding mod configuration under dayzOffline.sakhal; selecting it does not migrate another map’s Expansion or trader setup. Keep the original mission, profiles and save together for recovery. Follow mod removal when changing the packages used by an existing world.

Use CJ187-SummerChernarus on Chernarus

CJ187-SummerChernarus, item 1644467354, replaces Chernarus textures, vegetation and other assets to give the existing terrain a summer appearance. Keep your Chernarus mission selected when adding it. The author’s description doesn’t provide a separate mission template to switch to.

Back up the mission, persistence and current mod list, then install the original package on the test server and joining clients using the mod installation procedure. Keep its signing key and package versions matched. Check other vegetation, terrain-texture and ghillie replacements in your mod set before combining them. The author also replaces existing ghillie appearances without adding new classnames, so this change doesn’t need an invented summer-ghillie economy entry.

Use the change notes to choose what to check after installation. The April 2026 hotfix names DayZ 1.29 compatibility, followed by a summer satellite-map update. May and June 2025 fixes address infected pathfinding inside buildings; earlier updates changed fishing, grass and sounds. These are author release notes, not results from your server.

Join with a normal client and compare several areas, including a town, woodland and coast. Check distant textures, ground vegetation, ghillie appearance, fishing and infected movement through buildings. Also inspect custom map edits for misplaced objects or unexpected cover. Repeat with your usual weather and lighting settings; the seasonal artwork alone doesn’t establish the weather your mission will use.

If the combined mod set fails those checks, stop the test service and restore the previous packages and launch list. Keep the saved world intact while diagnosing an asset or compatibility problem. Review the full mission only if another change also altered its files.

This section used AI-assisted research and drafting on 6 October 2026. We read the original description and latest ten of 41 change entries. Current package contents, client rendering, pathfinding, performance and saved-world recovery haven’t been tested here.

Use Winter Chernarus V2 and its matching mission

The original Winter Chernarus, item 1597140327, directs server owners to Lad’s Winter Chernarus V2, item 2981609048. V2 is a standalone successor. Remove the original from the test launch list when switching, and install V2 on the server and joining clients with its current signing key. Use the Workshop distribution; the author forbids including it in a server pack.

Back up your Chernarus mission and world first. V2 changes Chernarus’s assets and winter behavior. Its author-linked mission repository offers Regular and Hardcore presets. Use the matching files supplied with your installed package, then compare your custom settings before replacing anything.

The checked repository uses these mission directory names:

• RegularWinter.chernarusplus for Regular.
• HardcoreWinter.chernarusplus for Hardcore.

Extract the chosen directory directly into mpmissions and set the existing mission template to that exact name. Keep your own hostname, passwords, ports and service settings. Both sample configurations enable cfggameplay.json; Hardcore also disables third-person view and the crosshair, uses colder monthly temperatures and has a different night-speed multiplier. Those choices affect gameplay beyond the snow textures.

Check the date and weather together. Both reviewed init.c files reset dates outside a 15 January to 15 February window back to 15 January. The Workshop description suggests 20 February for some blue sky, but that date will be reset by these examples unless you adjust their date logic. Preserve your other mission initialization and starter-equipment code when making that change.

Both supplied cfgweather.xml files have enable="0", so editing their weather ranges alone won’t activate them. Follow the weather configuration guide and decide which system controls weather before enabling a file. The Hardcore XML also contains a comment saying snowfall should remain zero beside nonzero snowfall limits; check the actual settings against the matching release instead of treating that comment as the intended winter setup.

For a terrain add-on built against the original Winter scripts, Lad specifies changing its required addon from chernarus_winter_scripts to WinterChernarusV2Scripts. This is work for the add-on author; changing a server folder name won’t update that dependency. Keep the old package’s Namalsk settings separate from V2 unless the current authors explicitly document that combination.

Join the test mission with an ordinary client and inspect snow brightness, distant textures, temperatures and weather. Check snow interactions with your survival mods, fresh-player equipment and saved state after a restart. The September 2026 V2 notes changed snowball action names for Namalsk Survival compatibility, while the checked mission repository dates to February 2025. Confirm the files match your installed package before switching the live service.

This section used AI-assisted research and drafting on 7 October 2026. We read both original descriptions, the latest ten change entries for each package and nine complete V2 mission/configuration files. Current binaries, the remaining mission files and gameplay haven’t been tested here. Keep your previous Chernarus recovery set until the checks above pass.

Recover when a game update breaks a community map

A DayZ update can require changes from the terrain or mod author before that combination works again. For example, Bohemia’s 16 September 2026 Experimental 1.30 notes require terrain authors to regenerate navmesh files for a changed format. That is a version-specific author task; deleting your saved world cannot regenerate the terrain package.

Before a planned update, read the game and map release notes and rehearse the proposed combination on a separate instance. Where the author supports testing an upcoming build, keep its Experimental installation and save separate. Record the game, terrain, mission and dependency versions that pass a player join, natural spawning and restart checks.

If the updated server fails:

1. Keep players out of the affected instance and save the first relevant RPT/script error. Record which packages and mission files changed. Avoid repeated restarts or a wipe while the cause is unknown.
2. Check the map author’s advice for that exact game build. Install the compatible package, dependencies and mission changes on a test copy, then merge your custom edits. If no compatible release is available, keep the map offline while waiting for the author.
3. To offer a temporary world, prepare a separate current-build vanilla instance and mission with its own profiles and storage. Check that no launch argument, panel setting or shared mod database points back to the affected world’s data. Test a normal client join and tell players that this temporary world’s progress stays separate.
4. Before returning to the community map, test the compatible set with a copy of its saved world. Follow any explicit author migration/reset requirement, then verify player and placed-object state after a restart. Keep the original backup until those checks pass.

Restoring old files is useful only when the game, required mods and joining clients remain compatible. An older server executable alone won’t accept clients that require another build. Preserve the full recovery set and diagnose compatibility before deciding whether to restore it; do not merge the temporary world’s save into the community map.

This recovery procedure is based on the linked release and configuration references. It does not establish that a particular map works on an installed game build; no game-update or world-recovery test was run for these instructions.

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 intact until the new map passes your checks. For rollback, stop the server and restore the matching old configuration, package set and data. Do not merge the two persistence trees.