How much server memory is needed for different player counts

Project Zomboid Server Requirements

Build 41 vs Build 42 – Small Group Hosting Guide

Last Updated: May 2025

📊 Quick Answer

Hosting a small Project Zomboid server (for 2–8 players) doesn't require a supercomputer. In general, allocate ~4–6 GB of RAM and use a mid-tier 4-core CPU to keep things smooth. A good rule of thumb is 2 GB base + 0.5 GB per player – so a 6-player server might use around 5 GB RAM. Build 42 hasn't raised hardware needs; in fact its optimizations improved multiplayer performance. Aim for at least a 10 Mbps upload connection for low-lag play.

💡

For a step-by-step setup and detailed tips, skip to the Quick-Start Guide.

🚀 Quick-Start Guide – Setting Up a Small Project Zomboid Server

If you're itching to get your Project Zomboid server running ASAP, this quick-start will guide you through the basic setup. This applies to both Build 41 (B41) and Build 42 (B42) servers. We'll assume you want a server for a small group of friends (say 2–6 players), either on your own PC or a simple dedicated machine.

1

Install the Dedicated Server files: Project Zomboid provides a separate dedicated server tool via Steam. In your Steam client, go to Library -> Tools (or just search for "Project Zomboid Dedicated Server"). Install "Project Zomboid Dedicated Server" – it's about 5 GB. (If you own PZ on Steam, you have access to this server tool for free.)
2

