Project Zomboid is one of those games that refuses to die. It has been in Steam Early Access since 2013, and by 2025 the analysts at GameDiscoverCo estimated it had sold north of 15 million copies on Steam. The arrival of Build 42 late in 2025 sent players flooding back — the game had already logged an all-time concurrent peak above 65,000 players in 2022, according to SteamCharts, and Build 42’s multiplayer rollout triggered a fresh surge into early 2026. When that many people are trying to survive Knox County together, sooner or later somebody wants a persistent world that runs 24/7 without the host having to leave their PC on. That is where a Project Zomboid dedicated server comes in.

This guide walks you through building a Project Zomboid dedicated server from scratch in roughly 30 minutes, on either Windows or Linux, using the free official server tool (Steam App ID 380870). You will install SteamCMD, download the server, set an admin password, tune the config files, open the correct UDP ports, enable RCON, add Steam Workshop mods, and wire up systemd so the world restarts itself after a reboot. Every port number, filename, and command below has been verified against the official Steam tooling and community documentation rather than guessed, because a single wrong port or heap value is the difference between a running server and a black screen.

Why Run a Project Zomboid Dedicated Server?

Project Zomboid gives you three ways to play with friends, and they are not equal. The simplest is a co-op host (sometimes called a listen server), where one player clicks “Host” from the main menu. It is fast to set up, but the world only exists while that player is online, their CPU is shared between running the game and simulating the server, and everyone else’s ping is tied to that one home connection. The second option is renting a slot from a game-server host — convenient, but you pay monthly, you are boxed into their control panel, and mod installation is often clumsier than doing it yourself.

A true project zomboid dedicated server is the third option and the one this tutorial targets. It runs as its own headless process — on a spare PC, a home lab box, or a cheap cloud VPS — completely independent of any single player. The world keeps ticking whether zero or sixteen survivors are logged in, crops keep growing, and the zombie population keeps migrating. You own the save files, you control the mod list, and you can automate backups and restarts. The trade-off is that you do the setup yourself, which is exactly what the next twelve steps cover.

Hosting modelRuns 24/7Monthly costMod controlBest for
Co-op / listen hostNo (host must be online)FreeAutomatic, but host-boundQuick sessions with a couple of friends
Rented game hostYes~$8–$25Via control panelPlayers who want zero server admin
Self-hosted dedicated (this guide)YesFree on owned hardware, or VPS costFull manual controlPersistent communities and modded worlds

If you have already stood up a persistent world for another survival title — say a Valheim dedicated server or a Palworld dedicated server — the workflow here will feel familiar: SteamCMD to download, a config file to edit, ports to forward, and a service to keep it alive. Project Zomboid has a few quirks of its own (an interactive admin-password prompt and a Java heap that must be sized by hand), and this guide flags each one.

What You Need Before You Start (Prerequisites)

The Project Zomboid dedicated server is deliberately lightweight compared with, say, an ARK dedicated server, but it is unusually sensitive to single-thread CPU performance and to Java heap size. Get the memory allocation wrong and the server will crash on load; get the CPU wrong and a full lobby will stutter no matter how much RAM you throw at it. Here is what you need in place before Step 1.

ComponentMinimumRecommendedNotes
Operating systemWindows 10 / Ubuntu 22.04 LTSWindows Server 2022 / Ubuntu 24.04 LTS64-bit only
CPUModern quad-coreHigh single-core clock (PZ is single-thread heavy)Clock speed beats core count here
RAM (server process)4 GB free8–16 GB freeSet via the -Xmx Java flag
Disk~5 GB freeSSD with 10 GB+ freeServer files plus growing save data
SteamCMDLatestLatestFree command-line downloader from Valve
JavaBundledBundledThe server ships its own JRE — do not install Java separately
NetworkUDP 16261–16262 openStatic IP or DDNS + port forwardingUDP, not TCP

Hardware and RAM Requirements by Player Count

RAM is the single most important number to get right. The Java heap you assign with -Xmx is a hard ceiling: the server will use up to that much and crash if it needs more. Under-allocate and you get out-of-memory crashes when the map streams in; over-allocate past your physical RAM and the OS will swap and stutter. The independent hosting guide from RedSwitches recommends roughly 6 GB for a handful of players and scaling from there. Build 42 is noticeably hungrier than Build 41 for both RAM and CPU, so pad these numbers if you run the unstable branch.

