Project Zomboid Server Prevention Checklist (Build 42.19)

1. Give every server an owner and a written record

A stable server starts with a small, current record that another admin can understand without guessing. Keep it beside the backup documentation, not only in one person’s memory.

Identity

Server name and world/save name
Host machine or provider
Stable/unstable branch and current build
Primary and backup admin contacts

Operating commitments

Normal player cap and play hours
Maintenance window and announcement channel
Backup frequency and retention
Who can approve config, mod, and restore changes

Keep dated copies or a private version history for Zomboid/Server/<name>.ini and <name>_SandboxVars.lua. A readable diff is safer than remembering which field changed last week.

2. Lock in a deliberate configuration

Control	Build 42.19 default / practice	Operational rule
Network pair	`DefaultPort=16261` and `UDPPort=16262` unless deliberately changed	Document the actual pair and keep router, OS, VM/container, and provider firewall rules aligned.
Player capacity	`MaxPlayers` defaults to 32; the UI warns that counts above 32 can harm streaming and synchronization	Set the public cap from measured peak load, not from the hard maximum.
Empty-server behavior	`PauseEmpty` controls whether the simulation pauses with no players	Choose deliberately; it changes farming, generators, erosion, and other time-dependent expectations.
Access policy	`Open`, whitelist settings, and password determine who may create or use accounts	Private communities should prefer explicit access over public auto-enrollment.
Gameplay rules	Zombie, loot, infection, fire, and time rules belong in Sandbox settings (`SandboxVars`)	Generate from the current in-game UI, then customize real keys only.
Remote administration	RCON is optional and uses its own TCP port and password	Leave it disabled unless needed; if enabled, restrict source access and store the secret outside public files.

Separate network, server, and sandbox changes Change one class at a time and keep a rollback copy. Bundling a port move, mod update, zombie-population increase, and branch switch into one restart makes both testing and recovery unnecessarily hard.

3. Harden access without making daily administration painful

Player access

Use a whitelist or explicit account approval for private groups.
Remove departed players and stale elevated accounts promptly.
Keep the join password out of public screenshots, tickets, and repository files.
Document bans and role changes so a second admin can review them.

Admin access

Use a separate normal character for ordinary play.
Grant only the access level needed for the task.
Rotate admin, panel, RCON, and host credentials after staff changes.
Protect the host account with strong authentication and provider-supported MFA.

Do not place passwords, RCON secrets, provider API tokens, or private backup URLs inside public HTML, screenshots, query strings, or shared mod lists. Redact them before asking for help.

4. Treat mods as controlled releases

Multiplayer needs both the Workshop numeric IDs and the mods’ internal IDs. Keep a small manifest that maps each WorkshopItems entry to its Mods entry, required dependencies, purpose, and rollback note.

Freeze the proposed list. Record added, removed, and updated Workshop items before maintenance begins.
Take a full pre-change backup. Include configuration and the matching multiplayer world.
Test on a disposable copy. Start, join, create a character, visit affected map areas, and complete a save/restart cycle.
Announce client requirements. Players should use the same game branch and allow the same dependencies to download.
Deploy during a window. Keep the previous manifest and files available for rollback.
Watch the first live session. New items spawning is not enough; verify old containers, vehicles, map cells, and player inventories.

Map mods deserve a stricter rule Adding, removing, or reordering map content after cells have been visited can leave persistent conflicts. Test against a copy of the real world and keep the pre-change backup longer than a routine item-mod update.

5. Back up the whole service, not one folder

A restorable backup set contains at least:

Zomboid/Server/ for INI, SandboxVars, spawn regions, and related server configuration
Zomboid/Saves/Multiplayer/<name>/ for map, chunks, player/world databases, and persistent state
The mod manifest and exact server branch/build note
Any service, container, scheduled-task, or provider configuration needed to start the same instance

When	Backup action	Retention purpose
Routine play	Automated dated backup after a clean save point	Recover ordinary mistakes and recent corruption.
Before game, branch, mod, or sandbox changes	Full configuration + world snapshot, clearly labeled pre-change	Provide a coherent rollback point.
After a validated change	New known-good backup after one save/restart test	Reduce dependence on the previous version.
Periodic archive	Copy to storage outside the server host	Survive disk loss, provider failure, ransomware, or accidental deletion.

Use the 3-2-1 idea Keep multiple copies, on more than one storage type or location, with at least one copy outside the live host. Encryption is useful for off-site archives, but keep the recovery key somewhere the backup admin can actually reach.

6. Monitor early warnings, not just “server online”

Host health

CPU saturation and sustained load
Memory pressure and swapping
Disk free space, latency, and backup growth
Outbound bandwidth, latency, and packet loss

Service health

Join success from a normal player account
Save and restart duration
Repeated mod, database, or map-cell errors
Age and size of the last successful backup

Choose thresholds from your own normal peaks. A single memory number cannot predict the effect of player count, zombie population, active map cells, vehicles, animals, and mods. Trend the server before deciding what “too high” means.

7. Use a maintenance rhythm players can trust

Cadence	Admin checklist
Each play day	Check free disk, last backup, current branch, join health, and obvious repeating errors.
Weekly	Review access, backup retention, resource trends, mod updates, and player-reported trouble spots.
Before maintenance	Announce downtime, freeze changes, take a full backup, record versions, and prepare rollback criteria.
After maintenance	Start privately, join as an ordinary player, verify persistence after restart, then reopen gradually.
After staff changes	Remove access, rotate shared secrets, update contacts, and confirm the backup admin can still restore.

Maintenance announcements should say what will change, when the server closes, expected downtime, and whether rollback may remove progress. Clear expectations reduce panic reconnects during a fragile recovery window.

8. Prove the plan before an emergency

Restore a recent full backup into a private instance.
Join with both an admin and an ordinary account.
Verify characters, containers, vehicles, map chunks, sandbox settings, and mods.
Run a clean save and restart, then join again.
Record recovery time, missing instructions, and who completed each step.

Repeat after host migrations or major branch changes. A backup label, archive size, or green scheduled-task result does not replace a successful restore.

When prevention is no longer enough If a drill or live session exposes connection failures, crash loops, mod breakage, desync, or corrupted state, follow the symptom-based incident runbook and preserve the failed state before making destructive changes.

Project Zomboid Server Prevention Checklist (Build 42.19)

1. Give every server an owner and a written record

Identity

Operating commitments

2. Lock in a deliberate configuration

3. Harden access without making daily administration painful

Player access

Admin access

4. Treat mods as controlled releases

5. Back up the whole service, not one folder

6. Monitor early warnings, not just “server online”

Host health

Service health

7. Use a maintenance rhythm players can trust

8. Prove the plan before an emergency

Related Articles