Launch the server for the first time: Once installed, find the server files. On Windows, you can right-click Project Zomboid Dedicated Server in Steam, go to Properties -> Local Files -> Browse. In the install folder, run the StartServer64.bat file (on Linux, you'd run the start-server.sh script in a terminal). The server will initialize – on first run it will ask you to set an admin password (this will be for the in-game "admin" user) and will generate default server settings.
3

Allow firewall access: The first time it runs, Windows may prompt you to allow the server through the firewall. Accept this so players can connect. By default, the server uses port 16261 UDP (and additional ports for each player, e.g. 16262, 16263, etc.). If you plan to host over the internet (not just LAN), you'll need to port forward 16261 UDP (and a range for extra ports, e.g. 16262–16266 UDP for a few players) on your router. (Since late B41, the server uses a secondary port for direct connections to reduce lag, so open at least 16261–16262.)
4
Configure server name and memory: After the server finishes its first-time setup, close it (type quit in the server console or close the window). Now, adjust settings. For an easy GUI method, you can configure settings through the game client:
- Launch Project Zomboid (the game, not the server). On the main menu, choose HOST -> Manage Settings. Select the server settings profile (default is "servertest" or "DefaultSettings"). Click Edit Settings.
- Under the Details tab, set a Server name (this is just a label) and maybe a description. Set a password if you want the server private.
- Importantly, set the Server memory allocation. For a small server, 2 GB is sufficient for a couple of friends. If you expect more players or lots of mods, you might increase to 4 or 6 GB. (Don't allocate more than about 80% of your system's RAM though.)
- Tweak any other settings you want (we'll cover key ones later). Save the settings. This will update the servertest.ini and sandbox files in your Zomboid server folder.
5

Start the server (and keep it running): You can now launch the server with your new settings. If you used the in-game Host interface, simply click Start to launch it from there. (This actually runs the same dedicated server in the background, with your chosen settings.) If you prefer using the standalone server app, run StartServer64.bat again – it will now load the updated servertest.ini. The console will show "Server started" when ready. Leave this console window open; closing it will shut down the server.
6

Connect to your server: On your gaming PC, launch Project Zomboid. Go to Join -> LAN (if it's the same PC or network) or Internet. If it's your own machine, the server might be listed under LAN as 127.0.0.1. Otherwise, add it as a Favorite using your public IP (for external friends) or local IP. The default port is 16261. Use the username "admin" and the admin password you set earlier to join as admin, or create a new username/password (if the server is open or you've whitelisted a user). Once in, you should be able to play co-op!
7

Share server info with friends: Give your friends the public IP and server password (if any). They will go to Join -> Internet -> Add and input your IP, port 16261, and the password. Alternatively, you can also use tools like Steam's server list or invite via Steam friends (if running as a listen server), but direct IP join is usually easiest for dedicated servers.
8

Keep the server running and monitor it: The server console (or the in-game host interface) will show logs. You'll see players connecting, server saving world occasionally, etc. To stop the server, type save (to force save world) then quit in the console, or use the in-game Host "Stop" button if that's how you launched it. Always shut down gracefully to avoid save corruption.

✅

That's it! Your basic server is up. For persistent use, you might want to run the server on a spare PC or a hosted server so it's online 24/7. Next, we'll dig deeper into hardware requirements, performance, and advanced settings – but if you just wanted the quick setup, you're ready to survive with friends. Happy zombie hunting!

🖥️ Server Hardware Requirements by Player Count

What kind of hardware do you need to host Project Zomboid? The answer depends on how many players you'll have and whether you use mods. Project Zomboid servers are more CPU-intensive than GPU (it's all CPU, no graphics on the server), and they can be memory-hungry with lots of players or mods. Here we break down typical requirements:

📊 RAM and Player Count

Memory is often the first concern. As a baseline:

Base usage: ~2 GB RAM for the server itself (even 0–2 players).
Per player: +0.4–0.5 GB RAM for each additional concurrent player (vanilla settings).

This rough formula (often cited by server hosts) suggests, for example:

2–4 players: ~3–4 GB RAM allocated (2 GB base + 0.5*players).
5–6 players: ~4.5–5 GB RAM (commonly rounded up to 6 GB).
10 players: ~7 GB (e.g. 2 + 0.5*10) – in practice many admins go with 8 GB for ~10 players to be safe.
20+ players: 10–16 GB or more (e.g. 16 GB covers ~28 players by formula; 32+ GB if heavily modded 32-player server).

💡

Tip: It's usually best not to max out your system's RAM for the server. Leave headroom for the OS. A good practice is using no more than ~80% of your RAM for the server process (especially on Windows, which needs a few GB for itself).

Mods and RAM: Mods can significantly affect memory. Many mods add new items, textures, or maps that consume RAM. A "heavily modded" server might need an extra 1–2 GB beyond the formula. For example, a 10-player server vanilla might do with ~7–8 GB, but with dozens of mods, you might allocate 10–12 GB. Warning: If you find your server using far more RAM than expected (e.g. 16+ GB for 10 players), it could indicate a memory leak or mod conflict. One experienced host noted that if mods are broken, they can consume infinite RAM ("no matter how much extra you give it, it will fill it"). In such cases, adding RAM won't fix lag – you'll need to remove or fix the problematic mod.

What if you allocate too little? If the server doesn't have enough RAM, it will start to lag (frequent slowdowns) and eventually crash when out-of-memory. It's better to allocate a bit more than needed as a buffer. Most hosting providers let you choose plans with certain RAM amounts (e.g. 4 GB, 8 GB, etc.). If in doubt, err on the higher side for modded servers or >10 players. For 5–6 players, ~6 GB ensures breathing room.

💻 CPU and World Simulation

Project Zomboid's server is CPU-bound, especially with many entities (zombies!) and players. The server runs the game world simulation: zombies AI, loot spawning, physics, etc. Build 41's multiplayer is largely single-threaded for game simulation (one core does most heavy lifting). Build 42 has seen some optimization, but it's still beneficial to have a high clock-speed CPU.

CPU guidelines:

A modern 4-core CPU (e.g. ~3+ GHz base clock) is generally sufficient for small servers. PZ will primarily use 1–2 cores heavily (one for game, one for networking).
Single-core performance matters: A fast dual-core can outperform a slow 16-core in PZ, because the game can't fully utilize many threads. For example, a host using an old 16-core Xeon at 2.2 GHz struggled when 25+ players joined, because the per-core speed was low (the server lagged when population grew).
For 2–8 players, even an older Intel i3 or i5 (or AMD equivalent) can handle it, as long as it's not a ultra-low-power variant. Build 41 MP was known to be CPU-intensive in busy areas ("The whole 41st build runs mainly on your CPU" as one dev said). So if you plan on hosting big hordes or driving across the map with friends, a CPU with good single-thread performance (e.g. 3.5+ GHz) helps prevent stutters.
Build 42 improvements: There are reports that Build 42's MP is more efficient on CPU than B41 (one user noted "Performance is way better in Build 42"). The Indie Stone devs worked on making inventory and map streaming more server-authoritative and optimized, which likely reduces CPU load in some situations. So B42 might be a bit kinder to your CPU, but don't expect miracles – zombie swarms will still chew up cycles.

TL;DR CPU:

If you're running on your own hardware, an Intel Core i5/i7 or AMD Ryzen with a decent clock (say 3.0+ GHz) is great. If using a VPS or dedicated host, look for high clock speeds. Some game hosts advertise using Ryzen 7/9 4.5GHz+ CPUs for PZ servers – that's ideal, but for a small group not strictly necessary. Just avoid very old or low-power chips (e.g. that 6th-gen i3 @ 2.3GHz might struggle with 8+ players and huge hordes).

🌐 Bandwidth and Internet Connection

Network bandwidth determines how many data the server can send/receive per second – crucial for low latency. PZ isn't extremely heavy on bandwidth per player, but it can add up with many players or if someone drives a car across the map (which streams a lot of map data to others).

Per player bandwidth: Roughly on the order of 5–10 KB/s (kilobytes) when just moving around normally, but can spike higher (20–50 KB/s) during intense moments (driving fast, big hordes). Over an hour, one player might consume tens of MB of data. For example, one host estimated ~70 GB monthly for a 20-player server, which is around ~200–300 MB per hour for all players combined (that's ~15 MB/hour per player on average). These are ballpark figures; actual usage varies.
Internet speed requirement: A safe recommendation for a small server is at least 5–10 Mbps upload speed. Download is usually less critical on the server side, but about 20 Mbps down is suggested (if the server needs to fetch workshop mods etc., but mostly upload matters for hosting). If you're hosting at home, check your ISP's upload speed – many home connections have only 5–20 Mbps up. For 4–6 players, ~10 Mbps upload will usually suffice with headroom. If you had e.g. 16 players, you'd want more like 20+ Mbps.
Latency: For best results, host the server physically near the players (e.g. if all your friends are in EU, a European server will yield much lower ping than a US server). PZ is quite playable even with 100–150ms ping, but below 100ms is ideal for smooth combat syncing. If hosting on a cloud server, choose a region close to you and your group.

📶

Networking tip:

After Build 41.78, the server can accept direct connections on a secondary port (bypassing some of Steam's relay network). This reduced latency and improved throughput significantly. Just remember to open that second port (default 16262) on your firewall. The change means less packet loss and better pings for clients (which is why Build 42 and late B41 perform better on busy servers).

💾 Storage and OS

Project Zomboid's server isn't heavy on disk: the install is ~5 GB, and savefiles (world data) can grow a few hundred MB with map exploration. Any modern HDD or SSD will do, but:

An SSD is recommended for faster chunk loading and saving, especially if multiple players are streaming different map parts. If using a VPS, it will likely be on SSD. If you host on an old laptop with an HDD, it might introduce occasional hitching when writing map data.
OS doesn't drastically affect performance. Windows vs Linux: Both can run PZ servers well. Linux might have a slight edge in using fewer resources for the OS itself. The Indie Stone runs official servers on Linux, and many communities use Linux servers. We'll cover specifics in the next section.
Ensure you have Java installed (the dedicated server comes bundled with its Java runtime, so usually you don't need to manually install anything if using the provided scripts).

📊 Summary Table – Recommended Specs

Players	RAM (vanilla)	RAM (modded)	CPU Cores & Clock	Network (Upload)
2–4	3–4 GB	~4 GB	2+ cores @ 2.5+ GHz	≥ 5 Mbps
5–8	5–6 GB	6–8 GB	4 cores @ 3+ GHz (good single-thread)	≥ 10 Mbps
10–16	8–12 GB	12–16 GB	4–6 cores @ 3.5+ GHz	≥ 20 Mbps
20–32	16 GB+	20 GB+ (watch mods)	6+ cores, high performance (e.g. 4.5 GHz turbo)	≥ 50 Mbps

(These are general recommendations; actual needs may vary with zombie count, mods, etc. Always leave some headroom.)

As you can see, for small groups the requirements are quite modest – a midrange gaming PC or a budget cloud VM (with 4–8 GB RAM) can handle it. Next, we'll look specifically at any changes Build 42 brings relative to Build 41 that might impact these requirements or setup steps.

🔄 Build 41 vs Build 42 – Changes in Server Performance and Features

Project Zomboid Build 42 is a major update that, as of 2024/2025, is moving out of unstable testing. Many players wonder how it affects servers compared to the tried-and-true Build 41. The good news is that Build 42 does not drastically increase hardware requirements; in fact, it introduces some optimizations and long-requested features that make server hosting more robust and flexible.

Here's a breakdown of relevant changes:

🚀

Multiplayer Optimization

One of the highlighted improvements in B42 is better server synchronization and reduced latency in multiplayer. The Indie Stone devs addressed several performance issues; for example, they refined how the server and client communicate inventory and actions (making more operations server-side authoritative) which helped reduce lag spikes. The result is fewer hitching and warping issues during co-op play in B42, according to patch notes and community feedback. Many hosts noticed that Build 42 feels "smoother" under load – fewer instances of players desyncing or zombies rubber-banding.

🔌

Direct Connect (from late B41)

This is technically a Build 41.78 change, but it carries into B42. As mentioned, the server now uses a second port to let clients connect directly instead of tunneling all traffic through Steam. This was introduced to fix Linux server instability and improve networking throughput. For you as a host, it means B42 servers will automatically take advantage of this. Just remember to open that extra port. The benefit is notably lower ping and capacity for more players before lag sets in, as it "circumvents the data traveling through the Steam network which was impacting latency and throughput significantly". In short, B42 inherits a much sturdier netcode from late B41.

⚙️

CPU/Threading

Build 42 doesn't magically multithread the game loop (that's a deeper engine issue likely addressed in future builds), but some background systems were improved. For example, zombie optimization and map streaming saw tweaks. There isn't an official claim like "uses multiple cores now," so the advice about single-thread performance remains. However, anecdotal reports like "performance is way better in 42" suggest that whatever code refactoring was done (possibly related to animals or crafting systems) has helped server tick rates. Bottom line: If your server was comfortable on Build 41, it should run Build 42 fine – and maybe a bit better under stress.

🧠

Memory Usage

The addition of new content in Build 42 (e.g. new crafting systems, items, animals like chickens, expanded map areas) can use a bit more memory, but it's marginal in context of a server. The biggest memory consumers – player data, chunk data, mod content – still dominate. One thing to note: B42 is not backward compatible with B41 saves/mods. That means when you switch a server from 41 to 42, you'll likely start a fresh world and also update mods. Mods not updated for 42 could cause issues (including memory leaks or crashes) until they are updated. So you might see some memory weirdness if using outdated mods on 42. Ensure your mods are up-to-date for B42, or remove those that aren't.

🐔

New Features Impacting Servers

Build 42's headline features include livestock (animals), vastly expanded crafting (metalworking, brewing, etc.), and new map regions. From a server host perspective:

Animals: These are basically NPC creatures. They will put some load on the server CPU for AI/pathfinding, but currently B42 has relatively few animal types (chickens, maybe cows, deer) and they're not as numerous as zombies. Unless you have tons of animals, the impact is minor. It's something to watch if/when NPC survivors come in later builds.
Map: A bigger map or more map objects might slightly increase RAM usage per chunk. But again, not a huge jump.
Crafting and Items: More item types could mean slightly more RAM (for item definitions, etc.) and maybe more processing if players automate things, but PZ doesn't have complex machines running in the background (beyond generators).

In testing, servers didn't need to increase RAM just because of the base B42 content. Only if players do more (tame huge animal herds, build enormous bases with new systems) could it add some load. So far, no major server hardware bump is needed for these.

🛡️

Stability

B42 had some early unstable versions that disabled multiplayer initially, but by the time it's public/stable, those issues are ironed out. The devs explicitly focused on fixing "server crashes" and instability on Linux during the B42 development cycle. So one could say B42 is more stable for servers than early B41 MP was. Fewer random crashes and better handling of things like safehouse transfers, map streaming, etc. This of course depends on mods and such, but the vanilla server is solid.

💬

Feature: Discord Integration

A neat addition around B42's time – the developers improved Discord integration for servers. Server owners in B41 often had to use mods or external scripts to get Discord webhooks for chat. With Build 42's updates (Fenris's work), you can allow Discord <-> in-game chat relay and even issue server commands via Discord for moderation. For example, server operators will be able to run certain admin actions from a Discord channel (like kicking or checking status) once configured. This doesn't affect performance much, but it's a quality-of-life feature making server management easier (especially for roleplay or event servers).

⚠️

Backwards Compatibility

One downside: Build 42 servers cannot be joined by Build 41 clients and vice versa. If you update, everyone needs to update. Also, mods/scripts made for 41 may break on 42. Be prepared to refresh your mod list. Many mod authors have posted B42-compatible versions by now (check Steam Workshop for notes like "B42 update"). On the plus side, the server config (servertest.ini) format remains largely the same, so you can carry over settings (aside from new options).

In summary, Build 42 brings welcome improvements for server hosts:

Smoother, more stable multiplayer (less lag, better sync).
New official features (animals, etc.) that enrich gameplay without demanding much more from your hardware.
Better integration tools (Discord, etc.) to manage your community.
No need to upgrade your server machine just for B42 – if you could host on B41, you can host on B42, often with even better results.

🏠 Hosting on Windows vs Linux vs Cloud Servers

You can run a Project Zomboid server on a home PC (Windows), on a Linux server (many use Ubuntu or Debian), or rent a pre-configured instance from a game server provider (or cloud like AWS, DigitalOcean). Each option has its nuances:

🪟 Windows Hosting (Home PC or Server)

Pros:

Easiest for beginners, since you can just use the Steam dedicated server or the in-game host. All GUI tools (PZServerSettings.exe, etc.) work on Windows.

Cons:

Consumes resources on your PC while playing, and Windows can be a bit heavier on RAM usage for the OS. If running headless (no monitor) it's less convenient without remote desktop.

Setup:

We covered much of it in the Quick-Start. A few Windows-specific notes:

Service/Auto-start: If you want the server to start when your PC boots (say you have a dedicated Windows machine), you can create a scheduled task or Windows Service for StartServer64.bat. There are community guides for that. Alternatively, use a tool like NSSM (Non-Sucking Service Manager) to run the .bat as a service.
Firewall: Use Windows Defender Firewall to allow java or the specific ports. If players can't connect, double-check the firewall inbound rules (should allow UDP on 16261+).
Performance: Close unnecessary programs. Windows Update or other heavy processes can cause lag spikes if they kick in while the server's running. Also, disable power-saving on a PC host (set power plan to high performance) to avoid the CPU downclocking.

Many small servers are hosted by one player on their gaming PC while they play. This is fine for ~4 players, but beyond that, consider a separate machine or dedicated server app (not the in-game host) to reduce strain on the game client. Running the server and game on the same PC is possible – PZ is not very multi-threaded, but if you have enough CPU cores (e.g. a 6-core CPU, dedicate some cores to server via affinity if needed).

🐧 Linux Hosting (Headless Server)

Pros:

Efficient resource usage, great for dedicated environments. Most rented servers run Linux. Once set up, it's very stable and you can manage it via SSH (command line). No need for a GPU or GUI.

Cons:

Initial setup is command-line based; might be intimidating if you're new to Linux. Fewer hand-holding tools (though the dedicated server is same across platforms).

Setup:

Here's a quick run-down for a headless Linux host (Build 42 or 41):

Install the server – either copy the files over from Steam (there's a SteamCMD method) or if you have a desktop Linux, use SteamCMD:
```
./steamcmd.sh +login anonymous +app_update 380870 validate +quit
```
This installs the Project Zomboid Dedicated Server (app ID 380870). If you already have the files from a Windows installation, you can also transfer them.
Launch: Run start-server.sh (for Build 41, or StartServer64.sh in B42, depending on naming). Make sure it's executable (chmod +x start-server.sh). You should run it inside a screen or tmux session so it keeps running after you log out. Example:
```
cd ~/Zomboid/Server./start-server.sh -Xms2g -Xmx4g -adminpassword YourAdminPass
```
The -Xms and -Xmx flags set the min/max RAM (2 GB and 4 GB in this example). On Linux, you often configure RAM via these Java options rather than a GUI. The first run will generate servertest.ini in /.config/Zomboid/Server (or /Zomboid/Server depending on distro).
Edit configs: Use nano or vim to edit servertest.ini for server name, ports, etc., or use the PZServerSettings tool on a Windows machine and copy the config over. (Note: There's a PZServerSettings.exe in the game directory which provides a GUI on Windows to edit server config files. You can load your servertest.ini there, tweak settings, and save, then transfer it to your Linux server.)
Ports: Open the necessary ports on your Linux firewall (ufw or similar). For example:
```
sudo ufw allow 16261:16270/udp
```
This opens UDP 16261–16270.
Run on startup (optional): You can create a systemd service file to auto-run the server on boot. Many community guides provide a template for this.

Headless management:

Without a GUI, you'll rely on the server console and commands. The console accepts the same commands (type help to see them). You can also use an RCON tool (PZ supports RCON protocol if enabled in the .ini) to send commands remotely, or use the aforementioned Discord integration for some tasks.

Linux performance:

Historically, there was a period when Linux servers had a specific bug (in 41.73) that caused crashes, but that was fixed by 41.78. Now, Linux servers are as good or better than Windows in terms of performance. One reason to consider Linux: if you have an old laptop or a Raspberry Pi 4 – these can run a small PZ server under Linux. For example, a Raspberry Pi 4 (4GB RAM) can host 2–4 players on a lightweight OS, though it might struggle with large mods or big crowds. It's a fun experiment for techies (search for "Project Zomboid server on Raspberry Pi" and you'll find some attempts).

B42 on Linux: Ensure you opt into the correct branch if using unstable (e.g. -beta unstable in SteamCMD). One note from official news: initially B42 unstable wasn't available for Linux at launch due to some last-minute issues, but by now it should be resolved. Running B42 server on Linux requires the same steps as B41, just be sure to update your files.

☁️ Cloud/VPS Hosting

If you don't want to host at home, you have two main paths:

Game server hosting providers (GPortal, Nitrado, Apex, etc.)
Cloud VPS (AWS, Azure, DigitalOcean, Linode, etc.)

Game Hosts (Managed):

These are services where you rent a Project Zomboid server slot, and they provide a web panel to configure it. This is the easiest non-technical route. The provider handles installation, updates, backups, etc. You just use their dashboard to change settings. Many have one-click mod installs or mod workshop integration. The downside is cost (usually a monthly fee based on number of player slots or memory) and sometimes less flexibility (maybe they limit certain configs or mod counts).

When picking a provider, consider:

Slots vs performance: Some sell by "slots" (players) but actually what matters is RAM and CPU. Ensure the plan has enough RAM for your mods/players. Some hosts explicitly mention "8 GB RAM, up to X players".
Location: Choose one with a server center near your player base.
Price: Ranges ~$10–15/month for a small server. There are "budget" hosts but be wary of overselling (too many servers on one machine leading to lag).
Reputation: Check recent reviews because performance can vary widely. For PZ in 2025, popular hosts include GPortal (official partner), GTXGaming, PingPerfect, and low-cost ones like ScalaCube or ZAP. Each has pros/cons. For example, GPortal is known to allocate decent RAM (their site suggests 6 GB for a 5–6 person server).

Cloud VPS (DIY):

You rent a generic virtual server and set up the game yourself (similar to the Linux steps above). For example, a DigitalOcean droplet with 4 GB RAM and 2 CPUs (~$24/mo) can run a small PZ server. AWS EC2 or Lightsail, similar idea (Lightsail $20 instance has 4GB RAM). This requires doing all the Linux setup, but gives you full control.

Make sure to account for bandwidth limits (some cloud VPS have data caps).
One advantage: you can host multiple game servers or other services on one VPS if resources allow.
If going this route, choose Ubuntu 22.04 or Debian as a straightforward OS, follow the Linux setup guide, and keep the system updated.

Windows on cloud?

It's possible (e.g. a Windows Azure VM), but Windows licensing makes it pricier. If you're not comfortable with Linux, you might try a Windows cloud VM. However, the cost for equivalent specs is higher than Linux, and you'll still need to remote in to manage it.

Network Consideration for Cloud:

Cloud VMs typically have high bandwidth and ports open by default (you control them via security groups). Latency will be mostly about physical distance. If all your friends are in one country, pick a datacenter in that region.

Admin User Accounts:

On many rented servers, you won't have a direct GUI, so you'll interact via config files or web console. Use the hosting provider's knowledgebase for specifics. Usually, you still have a servertest.ini to edit (often through a web file manager). For mods, typically you paste mod IDs in the config and the server downloads them from Steam Workshop.

💾

Important: Back Up Your Server

Backing up is important. If hosting on your PC, backup the Zomboid/Server folder (especially the Saves subfolder for your world) periodically. On a rented server, use their backup features if available. This protects your world from crashes or mod errors. Project Zomboid doesn't yet have a built-in cloud save for servers, so it's on you to copy those files.

⚙️ Server Configuration and Administration

Project Zomboid servers offer a lot of customization. This is done via a few key configuration files and commands. Here we'll go over the important settings in servertest.ini (or whichever ini corresponds to your server name), as well as admin commands you can use in-game or in-console to manage the server on the fly.

📄 Key Config Files Overview

All the server's settings are stored in the Zomboid/Server directory (under your user folder for a home server, or in the install directory for dedicated). The main ones:

servertest.ini – Main server config (the "Server Options"). This includes things like server name, description, port, player limit, PVP on/off, mods list, etc. Essentially everything in the "Details" and "Server Options" sections of the in-game host settings corresponds to lines here.
servertest_SandboxVars.lua – Sandbox settings (world difficulty options: zombie count, loot rarity, etc.). If you customized zombie behavior or day length, it's saved here in Lua table format.
servertest_spawnpoints.lua – Defines spawn regions and points for new players.
servertest_users.db – A database file containing whitelisted users and their hashed passwords, admin flags, etc. (SQLite format). There's also servertest.db which contains world save data.

For most manual editing, you'll focus on servertest.ini. Let's highlight a few important options from it:

Setting	Description
`Public=true/false`	If true, your server will appear on the public internet server list (Steam master server). Usually you set this false for a private friends server and just share IP/password.
`DefaultPort=16261`	If you want to run multiple servers from the same machine, they need unique ports (and port+1, etc.). Normally leave as 16261 for one server.
`MaxPlayers=...`	Set the max player count. Even if you have hardware for 16, you can cap this to say 8 if you only want a small group.
`UPnP=true/false`	If true, server will try to auto-configure your router (for home hosting). Sometimes this helps, sometimes not. If you manually forwarded ports, you can set false.
`Open=true/false`	If Open=false, then only whitelisted users can join (you must pre-create accounts). If true, anyone can join and they will automatically be added to whitelist on first join if they know the server password (if set).
`ServerPassword=...`	You can require a password for anyone to join. Good for privacy if you don't whitelist individual accounts.
`PVP=true/false`	Toggles friendly fire.
`PauseEmpty=true/false`	If true, the game world pauses when nobody is online. For a small co-op that might be nice (so time doesn't pass). If you want farming and such to progress 24/7, set false.
`Mods=ModID1;ModID2;...`	List of mod Workshop IDs (the string you see in workshop URL or mod info). You must list all mods here to load them.
`WorkshopItems=...`	List of Workshop file IDs corresponding to those mods. Often, ModID and Workshop ID are the same or similar, but ensure you fill this (this makes the server auto-download the mods from Steam).

Generally, using the PZ Server Settings GUI (available on Windows or via the game's Host interface) is easiest to ensure the syntax is correct. Always stop the server before editing .ini directly. After editing, start the server, and it will load the new settings.

🛠️ Admin & Host Commands

Once your server is running, you, as admin (or any player granted admin rights), can use a suite of commands to manage things. These can be entered:

In the server console (if you have access to it directly).
In the in-game chat (press T) prefixed with / (if you are an admin or the host).

Some most useful admin commands include:

/help

Lists commands in-game (it'll output a long list to you).

/save

Forces the server to save the world immediately. Useful before a shutdown or backup.

/quit

Saves and shuts down the server (same as typing quit in console).

/players

Shows a list of currently connected players.

/grantadmin "username"

Grants a normal user admin rights. (They need to relogin to gain full admin powers like ghost mode.)

/adduser "username" "password"

Adds a new user to whitelist with a password (works if your server is not open).

/banuser "username"

Bans a user (by username). Add -ip to also ban their IP and -r "reason" to specify reason.

/teleport "player1" "player2"

Teleports player1 to player2's location (if second name omitted, teleports you to player1).

/godmode "username"

Toggle god mode (invulnerability) on a player.

/servermsg "Your message here"

Broadcasts a message to all players (it appears mid-screen).

/createhorde number "username"

Spawns a horde of given size near the user (fun for events).

/weather

There are a few (like /startrain or /stoprain to control weather).

As admin, you also have the Admin Panel UI in-game (accessible via the debug icon or pressing Escape -> Admin Panel when logged in as admin). This allows using some of these commands via buttons and gives additional info (like a list of players where you can click to teleport to them, etc.). You can also enable Brush Tool to delete items or zombies, etc., if cheat/debug is enabled for admins.

🔄 Soft Reset vs Hard Reset

In the host UI, you'll see options like Soft Reset and Delete World. Soft Reset is a unique feature – it wipes all world progress (map resets to default, all loot/zombies reset) without deleting character data. This is used rarely (like if you want to start a fresh world but keep player skills). It can only be done when server is launched in a special "softreset" mode, and it's finicky – most people just hard reset (wipe everything). Use with caution.

🌐 Remote Admin

If you can't be in-game, but want to administer, consider enabling the RCON in servertest.ini (set RCONPort and password). Then you can use any generic RCON client or a tool like Rusty (for Rust, but works) or mcrcon to send commands remotely.

📋 Whitelist and Passwords

For a small group server, you'll typically either:

Set a Server Password and give it to friends, letting anyone with the password join (and maybe Open=true so they auto-whitelist).
Or use a Whitelist with accounts: set Open=false so that you manually add users. In that case, your friends will need to join with a username/password you create for them via /adduser. They can then change their password in-game via /changepwd.

Whitelist adds security and personalized login (and you can tie admin to specific accounts). But it's a bit more setup. For casual play, a simple server password is fine.

Remind your friends that their character data is tied to the username on the server. If they change username, they'll appear as a new character.

💾 Backups and World Management

It's worth mentioning how to backup or reset the world:

Backup: While server is off, copy the Saves/Multiplayer/<servertest> folder (which contains the map_p.bin files, etc.). That's your world state. Some admins backup this regularly in case of griefing or update issues.
Wipe (Hard reset): To start fresh, you can either delete the Saves/Multiplayer/servertest folder (or whatever your server name is), or simply change the ServerName in servertest.ini to something new – the server will generate a new world with that name, keeping the old world save untouched under the old name. Make sure to also clear or change servertest_users.db if you want a fresh whitelist.
Soft Reset (already covered): specialized use, not commonly needed.

📊 Monitoring Performance

As an admin, you might want to watch server performance:

Use the /debug command (if enabled) or the /performance command. Actually, PZ doesn't have a direct "show performance" command, but you can see some stats in logs.
A helpful command is /sendpulse – this toggles sending server performance info to clients. When on, clients (admins) will see a pulse/frequency of server heartbeat, which can indicate lag if pulses slow.
In the console, watch the lines – if you see "Timing issue" or "Server thread hung for X ms" warnings, that means the server is struggling (common if too little RAM or too much CPU load).
Mods like LagOMeter can be installed to measure latency and server tick by players (optional).

🧩 Mods: Which Ones to Use (and Avoid) on a Server

Mods are a big part of Project Zomboid's community experience. From quality-of-life tweaks to total overhauls, they can greatly enrich multiplayer – but they can also tax your server. Here's how to approach mods for a small server:

🔧 Mod Integration Basics

To install mods on the server, as mentioned, add them to Mods= and WorkshopItems= in the ini, or enable them via the Host interface's Mods tab (which is simpler). Clients joining will automatically download the required mods from Steam Workshop if the server is in the public list or if they have the Workshop IDs.

⚠️

Keep mods in sync:

PZ servers enforce that clients have the same mod set and versions. If a friend has an extra mod or missing mod, they'll get a "Workshop item different than server's" error. So it's best for them to subscribe to the mods from Workshop ahead of time. If not, the game will try to download it on join (if Public=true or if they join via the server browser showing the mod list).

⚖️ Lightweight vs Heavy Mods

🪶 "Lightweight" mods typically:

Change game settings or add simple items (e.g. a weapon mod, new backpacks, etc.).
Have small file sizes (tens of MB or less) and don't significantly increase memory or CPU.
Examples: Zed Removal (removes certain zombies), Quality of Life crafting mods, small map mods adding one location.

🏋️ "Heavy" mods often:

Add large maps or expansions – e.g. mods that add whole new towns or expand the map (like Grapeseed, Bedford Falls, etc.). These increase RAM usage because the map is larger and more objects.
Overhaul mods like Hydrocraft (massive crafting expansion) or Brita's Weapon Pack (tons of new guns, armor) – these introduce many new items and textures, raising memory and possibly causing more zombies (for Brita's, more loot distribution calculations).
Superb Survivors (if you attempt NPC mods in B41) – spawns NPC survivors; very CPU-heavy. (Note: with B42 bringing official animals and later NPCs, these older NPC mods may be obsolete or incompatible.)
Huge occupation or skills mods – might not be heavy in performance but need to be carefully matched with server settings.

Notorious heavy mod list (anecdotally):

Brita's Armor/Guns – loved by many, but comes with reports of lag if not configured. One server op in Reddit had Brita's on and noticed players "warp around" when close together, possibly due to the added load of those mods plus possibly latency. However, it was noted Build 42 improved that significantly.
Hydrocraft – lots of items, can slightly bloat save file and RAM, but many servers run it fine if they have enough memory.
Mass Zombie Spawns mods (like 10x zombies) – obviously more CPU for zombie AI.
Map mods – If you add many map mods, your server's map directory grows. The server loads chunks into RAM when players are around them. More locations = potentially more loaded chunks if players spread out. Having 5 different custom map areas might increase RAM usage by a few hundred MB and CPU when zombies simulate there. Use only maps you really want. Some popular ones: Raven Creek (big city, heavy on resources due to high object density), Grapeseed (moderate), Fort Redstone (small).
Pillow's Random Spawns (a mod that adds many spawn points across map) – not heavy itself, but if paired with many map mods, can cause minor slowdowns on player spawn as it places them.

On the flip side, some mods can improve server performance or management:

Zombie Cleanup mods: E.g., a mod that removes corpses or dropped loot after X days to reduce world clutter (though PZ has some built-in cleanup for corpses via server options like HoursForCorpseRemoval).
Auto-backup mods/tools: There are scripts some use to snapshot save folder every few in-game days.
Server Administration mods: Like "Mod Manager" or "Server Management" mods that add commands or GUI for admins. Use those only if needed; they shouldn't affect players.
Discord Bridge mods: If you don't want to use the new official integration or are on B41, mods like "DiscordRelay" can pipe in-game chat to a Discord channel. Lightweight but requires a bot setup.

⚙️

Ensure mod compatibility with Build 42:

Many mods have been updated to B42. But if you're on the unstable/new version, double-check. The Steam Workshop often has beta branches or separate "B42 version" of mods. Using out-of-date mods can cause weird errors or even prevent the server from starting. Read mod descriptions; many authors mention if B42 is supported.

📋 Managing Mods and Workshop

Some tips for smooth mod usage:

Use Collection: If on Steam, create a Workshop Collection with all the mods your server uses. Share that with your friends so they can subscribe easily.
Load Order: PZ doesn't usually have mod load order issues like some games, but if a mod requires another (dependency), make sure the required mod appears earlier in the Mods= list. E.g., many mods require tsarslib or xerxesframework – put those first.
Monitor Logs: If the server console throws red errors about missing items or lua errors, it could be a mod issue. Some benign errors can be ignored, but repeated red traceback likely means a mod isn't working right.
Mod Updates: When a mod updates on Workshop, the server (if it's connected to Steam) will try to update it on restart. Clients also update. This can sometimes introduce differences (if one updates and other didn't). It's good practice to schedule a server restart when you know a big mod updated, so everyone's on the same version. Running an outdated mod vs client mod will cause a version mismatch kick.
Limit adding/removing mods mid-playthrough: It's possible but be careful. Removing a mod that added items will make those items disappear (or turn into "ErrorItem"). Adding a big mod mid-game could suddenly flood loot tables or conflict with existing world data. Ideally, decide your mod list at server start and stick with it for that save. Minor additions are okay (like adding a new vehicle mod so new cars spawn).

🎮 Fun Mods for Small Groups

While on the subject, here are a few popular mods that small co-op groups enjoy (and are reasonable on performance):

Authentic Z

AuthenticPeach's mod – Adds lots of wearable items (outfits, backpacks, etc.) and some fun rare zombies. Minor impact, mostly client-side.

Better Trailers

If you like vehicles, this improves towing. Lightweight.

Skill Recovery Journal

Not performance heavy; lets players regain XP after death via a journal item.

Sleep Needed

In MP, by default you don't need to sleep. Some mods re-enable sleeping or resting requirements to increase challenge (works fine).

Nocturnal Zombies

Changes zombie behavior based on time; these just tweak AI variables, negligible cost.

Farmoid (B41)

If on B41, added animals (but now B42 has its own animals, which are more optimized). Farmoid on B41 was heavy because it simulated animals via lua.

Before installing any mod, skim the comments on Workshop to see if anyone reports server lag or memory issues. That can tip you off if a mod is problematic.

🔍 Handling Mod-related Lag

If you suspect mods are causing lag:

Try temporarily disabling one to pinpoint which is heavy.
Check memory usage (if on Windows, see Java process RAM in Task Manager; on Linux, use htop). If certain mods (like huge map) cause a big jump, consider removing one or two.
Some mods have config files (in mod folders) to tweak their intensity (e.g., Brita's has options to reduce spawn rates of guns, which can reduce item clutter).
If one mod is crucial but heavy, compensate by easing elsewhere (e.g. if you insist on 10x Zombies mod, maybe reduce max players or ensure a very strong server).

At the end of the day, moderation with mods is key for smooth performance. A curated set of 5–15 well-chosen mods can make the game way more fun and still run great. But stacking 100 mods will likely cause trouble, no matter how beefy the server.

❓ FAQ (Frequently Asked Questions)

Q How much RAM do I need for a Project Zomboid server? ▼

It depends on player count and mods. As a rule, allocate 2 GB plus about 0.5 GB for each player slot. So for a 4-player server, ~4 GB is fine; for 8 players, ~6 GB; for 10+ players, 8 GB or more. If you use big mods or maps, add an extra 1–2 GB cushion. It's better to have a little extra than to run out. Small co-op games (2–3 people) have run on even 2–3 GB, but I'd recommend 4 GB to be safe. Remember, more RAM won't necessarily boost performance after a point – it just prevents memory-related crashes. A heavily modded 10-player server can run ~10 GB usage in worst cases, but many report 5–6 GB is enough for ~5 players with several mods. Always leave some headroom for the OS (don't give all your RAM to the server).

Q Can I host a 5-player modded Project Zomboid server on my PC? ▼

Yes, if your PC meets the specs. For 5 players with mods, you'll want around 6 GB RAM allocated and a decent CPU (e.g. a quad-core 3+ GHz). Most gaming PCs from the last 5–7 years qualify. The key is uploading your internet – ensure you have at least ~10 Mbps upload speed so all players have low ping. If you're also playing the game on the same PC, make sure the CPU/GPU can handle both the server and client. Many people host for friends while playing; just lower some graphics if needed to lighten the load. Also consider using the dedicated server tool instead of the in-game host, as it can be more stable for longer sessions (you can still play on the same machine by launching the game separately). But overall, a midrange PC should handle a 5-player modded game fine. I've seen examples: one user hosted 5 friends on a low-wattage i3 mini PC – it worked, though upgrading to an i7 improved headroom. So hardware helps, but you don't need a server rack for 5 players.

Q Does Build 42 require better hardware than Build 41 for servers? ▼

No – Build 42's server requirements are roughly the same as Build 41, and some aspects are even improved. The devs optimized multiplayer in Build 42, resulting in better performance per hardware spec (e.g. less lag at high load). In other words, if your machine ran a Build 41 server adequately, it will run Build 42 as well or better. Build 42 adds new content (animals, more crafting) but those don't significantly increase CPU or RAM usage in vanilla. One caveat: Build 42 is a newer build, so ensure any mods are updated, as outdated mods can cause issues that feel like performance problems. But hardware-wise, you don't need an upgrade solely for B42. Some community members explicitly noted "performance is way better in 42" on their same server hardware, thanks to netcode and sync fixes. Just remember that Build 42 servers and Build 41 clients are incompatible – everyone needs to be on 42, and you might start a fresh world when upgrading.

Q How do I host a Project Zomboid Build 42 server on a Linux headless host? ▼

Hosting B42 on a headless Linux is very similar to B41 (or any version):

Install the server files using SteamCMD (app ID 380870) or by transferring files. For example, on Ubuntu use the SteamCMD command line to download Project Zomboid Dedicated Server.
Run the server with the provided script. For Build 42, use StartServer64.sh (or start-server.sh depending on the version). You might need to chmod +x to make it executable.
Edit servertest.ini for your desired settings (server name, password, etc.). You can generate this by running the server once or copying from a Windows setup. Make sure to configure memory (e.g., edit the .sh to include -Xmx parameter or set Memory= in the ini if applicable).
Open ports on your Linux firewall (ufw allow 16261/udp etc.). Also open 16262 if using the direct connect optimization.
Use a terminal multiplexer (like screen or tmux) so you can detach and let the server run after you log out. Example: screen -S pzserver ./StartServer64.sh.
Manage via SSH: You can enter console commands in your SSH session. Or enable RCON for remote management.

No graphical interface is needed – all config can be done via text files. B42 on Linux had a brief delay at launch (the unstable release), but as of now, it runs smoothly. Just ensure your system has the required libraries (the server uses Java – the package is included in the server files, so you shouldn't need to install Java separately, but on some distros you might need things like lib32gcc if it complains). Headless Linux is a great way to host PZ 24/7 with low overhead.

Q What can I do to reduce lag on my Project Zomboid server? ▼

Lag can come from various factors, so try these:

Allocate sufficient RAM: Ensure you're not running out of memory (watch for high usage or GC pauses). If memory is maxed, increase it if possible.
Upgrade network or adjust settings: If internet upload is the bottleneck (high ping), consider reducing Networking load – e.g., lower ZombieUpdateFreq or ClientPlayerTransmission settings via server options (advanced, but can throttle how often zombies or players update to clients). Or simply upgrade to faster internet / move server closer to players.
Reduce zombie count or complexity: Massive hordes = heavy CPU. If you're experiencing server framerate drops during huge events, consider scaling back zombie population in sandbox, or disable certain tick-heavy events (like extreme helicopter event mods).
Use the direct connect port: Make sure you and friends are connecting via the direct port introduced in late B41 (open 16262). This avoids some lag that occurs when all traffic goes through Steam relay.
Restart periodically: PZ servers (especially modded) can develop a bit of lag over long uptimes due to accumulated junk (items, zombies) or minor memory leaks. A simple daily restart (in off-hours) can clear that. Some admins automate a save and reboot early in the morning.
Enable PauseEmpty: If you have PauseEmpty=true, the server essentially freezes the world when no one's on, which can help performance when people log in (they're not catching up on 5 days of world simulation). If your server runs 24/7 with players on and off, having it pause when empty can reduce the workload.
Clean up corpses and loot: A world littered with hundreds of bodies and dropped loot can increase save size and maybe cause lag when new players enter an area. The server has settings for corpse removal (e.g. HoursForCorpseRemoval). You could shorten that so bodies vanish after, say, 12 in-game hours. There are also mods or admin commands to clear bodies in one go.
Profile mods: If lag started after adding a certain mod, try disabling that mod as a test. Some poorly optimized mods (especially ones that do heavy OnTick processing in Lua) can degrade performance. The community often points out if a particular mod causes trouble – a quick search can reveal if others had lag issues with it.
Hardware upgrade: If all else fails, you might truly be at the limit of your hardware. More CPU clock or more cores (for some background threads) on the server can help, as can faster RAM or SSD. Most small servers won't need this, but large servers (>20 players, heavy mods) benefit from high-end hardware (gaming-grade CPU on server side).

Check your server's Ping readouts and logs – if ping is high for everyone, it's network; if ping is low but things still lag, it's server tick (CPU/RAM). Also ensure your players aren't on the other side of the world which you can't fix except by relocating server.

Q Are there any specific server mods or tools you recommend? ▼

For ease of management, consider:

Server Save Manager: Not a specific mod name, but some community tools allow auto-saves and backups. For example, a script that copies the save file every hour.
Discord integration: If you run a community, the new built-in Discord integration in B42 is great. Otherwise, mods like Discord Relay for B41 did a similar job. Being able to see game chat in Discord or allow admins to issue commands from a Discord channel is a huge convenience.
Mod Manager (Harry's Mod): Some servers use this to allow players to vote mods on/off or such; mostly for public servers though.
Anti-cheat/raid mods: If it's just friends, you likely don't need this. But for public, there are mods to log PvP kills or discourage offline base raiding by NPC zombies, etc.
Performance mod (Multi-Core): There is a Workshop mod called "Multi-Core Enhancement" which attempts to tweak PZ to utilize multiple cores more effectively. It's not magic, but some have tried it on servers. It can offload some of the rendering tasks to extra threads – however, that one might mainly be client-side. On server, rendering isn't a thing, so it might not help. Still, mod exists.
Admin tools UIs: e.g., "Console++" or "Admin Toolbox" mods that give GUI for common tasks. These can be handy if you're frequently managing things in-game.

Lastly, if you are on the go, you can use PZ Server Web Map – there's a third-party tool that lets you generate a live web map of your server and see players/zombies (like a online map tool). It's advanced and requires web setup, but some small groups enjoy having a live map to coordinate (though it can be considered a bit cheaty since it reveals all).

 📜 Patch History – Build 41 to Build 42 (Server-Related Changes) Below is a brief timeline of notable changes from late Build 41 patches to Build 42 that affect server hosting and performance:
Build 41.60–41.68 (2022) – Initial public MP tests; servers required manual port forwarding (no direct connect yet), and performance issues in large servers were common (single-thread bottleneck). No direct connection – relied on Steam relay.
Build 41.73 (Aug 2022) – Update to Steam networking API caused Linux server crashes. Larger servers (esp. on Linux) experienced instability.
Build 41.74 – Attempted fixes for Linux, but introduced other issues.
Build 41.77 (Sep 2022) – Aimed primarily at fixing Linux server crashes that had been plaguing hosts. Provided interim stability.

      Build 41.78 (Oct 2022) – Major networking overhaul for MP:
      Implemented direct server-client communication using an additional port, rather than piping everything through Steam. Result: Significant improvement in ping and throughput, benefiting all servers (especially Linux). Required hosts to open an extra port (default 16262).
Fixed various MP bugs (map streaming issues, "??? player on map" bug, etc.). Last major patch of B41.
Introduced AllowCoop and other server options to disallow local splitscreen clients on dedicated servers.

    

      Early Build 42 development (2023):
      Devs focus on server-side inventory and other logic moves to server to prevent exploits and improve sync. This laid groundwork for less lag when many items are moving around.
Discord integration coding (mid-2023) for improved community management.
Multiplayer kept disabled in initial unstable testing to polish co-op features.

    

      Build 42 Unstable (late 2024):
      Multiplayer re-enabled after initial unstable period. Testing confirmed improved stability.
Added animals which are server-handled entities (but with fairly low AI complexity compared to NPCs).
Further optimized zombie netcode (reports of better performance with hordes, though still can lag if extreme counts).
Addressed memory leaks that were found during unstable testing (for example, a B42 unstable bug with high RAM usage was patched).

    

      Build 42 Stable (2025):
      By stable release, B42 is considered very solid for MP. The devs noted "noticeable improvements in server stability and synchronization" as a direct response to community feedback.
Any remaining long-term plans (like NPC survivors in future B43+) are not in yet, so B42 is the peak of B41-era MP refinement.
No increase in official "system requirements" for servers – what worked for 41 works for 42.

    
Overall, the journey from 41 to 42 saw the dev team ironing out multiplayer kinks, making life easier for server hosts (we went from frequent Linux crashes to robust cross-play). Always keep an eye on official patch notes in the Indie Stone forum for any hotfixes that might address server issues; they are quite responsive to breaking bugs.