PlayersVanilla RAM (-Xmx)Modded RAMCPU guidance
1–44–6 GB6–8 GBAny modern quad-core
5–88 GB10–12 GBStrong single-core clock
9–1610–12 GB12–16 GBHigh-clock 6-core+
16+ (heavily modded)12–16 GB16–24 GBDedicated box or VPS

Build 41 vs Build 42: Which Branch Should You Run?

This is the most important decision you will make, so make it deliberately. As of mid-2026, Build 41 (B41.78) is still the stable, default branch that SteamCMD installs when you download App 380870 with no extra flags. Build 42 launched on the opt-in “unstable” beta branch in December 2024, and multiplayer support arrived in that branch in December 2025 with version 42.13, per the developers’ Steam discussion thread. Build 42 is still officially an unstable beta — The Indie Stone has not announced a stable release date.

FactorBuild 41 (B41.78)Build 42 (unstable)
BranchDefault / stableOpt-in “unstable” beta
MultiplayerMature and stableAdded Dec 2025 (v42.13), still WIP
Recommended max playersHigher, well tested~16–20 while in beta
Mod libraryHuge, fully compatibleGrowing; many mods not yet ported
Stability for a persistent worldBest choice todayExpect occasional breaking updates

The editorial recommendation is simple: build your first dedicated server on Build 41. It is stable, its multiplayer is battle-tested, and the mod ecosystem is complete. Once your server is running and you understand the config, this guide includes a dedicated section on opting into Build 42 if you want the newest content. Never mix save files between the two branches — that is a fast route to a corrupted world.

Step 1 — Install SteamCMD

SteamCMD is Valve’s command-line version of the Steam client, and it is how you download the server files anonymously — no Steam account, no password. If you have set up a Satisfactory dedicated server or a Minecraft server before, you already know the drill. The official reference lives in the Valve Developer Wiki.

On Linux (Ubuntu/Debian), install the 32-bit support library first — SteamCMD needs it even on a 64-bit system — then create a dedicated non-root user and drop SteamCMD into its home directory:

# Run as root or with sudo
sudo apt update
sudo apt install -y software-properties-common lib32gcc-s1 curl

# Create an unprivileged user to own the server (never run game servers as root)
sudo useradd -m -s /bin/bash zomboid
sudo su - zomboid

# Download and unpack SteamCMD into the zomboid user's home
mkdir -p ~/steamcmd && cd ~/steamcmd
curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf -

On Windows, download steamcmd.zip from Valve, extract it to a permanent folder such as C:\steamcmd (never a temp folder, and never inside Program Files where permissions will fight you), then run steamcmd.exe once so it self-updates. The first run prints a stream of update lines and drops you at a Steam> prompt. That prompt is where the next step happens.

Step 2 — Download the Dedicated Server (App 380870)

The Project Zomboid Dedicated Server is a separate free application from the game. The game is App ID 108600; the server tool is App ID 380870. You do not need to own the game on the account to download the server, because it installs with anonymous login. This one command downloads and validates the full server into a folder you specify:

# Linux (run from ~/steamcmd as the zomboid user)
./steamcmd.sh +force_install_dir ~/pzserver \
  +login anonymous \
  +app_update 380870 validate \
  +quit

On Windows the equivalent, run from inside the SteamCMD prompt, is:

force_install_dir C:\pzserver
login anonymous
app_update 380870 validate
quit

When the download finishes you will see a success line similar to the one below. The validate keyword is worth keeping in your routine forever: it re-checks every file against Steam’s manifest, so re-running the exact same command later is also how you update the server after a patch.

Update state (0x61) downloading, progress: 98.55 (3221225472 / 3268672512)
Success! App '380870' fully installed.

Pitfall — the “0x602 / disk write failure” error. If SteamCMD aborts partway with a disk-write error, nine times out of ten the install directory is inside a permission-restricted path or the disk is full. Point force_install_dir at a folder your user fully owns (like ~/pzserver or C:\pzserver) and confirm you have several gigabytes free before retrying.

Step 3 — First Launch and Set Your Admin Password

The server ships with launch scripts already built. On Linux the script is start-server.sh; on Windows it is StartServer64.bat. The very first launch is special: because no admin account exists yet, the server stops and interactively asks you to create one. Run the script from inside the server directory:

# Linux
cd ~/pzserver
./start-server.sh

# Windows: double-click StartServer64.bat, or from a terminal:
# C:\pzserver\StartServer64.bat

Within a few seconds the console pauses at the admin-password prompt. Type a strong password (you will not see the characters as you type on Linux) and confirm it:

Enter new administrator password:
Confirm the password:
...
SERVER STARTED
Zombies loaded, world initialised
*** SERVER READY ***

Once you see SERVER STARTED, the world is live and listening. This first run also generates all of your configuration files, which is exactly why we launch before editing anything. Type quit in the server console (or press Ctrl+C once and let it save) to shut it down cleanly so we can edit the freshly created config. The admin account you just made is your in-game super-user: log in with the username admin and that password to access server commands from inside the game.

Pitfall — never kill the process with kill -9. Project Zomboid writes player and world data on shutdown. Force-killing the process (or closing the window with the X on Windows mid-save) is the most common cause of “my base disappeared” reports. Always stop the server with the quit command or a single Ctrl+C and wait for it to finish saving.

Step 4 — Locate and Understand the Config Files

Project Zomboid keeps its server configuration in your user profile, not in the server install folder — a detail that trips up newcomers constantly. On Linux the files live in ~/Zomboid/Server/; on Windows they are in C:\Users\YOURNAME\Zomboid\Server\. Because we launched with no -servername argument in Step 3, the default config set is named servertest. Here are the three files that matter.

FileLocationControls
servertest.ini~/Zomboid/Server/Ports, player limit, passwords, mods, PvP, global rules
servertest_SandboxVars.lua~/Zomboid/Server/World ruleset: zombie count, loot rarity, day length, XP rate
servertest_spawnregions.lua~/Zomboid/Server/Which towns players can spawn in
Save data~/Zomboid/Saves/Multiplayer/The persistent world itself — back this up

If you launch with ./start-server.sh -servername myworld instead, the server reads myworld.ini, myworld_SandboxVars.lua, and so on. This is how you run several distinct worlds from one install. For this tutorial we will stick with the default servertest set to keep the paths predictable.

Step 5 — Configure servertest.ini (Ports, Players, Password)

Open servertest.ini in a plain-text editor (nano ~/Zomboid/Server/servertest.ini on Linux). The file is long, but you only need to touch a handful of lines to get a proper server running. The key settings are below; edit these while the server is stopped, because a running server overwrites the file on shutdown and will wipe your changes.

# --- servertest.ini (key lines) ---

# A password players must enter to join. Leave blank for an open server.
Password=ChangeThisJoinPassword

# Human-readable name shown in the server browser
PublicName=My Knox County Survival Server
PublicDescription=Modded co-op, wipe-free, backups nightly

# Show up in the in-game public browser? false = private/invite by IP
Public=false

# Max players (set to your hardware's comfort zone; keep B42 at ~16)
MaxPlayers=8

# Network. The game uses DefaultPort (UDP); 16262 (DefaultPort+1) is used
# automatically for direct connections. You do not set 16262 by hand.
DefaultPort=16261

# Global PvP toggle
PVP=false

# Pause the world when empty (saves CPU on small servers)
PauseEmpty=true

A few of these deserve explanation. Password is the join password every player types once; leave it empty for an open server. Public=true lists your server in the in-game browser, which is great for a community and a bad idea for a private friends-only world. MaxPlayers should match the RAM tier you picked earlier — setting it to 32 on a 4 GB box just guarantees crashes. Save the file and move on to memory, which is the other half of a stable server.

Step 6 — Allocate RAM Correctly with -Xmx

Project Zomboid runs on Java, so its memory ceiling is controlled by the Java -Xmx (maximum heap) and -Xms (initial heap) flags. This is the number that most often makes the difference between a server that runs for weeks and one that crashes when the map streams in a big city. The default heap that ships with the server is conservative; you almost certainly want to raise it to match the tier table from the prerequisites section.

There are two places you can set it. The cleanest is the JVM config file ProjectZomboid64.json in the server install directory, which holds the launch arguments as a list. Find the existing -Xmx entry and change its value:

// ProjectZomboid64.json (excerpt) -- give the server an 8 GB ceiling
{
  "mainClass": "zombie/network/GameServer",
  "vmArgs": [
    "-Djava.awt.headless=true",
    "-Xms8g",
    "-Xmx8g"
  ]
}

Alternatively, edit the launch script directly. Many admins copy StartServer64.bat to StartMyServer.bat on Windows (or copy start-server.sh) and set -Xms8G -Xmx8G right in the Java invocation. Either method works; pick one and stick with it so you are not fighting two conflicting values. Set -Xms and -Xmx to the same number to avoid heap-resize stutter, and never set -Xmx higher than your physical RAM minus about 2 GB for the operating system.

Pitfall — the silent out-of-memory crash. If your server dies a few minutes after players spread out across the map, and the log ends with a java.lang.OutOfMemoryError or simply cuts off, your heap is too small. Bump -Xmx by 2 GB and restart. Conversely, if the whole machine grinds to a halt and starts swapping, you set -Xmx higher than you have RAM — dial it back down.

Step 7 — Open Firewall Ports and Forward Your Router

Project Zomboid needs exactly two UDP ports: 16261 (the main game port, DefaultPort) and 16262 (DefaultPort+1, used for direct connections). Both are UDP, not TCP — this is the single most common configuration mistake, and forwarding TCP will silently fail. On a Linux box with UFW:

sudo ufw allow 16261/udp
sudo ufw allow 16262/udp
sudo ufw reload
sudo ufw status        # confirm both rules are listed

On Windows, open Windows Defender Firewall with Advanced Security, create a new Inbound Rule, choose Port, select UDP, and enter the range 16261-16262. If your server sits behind a home router (as opposed to a cloud VPS with a public IP), you also need to forward those same UDP ports on the router to your server’s local IP address. Give the server a static local IP or a DHCP reservation first, otherwise the forward will break the next time the machine’s address changes.

One useful quirk: if you deliberately leave 16262 closed, the game falls back to a Steam relay tunnel and still works — but you lose the lower-latency direct connection, so open both if you can. To let friends connect, share your public IP (search “what is my IP”) plus port 16261. A quick way to confirm the port is actually reachable from outside is an online UDP port checker while the server is running.

Step 8 — Enable RCON for Remote Admin

RCON (Remote Console) lets you send admin commands to the server without being logged into the game — kick players, save the world, broadcast a message, or trigger a restart from a script. It is disabled until you set a password. In servertest.ini, find and set these two lines:

# --- servertest.ini (RCON section) ---
RCONPort=27015
RCONPassword=ChangeThisToAStrongSecret

Restart the server so the change takes effect, then connect with any RCON client (the lightweight rcon-cli tool is popular). RCON runs over TCP on port 27015 by default, so if your admin machine is remote, open that port too — and lock it to your own IP, never the whole internet.

# Example: save the world and message players via rcon-cli
rcon -a 127.0.0.1:27015 -p ChangeThisToAStrongSecret "save"
rcon -a 127.0.0.1:27015 -p ChangeThisToAStrongSecret "servermsg \"Nightly backup in 5 minutes\""
CommandEffect
saveForce-write the world to disk immediately
playersList everyone currently online
quitSave and shut the server down cleanly
kickuser "name"Disconnect a specific player
servermsg "text"Broadcast a message to all players
addadmin "name"Promote a player to admin

Pitfall — RCON exposed to the internet. A weak or default RCON password on a publicly reachable port hands an attacker full control of your server. Always set a long random RCONPassword, and firewall port 27015 to your admin IP only. This is the same discipline you would apply to any remote-management port.

Step 9 — Install Steam Workshop Mods

Mods are half the reason people self-host, and Project Zomboid uses two parallel lists in servertest.ini to load them. WorkshopItems takes the numeric Workshop IDs (the number in a mod’s Steam Workshop URL) so SteamCMD knows what to download; Mods takes the Mod IDs (a short string listed on the mod’s page) so the game knows what to activate. You need both, and they must line up.

# --- servertest.ini (mods section) ---
# Workshop IDs: the big number from the Workshop URL, semicolon-separated
WorkshopItems=2392709985;2665923311;2857548524

# Mod IDs: the short names each mod's page lists, in load order
Mods=ModManager;Bandits;BetterSortCC

On restart, the server downloads each Workshop item automatically through SteamCMD and activates the matching Mod IDs in the order you listed them. Order matters: a mod that depends on another must come after its dependency, and a mod manager or framework usually needs to load first. Every client that joins will be prompted to subscribe to the same mods, so the list is shared automatically.

Pitfall — one Mod ID per Workshop item is not guaranteed. Some Workshop items bundle several mods, each with its own Mod ID, and some mods list a different Mod ID than their title suggests. Always read the mod’s Workshop page for the exact Mod ID and Workshop ID strings rather than guessing from the name, or the server will download the files but silently fail to enable them.

Step 10 — Run 24/7 with systemd (Linux)

Running the server from an SSH session is fine for testing, but the moment you close the terminal the server dies. On Linux, a systemd service keeps it running in the background, restarts it automatically if it crashes, and brings it back up after a reboot. Create /etc/systemd/system/zomboid.service with the following complete, working unit:

[Unit]
Description=Project Zomboid Dedicated Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=zomboid
WorkingDirectory=/home/zomboid/pzserver
ExecStart=/home/zomboid/pzserver/start-server.sh
Restart=on-failure
RestartSec=15
# Give the JVM time to save on shutdown before systemd force-stops it
TimeoutStopSec=90
KillSignal=SIGTERM

[Install]
WantedBy=multi-user.target

Enable and start it, then watch the log to confirm a clean boot:

sudo systemctl daemon-reload
sudo systemctl enable zomboid.service
sudo systemctl start zomboid.service
sudo journalctl -u zomboid.service -f   # follow the live log

Because the admin password was already created in Step 3, the service starts without prompting. On Windows, the equivalent is to wrap StartServer64.bat in a tool such as NSSM (the Non-Sucking Service Manager), which registers the batch file as a proper Windows service with auto-restart. Set the service to Automatic start so the world returns after a reboot.

Step 11 — Automate Backups and Restarts

A persistent world is only as safe as its last backup, and Project Zomboid saves are just folders on disk, which makes them trivial to snapshot. The script below copies the save directory into a timestamped archive and prunes anything older than seven days. Save it as ~/pz-backup.sh and make it executable with chmod +x ~/pz-backup.sh.

#!/bin/bash
# ~/pz-backup.sh -- nightly Project Zomboid world backup
SAVE_DIR="/home/zomboid/Zomboid/Saves"
DEST="/home/zomboid/pz-backups"
STAMP=$(date +%Y-%m-%d_%H%M)

mkdir -p "$DEST"
tar -czf "$DEST/pz-world-$STAMP.tar.gz" -C "$SAVE_DIR" .

# Keep only the last 7 days of backups
find "$DEST" -name "pz-world-*.tar.gz" -mtime +7 -delete
echo "Backup complete: pz-world-$STAMP.tar.gz"

Schedule it with cron so it runs every night at 4 a.m., ideally right after an automated restart when the world is freshly saved and player count is lowest:

# crontab -e  (as the zomboid user)
0 4 * * * /home/zomboid/pz-backup.sh >> /home/zomboid/pz-backup.log 2>&1

For real safety, copy the resulting archives off the machine — to another disk, a NAS, or object storage — because a backup that lives only on the server that crashed is no backup at all. A daily scheduled restart (via the same cron mechanism issuing an RCON quit, letting systemd restart the service) also clears accumulated memory and keeps long-running worlds smooth.

Step 12 — Connect and Verify Your Server

Time to make sure survivors can actually join. In the Project Zomboid client, choose Join, then Add Server. Enter the server’s IP address and port 16261. For a server running on the same machine, use 127.0.0.1; from another PC on your home network, use the server’s local IP; from the internet, use your public IP with the router forward in place.

# A healthy connection shows up in the server log like this:
[timestamp] Steam ticket validated for user: SurvivorMike
[timestamp] Player "SurvivorMike" connected (2 / 8 players)
[timestamp] Saving player SurvivorMike

If you see those connection lines and can walk around Knox County together, congratulations — your project zomboid dedicated server is fully operational. Log in with the admin account and the password from Step 3 to access the in-game admin panel, where you can spawn items, teleport, toggle god mode for testing, and manage players through a GUI rather than RCON.

Opt Into Build 42 Multiplayer (The Unstable Branch)

Once your Build 41 server is solid, you may want the newer content, crafting depth, and basement systems that Build 42 introduced. Remember the caveat from earlier: as of mid-2026 Build 42 is still an opt-in unstable beta, its multiplayer arrived only in December 2025, and updates can break saves and mods without warning. Treat a Build 42 server as an experiment, not your permanent home, and keep Build 41 backups.

Switching a SteamCMD install to the unstable branch means adding the beta flag to your update command:

# Download / switch the server to the Build 42 unstable branch
./steamcmd.sh +force_install_dir ~/pzserver \
  +login anonymous \
  +app_update 380870 -beta unstable validate \
  +quit

Start the server fresh on a new save name (use -servername b42world) so Build 42 never touches your Build 41 world. Expect a slightly higher RAM and CPU footprint, keep your player cap around 16 while the multiplayer code matures, and check each mod’s Workshop page for a Build 42 compatibility note before adding it — many popular mods have not been ported yet. When The Indie Stone promotes Build 42 to the default branch, you can move your community over with a planned migration rather than a surprise.

Tune Your World with SandboxVars.lua

The servertest.ini file governs the server’s plumbing, but the actual survival experience — how many zombies roam Knox County, how rare loot is, how fast time passes — lives in servertest_SandboxVars.lua. This is where you turn a punishing apocalypse into a relaxed base-builder or crank it into a nightmare. Stop the server, open the file, and you will find dozens of tunable values. The most impactful ones are below.

-- servertest_SandboxVars.lua (high-impact settings)
SandboxVars = {
    -- Overall zombie count: 1=Insane, 2=High, 3=Normal, 4=Low, 5=None
    Zombies = 3,
    -- How zombies are distributed across the map (4 = Urban Focused)
    Distribution = 1,
    -- In-game minutes per day (longer day = slower survival grind)
    DayLength = 3,
    -- Loot rarity: 1=Extremely Rare ... 6=Abundant
    FoodLoot = 4,
    WeaponLoot = 4,
    -- Skill XP multiplier (higher = faster character progression)
    XpMultiplier = 1.0,
    -- Do zombies migrate toward noise and player activity?
    ZombieRespawnHours = 72.0,
}

A few practical presets: for a co-op group that wants to focus on building, set Zombies = 4 (Low) and XpMultiplier = 2.0 so characters level faster and combat is less relentless. For a hardcore server, drop loot values to 2, raise the zombie count, and shorten DayLength. The same editing discipline from Step 5 applies here: the server rewrites this file on shutdown, so change it only while the server is stopped, and back up the file before a big edit so you can revert if a value breaks worldgen. Changes to zombie distribution and loot take full effect on newly generated chunks, so a fresh world reflects them most cleanly.

Harden Your Project Zomboid Server Security

A dedicated server is an internet-facing service, and it deserves the same hygiene you would give any exposed host. A misconfigured game server is a genuine foothold — open management ports and weak passwords have been the entry point for plenty of compromised home labs. Spend five minutes on the checklist below and you close off the obvious risks.

  • Run as a non-root, unprivileged user. The zomboid account from Step 1 means that even a worst-case exploit in the game code is contained to that user, not the whole machine.
  • Expose only what must be public. The internet needs UDP 16261–16262 and nothing else. Keep RCON’s TCP 27015 firewalled to your admin IP, and never leave it open to 0.0.0.0.
  • Use a long, unique RCONPassword. RCON grants full server control. Treat its password like an SSH key — long, random, and never reused from another service.
  • Harden SSH on the host. If you administer over SSH, disable password login in favor of keys, and add fail2ban to throttle brute-force attempts. This has nothing to do with Project Zomboid and everything to do with not losing the box.
  • Patch promptly. Re-run app_update 380870 validate after each game update. An out-of-date server is both incompatible with patched clients and potentially exposed to fixed bugs.
  • Keep backups off the machine. The nightly archive from Step 11 protects you from ransomware and disk failure only if a copy lives somewhere the server itself cannot reach.

None of this is exotic — it is the same least-privilege, minimal-exposure thinking that applies to any service you put on the public internet. Applied to a Project Zomboid dedicated server, it is the difference between a fun community project and an accidental open door.

Common Pitfalls to Avoid

Most failed Project Zomboid servers fall over for the same handful of reasons. Internalize these six and you will sidestep the overwhelming majority of forum help threads.

  • Forwarding TCP instead of UDP. Ports 16261 and 16262 are UDP. TCP forwards look correct in the router UI and do nothing. Double-check the protocol.
  • Editing config while the server runs. The server rewrites servertest.ini on shutdown. Stop it first, edit, then start — or your changes vanish.
  • Wrong heap size. Too little -Xmx causes out-of-memory crashes; too much causes OS swapping. Match RAM to the player-count table and set -Xms equal to -Xmx.
  • Editing the wrong .ini. If you launched with -servername myworld, edit myworld.ini, not servertest.ini. The default name is servertest.
  • Running as root. A game server should never run as root. Use the unprivileged zomboid user from Step 1 so a compromise can’t own the whole box.
  • Mixing Build 41 and Build 42 saves. The two branches use incompatible save formats. Loading a B41 world in B42 (or vice versa) corrupts it. Keep separate save names per branch.

Troubleshooting: Common Errors and Fixes

When something breaks, the server log is your first stop — on Linux it streams to journalctl -u zomboid.service if you used the systemd unit, and full logs land under ~/Zomboid/server-console.txt. The table below maps the errors you are most likely to hit to their real cause and fix.

SymptomLikely causeFix
“Server port 16262 is closed” warning at startup16262/UDP not forwardedHarmless — server falls back to Steam relay. Forward 16262/UDP for direct, lower-latency connections.
Friends get “connection timed out”Ports not forwarded, or wrong public IP sharedConfirm UDP 16261–16262 forwarded to the server’s local IP; share your public IP, not local.
Server crashes minutes after players spread out-Xmx heap too small (OutOfMemoryError)Raise -Xmx by 2 GB, set -Xms equal, restart.
Whole machine freezes / heavy swapping-Xmx set higher than physical RAMLower -Xmx to physical RAM minus ~2 GB.
Mods download but don’t activateMismatch between WorkshopItems and Mods IDsCopy exact Mod ID and Workshop ID from each mod’s page; fix load order.
Config changes keep revertingEdited servertest.ini while server was runningStop server, edit, then start.
“Steam ticket” / authentication errors on joinSteam mismatch between client and server branchEnsure both are on the same branch; use -nosteam only for non-Steam LAN testing.
RCON client won’t connectBlank RCONPassword or port 27015 blockedSet a strong RCONPassword, open TCP 27015 to your admin IP.
Base / progress disappeared after restartServer force-killed mid-saveAlways stop with quit; restore from your nightly backup.
Server won’t start after a game updateServer files out of date vs. clientsRe-run the app_update 380870 validate command to patch.

Advanced Tips for Performance and Scaling

Once the basics are humming, a few advanced moves squeeze more out of your hardware and keep a growing community happy. These are the same principles that apply to any heavyweight survival server, whether it is Project Zomboid or a sprawling modded save on another engine.

Prioritize Single-Core Clock, Not Core Count

Project Zomboid’s simulation is heavily single-threaded, so a CPU with a high boost clock will outperform a many-core chip with a lower clock, even though the latter looks better on paper. When picking a VPS, favor plans that advertise strong per-core performance over ones that just list a big core count. If you are running on bare metal alongside other workloads, pin the server process to dedicated cores so a busy neighbor can’t starve the simulation.

Run Multiple Worlds from One Machine

Because each config set is keyed by its -servername, you can run several independent worlds on one box. Each instance needs its own port pair: the first uses 16261/16262, the second 16263/16264, and so on. Give each a separate systemd unit and a distinct save name, size each one’s -Xmx to its expected population, and make sure the total heap across all instances leaves headroom for the operating system. This is the cheapest way to offer, say, a PvE world and a PvP world to the same community.

Be Ruthless About Mod Performance

Every mod adds simulation cost, and a bloated load order is the quiet killer of late-game performance. Add mods in small batches and watch the tick rate after each addition rather than pasting a 60-mod list and hoping. Map mods and mods that add lots of persistent items or NPCs are the heaviest; framework mods that other mods depend on are cheap but must load first. When performance dips, bisect the list — disable half, test, and narrow down — the same way you would debug any dependency problem.

Frequently Asked Questions

Do I need to own Project Zomboid to run the dedicated server?

No. The Project Zomboid Dedicated Server (App ID 380870) is a free, separate application that installs through SteamCMD with anonymous login, so no account or purchase is required on the server itself. Every player who connects, however, does need to own the game (App ID 108600).

How much RAM does a Project Zomboid server actually need?

For a vanilla server of one to four players, 4–6 GB assigned to -Xmx is comfortable. Five to eight players want around 8 GB, and heavily modded or 16-player worlds can need 12–16 GB or more. Independent hosting guides such as RedSwitches suggest starting near 6 GB and scaling up. Build 42 is hungrier than Build 41, so add a couple of gigabytes if you run the unstable branch.

Which ports does Project Zomboid use, and are they TCP or UDP?

The server uses UDP 16261 (the main game port, set as DefaultPort) and UDP 16262 (automatically DefaultPort+1, for direct connections). Both are UDP, not TCP — forwarding TCP is the most common connection mistake. RCON, if you enable it, uses TCP on port 27015 by default.

Should I run Build 41 or Build 42 for my server?

Run Build 41 (B41.78) for a stable, persistent world — it is the default branch and its multiplayer is mature. Build 42 is an opt-in unstable beta whose multiplayer only arrived in December 2025; it is exciting but can break saves and mods between updates. Start on Build 41 and experiment with Build 42 on a separate save if you want the newest content.

Where are the config and save files stored?

Configuration lives in your user profile, not the install folder: ~/Zomboid/Server/ on Linux or C:\Users\YOURNAME\Zomboid\Server\ on Windows. The default files are servertest.ini, servertest_SandboxVars.lua, and servertest_spawnregions.lua. The actual world saves live under ~/Zomboid/Saves/, which is the folder you should back up.

How do I add Steam Workshop mods to my server?

Edit servertest.ini and fill in two lines: WorkshopItems with the numeric Workshop IDs (so SteamCMD downloads them) and Mods with the string Mod IDs (so the game activates them), both semicolon-separated. Restart the server and it downloads and enables them automatically. Always copy the exact IDs from each mod’s Workshop page rather than guessing.

How do I set or reset the admin password?

On the very first launch the server prompts you to create an admin password interactively. To change it later, log in with the admin account and use the in-game password option, or use RCON to set a new one. If you lose it entirely, you can reset the admin account through the server’s user database, but the cleanest approach is simply to set a fresh password via RCON.

Can I run the server on the same PC I play on?

Yes, though it is not ideal. The dedicated server and the game client can coexist on one machine — connect to 127.0.0.1 — but they will compete for CPU and RAM, so size your -Xmx to leave plenty for the game itself. For anything beyond casual testing, a separate box or a cheap VPS gives a far smoother experience.

How do I update the server after a patch?

Stop the server, then re-run the exact same SteamCMD command from Step 2 — +app_update 380870 validate — and it pulls the newest build for your branch. Update promptly after a game patch, because clients on the new version cannot join a server still on the old one. Back up your saves before any update.

Why did my world disappear after a crash?

Almost always because the server process was force-killed while saving — a hard kill -9, a power loss, or closing the window mid-write. Project Zomboid commits world state on a clean shutdown, so always stop with the quit command or a single Ctrl+C. This is exactly why Step 11 sets up nightly, off-machine backups: with them, a corrupted world is a five-minute restore instead of a lost campaign.

Final Word and Next Steps

You now have a fully working project zomboid dedicated server: downloaded through SteamCMD, secured with an admin password and RCON, tuned for your hardware’s RAM, reachable through the correct UDP ports, loaded with Workshop mods, and kept alive around the clock by systemd with automated nightly backups. The whole build takes about half an hour, and everything above uses verified port numbers, filenames, and the correct App ID 380870 — no guesswork. Whether you keep it on rock-solid Build 41 or venture onto the Build 42 unstable branch, the fundamentals are identical, and your Knox County will be waiting whenever survivors log in.