# Project Zomboid Server Hosting - everything RE:NODE has published > A Project Zomboid server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it. Generated from https://www.renode.space/game-servers/project-zomboid, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/project-zomboid. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is Project Zomboid servers for a long apocalypse. Admin account and password are created for you. - Genres: Indie, RPG, Simulation, Early Access - Developer: The Indie Stone - Released: Nov 8, 2013 - Steam: https://store.steampowered.com/app/108600/ ### You supply two things yourself Project Zomboid is only sold with a credential its publisher issues to a person, so you need to own the game yourself and provide it after checkout. We cannot create it for you and we never share one between customers. Your server is built immediately; the game installation waits until you paste it into the Setup tab, then runs itself. ### What comes with every Project Zomboid server - Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other Project Zomboid server on the internet. - The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off. - Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine. - 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose. - 3 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them. - People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams. ### Which Project Zomboid plan do you need? Memory is what decides whether a server holds together, so start there. The Starter tier gives 3 GB and 1.5 vCPU, which suits a private group. The Advanced tier at 6 GB is where most public servers sit, and Premium at 10 GB exists for the servers that stay full. Storage matters more than people expect once mods and backups are involved - plans here run from 20 GB to 60 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have. If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players. More game servers: https://www.renode.space/ai/game-servers.md ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Where are the servers?** Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-15 22:30 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/project-zomboid or in the panel shop at https://panel.renode.space before quoting one. - You supply: Steam username - Project Zomboid server files are not downloadable anonymously, so the installer signs in as you. Use an account that owns Project Zomboid — ideally a separate one with Steam Guard set to email rather than the mobile app, or the download cannot complete unattended. (https://store.steampowered.com/about/) - You supply: Steam password - Used only by SteamCMD to download the server files. We strongly suggest a dedicated account rather than your main one. - You supply: Steam Guard code - Leave this blank the first time. If Steam does not recognise this account on this machine, it emails a short code to the account's own inbox. Come back, paste it in here, and press Start Setup again quickly — the code expires. | Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports | |---|---|---|---|---|---|---|---| | Starter | $9 | 3 GB | 1.5 vCPU | 20 GB | 1 | 2 | 3 | | Standard | $12 | 4 GB | 2 vCPU | 25 GB | 1 | 2 | 3 | | Advanced | $16 | 6 GB | 2.5 vCPU | 35 GB | 1 | 2 | 3 | | Pro | $21 | 8 GB | 3 vCPU | 50 GB | 1 | 2 | 3 | | Premium | $26 | 10 GB | 3.5 vCPU | 60 GB | 1 | 2 | 3 | ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 8 posts, newest first. Each one follows in full after the list. - [Project Zomboid server RAM: heap and plan](https://www.renode.space/blog/how-much-ram-does-a-project-zomboid-server-need) (2026-10-07): Project Zomboid server memory by players, spread and mods, how to set -Xmx so the JVM fits its container, and the sandbox settings that quietly raise the bill. - [Project Zomboid map reset that keeps players](https://www.renode.space/blog/project-zomboid-map-and-world-reset) (2026-10-07): How to reset a Project Zomboid server: full wipes, map-only resets that keep characters and accounts, partial chunk resets around safehouses, and ResetID. - [Project Zomboid SandboxVars.lua options](https://www.renode.space/blog/project-zomboid-sandbox-vars-explained) (2026-10-07): Every major Project Zomboid SandboxVars.lua option for a server: population, time, utilities, loot, world, character, vehicles, zombie lore and zombie config. - [Project Zomboid server lag: causes and fixes](https://www.renode.space/blog/project-zomboid-server-performance-and-lag) (2026-10-07): Why a Project Zomboid server lags and how to fix it: zombie population, players spreading out, the Java heap, ground items, corpses, backups and mods. - [Project Zomboid whitelist and accounts](https://www.renode.space/blog/project-zomboid-whitelist-and-accounts) (2026-10-07): How Project Zomboid server accounts work: Open=false whitelists, adding users, Steam ID binding, resetting a lost password, permadeath and Discord sign-ups. - [Project Zomboid admin commands and access](https://www.renode.space/blog/project-zomboid-admin-commands) (2026-09-21): The Project Zomboid admin account, every access level and what it can do, the full command list, bans and whitelists, safehouse settings and the logs. - [Project Zomboid server mods and load order](https://www.renode.space/blog/project-zomboid-mods-and-workshop) (2026-09-21): Installing mods on a Project Zomboid server: WorkshopItems vs Mods, finding the real mod ID, load order, map mods and spawn regions, and Build 42 folders. - [Project Zomboid server settings that matter](https://www.renode.space/blog/project-zomboid-server-settings) (2026-06-16): Which of Zomboid's hundreds of server and sandbox settings decide how a server feels: the ini, SandboxVars, zombie respawn, mods, memory and the Java heap. --- ### Project Zomboid server RAM: heap and plan Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/how-much-ram-does-a-project-zomboid-server-need A Project Zomboid dedicated server needs about 3 GB of memory for two to four players sharing one town on vanilla settings, 4 to 6 GB for eight to sixteen players spread across the map, and 8 to 10 GB for sixteen to thirty-two players with workshop mods and map mods. Because the server is a Java program, the plan is only half the answer: the Java heap, set with `-Xmx`, has to sit at roughly 70 to 80 per cent of the plan so the rest of the process fits around it. Get the plan right and the heap wrong and the server is stopped for running out of memory while Java still believes it has room. The biggest driver after that is not player count but spread - four players in four towns cost more than ten in one. #### What a Zomboid server keeps in memory The server runs the whole world for every player, and its memory is made of four things. - **Loaded map cells and chunks around each player.** The map is a grid of cells, and the server keeps the area around every connected player loaded: buildings, furniture, containers, items on the floor, vehicles and zombies in that area. Players in the same town share one loaded area. Players scattered across Muldraugh, Riverside and Louisville load three. - **Zombies.** The zombie population is tracked across the map, and zombies near players are fully simulated. Population settings set how many exist; how many are active at once follows how many areas are loaded. - **Items and vehicles.** Every item in a loaded container or on the floor, every vehicle with its parts and trunk contents. Players hoard, and a base with thirty stuffed crates and a car park of looted vehicles is a lot of objects. - **Mods.** Lua scripts, item definitions, textures for the server's own bookkeeping, and for map mods whole additional regions of cells. All of it sits in the Java heap, apart from the JVM's own overhead, which is outside it and is the reason the heap must be smaller than the plan. #### RAM by group and server type | Server | Plan memory | `-Xmx` | Notes | | --- | --- | --- | --- | | 2-4 players, vanilla, one town | 3 GB | `2g` | Comfortable | | 8-16 players, spread out | 4-6 GB | `3g` - `4g` | The common case | | 16-32 players, mods and map mods | 8-10 GB | `6g` - `7g` | Map mods are the expensive part | | Heavily modded, 100+ workshop items | 10 GB and up | `7g` - `8g` | Test the mod list before launch | Read the table by where players will be, not just how many. A small private group that all lives in one compound needs the first row even if it has eight people. A community of twelve who each claim a different town needs the third, before any mods are installed. #### Setting the Java heap correctly The server is started by a Java launcher that reads its JVM arguments from a JSON file in the server folder, `ProjectZomboid64.json` on 64-bit installs. The heap is the `-Xms` and `-Xmx` entries in its `vmArgs` list: ProjectZomboid64.json: ```json { "mainClass": "zombie/network/GameServer", "classpath": ["."], "vmArgs": [ "-Djava.awt.headless=true", "-Xms2g", "-Xmx4g" ] } ``` The real file carries more arguments than this, including garbage collector options that vary between game builds. Change only the two heap lines and leave the rest as shipped. On the Windows batch launcher the same two flags appear in `StartServer64.bat`. On a panel-based host the heap is often exposed as a Startup variable instead; if it is, use that rather than editing the file, because the panel may rewrite the file on reinstall. What the two flags mean: - **`-Xmx`** is the maximum heap. This is the number that matters. - **`-Xms`** is the starting heap. A modest starting value is fine; setting it equal to `-Xmx` makes the JVM claim everything up front, which is harmless if the maximum is correct and makes the memory graph easier to read. The rule for the maximum is the same as for any JVM server: leave room outside the heap. Metaspace for loaded classes, thread stacks, the JIT compiler's code cache and native buffers for networking all count against the container's limit and none of them is inside `-Xmx`. | Plan | Sensible `-Xmx` | Left outside the heap | | --- | --- | --- | | 3 GB | `2g` | ~1 GB | | 4 GB | `3g` | ~1 GB | | 6 GB | `4g` - `4500m` | ~1.5 GB | | 8 GB | `6g` | ~2 GB | | 10 GB | `7g` - `8g` | ~2-3 GB | > [!WARNING] > `-Xmx` equal to the plan's memory is the most common way Zomboid servers die. Java fills the heap as designed, the off-heap memory pushes the process past the container limit, and the server is stopped with no Java error at all - the log just ends. If your server restarts at busy times with nothing in the log, check this line first. #### What raises memory without new players Several sandbox and server settings change memory more than adding a player does. They live in the two files for your server name - `servertest.ini` and `servertest_SandboxVars.lua` by default, in the `Zomboid/Server` folder. ##### Zombie population `Zombies` sets the overall population preset, and the `ZombieConfig` block refines it: servertest_SandboxVars.lua: ```lua Zombies = 3, ZombieConfig = { PopulationMultiplier = 1.0, PopulationStartMultiplier = 1.0, PopulationPeakMultiplier = 1.5, PopulationPeakDay = 28, RespawnHours = 72.0, }, ``` Population scales memory and CPU directly. Note the peak: with the defaults, density rises towards one and a half times the starting level by day 28, so a server sized on day three can be short in week four for no reason anyone changed. Size for the peak. `RespawnHours` matters too - respawn refills cleared towns, so zombies never stop being a cost. Setting it to `0` disables respawn, and on many multiplayer servers that is both a gameplay improvement and a slow reduction in load. [SandboxVars explained](https://www.renode.space/blog/project-zomboid-sandbox-vars-explained) covers every option. ##### Items on the floor Players drop things. Over months, a server accumulates dropped clothing, empty cans and bags in every street people have walked down. The server ini has a cleanup for this: servertest.ini: ```ini HoursForWorldItemRemoval=24.0 WorldItemRemovalList=Base.Hat,Base.Glasses,Base.Maggots ItemRemovalListBlacklistToggle=false ``` `HoursForWorldItemRemoval` sets how many hours an item must lie on the floor before it is removed (`0` turns the cleanup off), and `WorldItemRemovalList` names which item types the rule applies to. With `ItemRemovalListBlacklistToggle=true` the list becomes the exceptions instead, so everything except the listed items is cleaned up. That is aggressive and can remove things players placed deliberately, so announce it before switching it on. Check the defaults in your own file: they have changed between builds. ##### Vehicles Every vehicle on the map is a persistent object with parts, condition and contents. `CarSpawnRate` in the sandbox settings sets how many spawn; a server that sets it high for fun ends up with car parks in every town, all loaded whenever someone is nearby. Players also collect them. A base with twenty cars is twenty sets of trunk contents. #### Mods and map mods Project Zomboid mods come from the Steam Workshop, listed by workshop ID and mod ID in the server ini. Most cost little memory: an item pack or a quality-of-life change is a handful of Lua files and definitions. Map mods are different. They add new cells to the world - new towns, new roads, sometimes whole new regions - and those cells hold buildings, containers and loot like the base map does. Two effects follow. The world is larger, so players spread further and load more areas at once. And some map mods are dense, with more containers and more items per building than vanilla towns. The third row of the sizing table is there mainly for map mods. Practical advice for a modded server: 1. **Add mods in batches and watch memory after each.** A collection of a hundred items is impossible to debug if the server suddenly needs 2 GB more. 2. **Start the server once with nobody online** after any mod change and check its idle memory. That is the new floor. 3. **Keep the mod list identical between server and clients.** Mismatches stop players joining; they do not cost memory, but they cost hours. [Project Zomboid mods and the workshop](https://www.renode.space/blog/project-zomboid-mods-and-workshop) covers the ini lines and load order. #### Proving memory is the problem Zomboid's lag has two common causes and they need different fixes. 1. **Watch the memory graph during the busiest hour.** A JVM sawtooth that climbs, drops after collection and climbs again is normal. A line pinned near the limit with small drops means the heap is too full, and the collector is working hard to free little. 2. **Compare with the heap.** If the process is near the container limit but the heap is not full, `-Xmx` is too high for the plan and the off-heap part is what is pushing it over. Lower `-Xmx`. 3. **Check CPU separately.** Zombie hordes, many vehicles and players spread across the map cost main-thread time too. Rubber-banding with memory comfortably below the limit is CPU. [CPU or RAM: which one is holding your server back](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) is the method, and [Project Zomboid performance and lag](https://www.renode.space/blog/project-zomboid-server-performance-and-lag) covers the Zomboid-specific causes. 4. **Look for a pattern in restarts.** A server that restarts at the same busy hour every evening with nothing in its log is running out of memory. A server that restarts at random with Java errors in the log is a mod or a corrupt save. On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than being left to swap. That makes an undersized heap obvious - an abrupt restart, not a slow decline - and the console's memory graph shows exactly how close each evening came. #### A worked example: twelve players outgrowing 4 GB A group of twelve starts a vanilla server on a 4 GB plan with `-Xmx3g`. For the first fortnight it is fine: most of them live in one Muldraugh compound and go on supply runs together. In week three, three players move to Riverside, two claim a farm out by Rosewood, and the evening sessions start ending in abrupt restarts with nothing in the log. Working through it in order: 1. **The restarts are memory.** Nothing in the log, at the busiest hour, and the panel graph shows the process pressing against the 4 GB line just before each one. That is the container limit, not a Java error. 2. **The heap is not the whole story.** With `-Xmx3g` the heap can only use 3 GB, so the extra pressure is off-heap memory plus a heap that is full. Raising `-Xmx` to `3500m` on the same plan would make it worse, because it takes room from the part that is already pushing the process over. 3. **The cause is spread.** Three separate areas are now loaded every evening instead of one, each with its own zombies, containers and vehicles, and the population is approaching its day-28 peak. 4. **The options.** Move to a 6 GB plan with `-Xmx4500m`, which fits the spread comfortably. Or keep 4 GB and reduce the load: lower `PopulationPeakMultiplier`, turn on item cleanup, and agree as a group to keep bases within one or two towns. Many groups do a little of both. 5. **Check after a week.** The useful number is the peak during the busiest evening session, after the population peak has passed. If it sits below about 85% of the new limit, the plan is right. The pattern is common enough to plan for. A Zomboid server that will host more than eight people should be sized for the week the group spreads out, not the week it arrives. #### Disk and the save folder Memory is what fails; disk is what grows. The save for a multiplayer world lives in `Zomboid/Saves/Multiplayer//`, and it holds one `map_X_Y.bin` file for every map chunk anyone has visited, plus player and vehicle data. A server that has run for a year with a well-travelled map is measured in gigabytes and hundreds of thousands of small files. Backups of it take longer as it grows, and restoring one is slower than people expect. [Project Zomboid map and world reset](https://www.renode.space/blog/project-zomboid-map-and-world-reset) covers resetting parts of the map without wiping players, which is also the honest way to shrink an old save. Project Zomboid plans on RE:NODE start at 3 GB and go up to 10 GB, from $9 a month, with three port allocations. The install needs a Steam login, entered on the Setup tab, and moving up a tier raises the limit on the server you already have without rebuilding it. #### FAQ ##### Is 4 GB enough for a Project Zomboid server? For up to about eight players who mostly play in the same area, on vanilla or lightly modded settings, yes, with `-Xmx` at about `3g`. Twelve players spread across several towns, or any map mods, want 6 GB or more. ##### What should I set -Xmx to? Seventy to eighty per cent of the plan's memory. That leaves room for the JVM's off-heap memory, which the container also counts. On a 4 GB plan, `-Xmx3g`; on 8 GB, `-Xmx6g`. Never set it to the whole plan. ##### Why does my Zomboid server use more RAM in week four? Most likely the default population peak: with `PopulationPeakMultiplier` at `1.5` and `PopulationPeakDay` at `28`, the zombie count rises over the first month. Players spreading out and accumulating items and vehicles add to it. Size for the peak, not the first week. ##### Do map mods use a lot of RAM? More than most mods. They add cells to the world, so players spread further and the server loads more areas at once, and dense map mods carry more containers and items per building. A server with several map mods belongs in the 8 GB and up range. ##### Does restarting the server help? It returns the JVM to a clean heap and is worth doing on a schedule, typically once a day. It does not remove items, vehicles or zombies, because they are saved in the world. If memory is pinned at the limit within an hour of a restart, the server needs a larger plan or a lighter world. Project Zomboid servers on RE:NODE run from 3 GB to 10 GB with three port allocations and backup slots on every tier. The console graphs memory against the plan's limit, so you can check that your heap setting leaves room, and changing tier raises the limit on the server you already have. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid map reset that keeps players Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-map-and-world-reset Resetting a Project Zomboid server comes in three sizes, and the save folder decides which you get. Deleting `Zomboid/Saves/Multiplayer//` wipes the world and every character, but leaves accounts, the whitelist and bans, which live in `Zomboid/db/.db`. Deleting only the map chunk files inside that folder - and keeping `players.db` - resets the world while characters keep their skills and inventory. Deleting only the chunks outside the areas you want to protect is a partial reset: the towns refill with loot and zombies, the bases stay. Whichever you choose, stop the server cleanly first, back up the whole `Zomboid` folder, and raise `ResetID` in the ini when the world itself is new. This guide covers what each file in the save is, the three kinds of reset and how to do each one, the settings that force a reset when you change them, and how to run a server so you need resets less often. The wider settings file is covered in [Project Zomboid server settings](https://www.renode.space/blog/project-zomboid-server-settings). #### What lives where Everything a dedicated server knows sits under its `Zomboid` folder, and every file is named after the server name passed with `-servername` (default `servertest`): ```text Zomboid/ Server/ servertest.ini server options, mods, ResetID servertest_SandboxVars.lua world rules servertest_spawnregions.lua where new characters appear db/ servertest.db accounts, whitelist, access levels, bans Saves/Multiplayer/servertest/ the world as played map__.bin one file per explored chunk players.db characters: skills, inventory, position vehicles.db vehicles in the world map_meta.bin safehouses, factions and other world metadata map_t.bin the world clock map_sand.bin the sandbox options this world was created with backups/ the server's own zipped backups ``` The exact set of files in the save folder varies between builds, and you will see more than are listed here - per-cell zombie population files and various tables. What matters is the three categories: | What | Where | Survives a world wipe? | | --- | --- | --- | | Accounts, passwords, access levels, whitelist, bans | `db/.db` | Yes, unless you delete it | | Characters | `players.db` in the save folder | Only if you keep that file | | The world: buildings, loot, zombies, player constructions | Chunk files in the save folder | No | | Server and sandbox settings | `Server/` | Yes | This is a Build 41 multiplayer layout, where characters are stored on the server. Build 42 changed the map's internal geometry and the save format, and the developers have said Build 41 saves will not carry over to it - so moving a server between the two is a fresh start whatever you keep. ```diagram title: What each kind of reset removes db = servertest.db | accounts and bans players = players.db | characters chunks = Chunk files | the explored world full = Full wipe mapreset = Map reset partial = Partial reset full -> players : deletes full -> chunks : deletes mapreset -> chunks : deletes all partial -> chunks : deletes some ``` #### Before any reset Every reset starts the same way. Do these in order, every time. 1. **Announce it.** Give a date and say which kind of reset it is. "Map reset, characters kept" and "full wipe" produce very different reactions, and players who were told plan accordingly. 2. **Stop the server cleanly.** `/quit` from the console, or the panel's Stop. A clean stop writes the world out. A killed process leaves the last minutes unsaved and can leave a chunk half-written, which you will then carefully preserve in a backup. 3. **Back up the entire `Zomboid` folder.** Not just the save. Settings, the database and the save together are the only copy that restores to exactly what you had. 4. **Keep that backup somewhere other than the server's disk.** Zomboid's own zipped backups in `Zomboid/backups/` sit beside the thing they protect. On RE:NODE, backups are stored off the machine and can be locked against rotation, which is what you want for the last snapshot of a season. > [!WARNING] > Never delete or move files in the save folder while the server is running. The server holds chunks in memory and writes them out as players move and when it saves, so a file you deleted reappears and files you kept are overwritten with a mix of old and new state. #### Full wipe: new world, new characters The full wipe is the simplest and the most common at the end of a season. 1. Stop the server and take the backup. 2. Delete `Zomboid/Saves/Multiplayer//`. 3. Open `.ini` and increase `ResetID` by one. 4. Change any sandbox options you want for the new season (see below - some only take effect on a new world anyway). 5. Start the server. The world generates as players explore, starting from the spawn regions. servertest.ini: ```ini ResetID=485729113 ``` The value is just a number. What matters is that it changes. Clients remember things about the servers they have joined, and a new `ResetID` tells them the world they knew is gone, which avoids odd behaviour from stale cached data when they reconnect. Accounts survive, because they live in the database. Everybody logs in with the same username and password, the whitelist still applies, bans still apply, and moderators keep their access level. If you also want a fresh roster - a new community, or a server that was open and is becoming private - delete `db/.db` as well. That removes every account including `admin`, so have the admin password to hand for the next start; on RE:NODE the admin password is generated per server and shown with its other credentials. #### Map reset: new world, same characters A map reset gives you a fresh, fully looted world with every zombie back, while players keep their characters - skills, traits, recipes they have learned and whatever they are carrying. It suits a long-running server where the map has been stripped bare but nobody wants to lose two months of carpentry levels. 1. Stop the server and take the backup. 2. In the save folder, keep `players.db`. Decide about `vehicles.db` (below). 3. Delete everything else in the save folder. 4. Start the server. Characters load with their position from the old world, which means some will log in standing where a building used to have a second floor, or inside a building that is now locked and full of zombies. Two ways to handle that: - Tell players to log in at a time when friends are around, and accept a little chaos as part of the reset. - Before the reset, ask everyone to move to an open area - a field, a road - and log out there. Their bases are gone, of course, along with every item stored in them. Only what a character carries survives. A popular courtesy is to announce the reset a week ahead so people can pack a bag with the things they care about. `vehicles.db` holds every vehicle in the world. Keeping it while deleting the chunks under those vehicles is not a combination the game is designed for. Unless you have a specific reason, delete it with the map and let vehicles spawn fresh. `map_meta.bin` holds safehouse claims. On a map reset the buildings they refer to are reset too, so delete it; otherwise players hold claims to buildings full of new zombies and loot, which is confusing at best. #### Partial reset: refill the towns, keep the bases A partial reset is the one most long-running servers end up wanting. Looted towns come back with loot and zombies, while player bases and the areas around them stay exactly as they are. It works because the world is stored in chunk files, one per explored chunk, named by chunk coordinates. Delete a chunk file and the server regenerates that piece of map from the original map data the next time somebody comes near: fresh loot, fresh zombies, doors closed, windows intact. Keep a chunk file and that piece of the world is unchanged. In Build 41 a chunk is 10 by 10 tiles, so the file `map_1180_1020.bin` covers tiles x 11800-11809, y 10200-10209. To protect a base: 1. Get the base's tile coordinates. An admin can read them in game; community web maps of the vanilla world show coordinates too. 2. Work out the range of chunk coordinates covering the base plus a margin of a few chunks, by dividing tile coordinates by 10. 3. Stop the server and back up. 4. Delete every `map__.bin` outside the protected ranges. Keep `players.db`, `vehicles.db` and `map_meta.bin`. 5. Start the server and visit a reset town and a protected base to check both. Doing this by hand for more than two or three bases is error-prone. Most admins write a small script, or use one of the community tools built for this, that reads a list of protected rectangles - often taken from the safehouse list - and deletes everything else. Whatever does the deleting, run it on a copy first and look at the result. > [!TIP] > Protect a generous margin around each base. Players' farms, rain collectors, car parks and the fence they built across the road all sit outside the building itself, and a reset that removes the half of a base outside the walls feels worse than no reset at all. Two caveats. Vehicles parked inside a reset area can behave oddly once their chunk has been regenerated; ask players to bring vehicles home first. And the chunk size and file naming changed in Build 42, so a script written for Build 41 coordinates is wrong on a Build 42 server - check the files on your build before trusting any arithmetic, including this guide's. #### Settings that need a new world Not every sandbox option applies to an existing world. The world stores the sandbox settings it was created with, which is what `map_sand.bin` is, and several options act once, at creation, or are tied to time since the world began: - **Start date and time** - `StartYear`, `StartMonth`, `StartDay`, `StartTime`. - **Utility shut-off** - `WaterShut` and `ElecShut` work from the world's start, so changing them later does not restart the countdown. - **Map choices** - `Map` order and map mods, which decide the geography chunks are generated from. - **Spawn regions** - which towns new characters can start in. Other options, such as zombie population and respawn, loot rarity and XP multipliers, can usually be changed on an existing world through the in-game admin panel's sandbox options or by editing the Lua file and restarting. The full option list is in [Project Zomboid SandboxVars explained](https://www.renode.space/blog/project-zomboid-sandbox-vars-explained). Map mods deserve their own rule. Adding a map mod to an existing world is fine; the new area generates when someone first walks into it. Removing one, or reordering `Map` so a different map wins in an explored area, leaves chunks that reference map data the server no longer has. That is a reset, at least of the affected area. [Project Zomboid server mods](https://www.renode.space/blog/project-zomboid-mods-and-workshop) covers the `Map` line and load order. #### The soft reset option, and why to be careful with it Build 41 has a start-up option, `-Dsoftreset`, that runs a server-side reset of world objects while keeping characters. It is the kind of feature that appears in old forum threads and patch notes rather than in documentation, and its exact behaviour - what it clears, what it keeps, and whether it suits a modded world - has varied. If you want to try it, copy the server first, run it on the copy, and look at the result before going near the real one. For most servers the file-based resets above are more predictable, because you can see exactly what you removed. #### Needing fewer resets Resets exist because the map runs out: loot is taken, zombies are cleared, the world goes quiet. Several sandbox options slow that down so a server lasts longer between them. | Option | Effect | | --- | --- | | `LootRespawn` | Containers refill on a schedule. Off by default | | `SeenHoursPreventLootRespawn` | Containers players looked into recently do not refill | | `ConstructionPreventsLootRespawn` | Areas with player construction do not refill, protecting bases | | `ZombieConfig.RespawnHours` | Zombies return to cells nobody has seen for a while | | `ZombieConfig.RespawnMultiplier` | How many come back | Loot respawn with construction protection is effectively a slow, automatic partial reset. It suits public servers where players come and go. For a friends' server that likes the feeling of a world being used up, it removes something, and a reset every few months is the better rhythm. #### Troubleshooting **Players lost their characters after a map reset.** `players.db` was deleted, or the server was started with a different `-servername` and loaded a different save folder. **Characters were kept but bases from the old world came back.** The server was running when files were deleted, and wrote its in-memory chunks back out. Stop it first, and repeat. **Some players cannot join after a full wipe.** They have stale client data for the old world. Make sure `ResetID` was changed, and have them restart the game. **Everyone had to register again.** `db/.db` was deleted along with the save. Restore it from the backup if you did not mean to. **A protected base lost its garden and fence.** The margin was too small. Restore those chunk files from the backup; it is one of the reasons to take it. **The world will not load after a map mod change.** A map mod was removed from a world that had explored its area. Put it back, or reset the affected chunks. **The server would not start with new sandbox settings.** A typo in the Lua file. The console shows the line. Compare against the file the server generated, or restore the previous one. #### FAQ ##### Does a wipe delete player accounts? No. Accounts, passwords, access levels, the whitelist and bans live in `Zomboid/db/.db`, not in the save. Deleting the save leaves them alone. Delete the database as well only if you want everyone to register again. ##### Can players keep their skills through a map reset? Yes, on Build 41 multiplayer. Characters are stored in `players.db` in the save folder. Keep that file, delete the rest of the save, and characters return with skills and carried items into a fresh world. ##### What does ResetID do? It identifies the world to clients. Changing it tells them the world they remember no longer exists, which avoids stale-data problems after a wipe. Increase it whenever you create a new world. ##### How do I reset only the looted towns? Delete the chunk files outside protected areas around player bases, keeping `players.db`, `vehicles.db` and `map_meta.bin`. Chunks regenerate from the original map when visited. Use a script or tool, test it on a copy, and leave wide margins. ##### Do I need to reset to change sandbox settings? Only for options tied to the world's creation, such as the start date, utility shut-off timing, the map list and spawn regions. Most other options - zombie population, respawn, loot, XP - can be changed on an existing world. ##### Can I move a Build 41 world to Build 42? No. The save format and map geometry changed, and Build 41 worlds do not load on Build 42. Moving a server between them is a new world, and you should plan it as a season change. Project Zomboid servers on RE:NODE start at 3 GB with three port allocations and an admin password generated per server. Backups are stored off the machine, restore with a button and can be locked so the last snapshot of a season survives rotation; SFTP and the file manager handle the save folder. The install takes your Steam login on the Setup tab - use a spare account. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid SandboxVars.lua options Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-sandbox-vars-explained `_SandboxVars.lua` holds the rules of a Project Zomboid world: how many zombies, how fast they move, how rare loot is, when the water and power go off, how long a day lasts and how quickly characters learn. It is a Lua table in `Zomboid/Server/`, read when the server starts. Most options are numbered positions on a scale rather than real quantities, and the scale is written in a comment above each line in the file the server generates - which makes that generated file the best documentation you have. The safest way to build one is to choose the settings in the game's own sandbox screen, host once from the client, and copy the resulting file to the server. This guide goes through the file section by section: what each option does, what its values mean on Build 41, which ones a multiplayer server should actually think about, and which only take effect on a new world. For the server ini - ports, PvP, safehouses, mods - see [Project Zomboid server settings](https://www.renode.space/blog/project-zomboid-server-settings). #### How the file works servertest_SandboxVars.lua: ```lua SandboxVars = { VERSION = 5, -- Changing this also sets the "Population Multiplier" in Advanced Zombie Options. -- Default=Normal 1 = Insane 2 = Very High 3 = High 4 = Normal 5 = Low 6 = None Zombies = 4, Distribution = 1, DayLength = 3, StartMonth = 7, StartDay = 9, StartTime = 2, WaterShut = 2, ElecShut = 2, ZombieLore = { Speed = 2, }, ZombieConfig = { PopulationMultiplier = 1.0, }, } ``` Three rules make editing it painless. **Every value has a comment above it.** The generated file explains each scale, including which number is the default. Keep the comments. When a guide (including this one) and the comment disagree, the comment matches your build and wins. **The structure matters.** It is a Lua table: options separated by commas, nested tables for `ZombieLore` and `ZombieConfig`, braces that must balance. A missing comma or brace stops the server from reading the file. The console shows the line where parsing failed. **Files are read at start.** Edit with the server stopped, then start it. Changes made through the in-game admin panel's sandbox options apply to the running world and are saved into it, which means the world and the file can disagree - and the world wins. If you use the panel, write the same change into the file so the next person reading it is not misled. [Project Zomboid admin commands](https://www.renode.space/blog/project-zomboid-admin-commands) covers the panel. > [!NOTE] > This guide describes Build 41, which most multiplayer servers have run. Build 42 renamed some options, turned several stepped scales into finer multipliers and added new sections, including options for animals. On a Build 42 server, read the generated file rather than copying any Build 41 example into it. #### Population, time and the start | Option | Values | What it does | | --- | --- | --- | | `Zombies` | `1` Insane to `6` None, `4` Normal | Overall count. Also sets `PopulationMultiplier` | | `Distribution` | `1` Urban focused, `2` Uniform | Whether zombies concentrate in towns | | `DayLength` | Steps; `3` is one hour | Real time per in-game day | | `StartYear` | `1` and up | Year of the apocalypse, cosmetic | | `StartMonth` | `1`-`12`, default `7` | Starting month. Affects season and weather | | `StartDay` | `1`-`31`, default `9` | Starting day | | `StartTime` | `1` 7 AM, `2` 9 AM, and later steps | Starting hour | `Zombies` runs from most to fewest, which surprises everyone once: `1` is Insane, not "one". It is a preset that sets `PopulationMultiplier`; if you also set the multiplier directly, the explicit value is what the server uses, so set one or the other deliberately. `DayLength` is the most consequential setting on the server for how the game feels. At the default of one real hour per day, a two-hour session is two in-game days. Farming, healing, skill books and food spoiling all run on game time, so shorter days make the world move faster around players who are not online. For an evening group, one or two hours per day is the usual range. Very short days punish anybody who logs in less than the others. `StartMonth` decides the season. The default July start gives a long summer to prepare for winter; starting in autumn or winter is a deliberate difficulty choice, because crops do not grow and cold arrives early. #### Utilities: water and electricity | Option | Values | What it does | | --- | --- | --- | | `WaterShut` | `1` Instant, `2` 0-30 days, longer ranges above | When the water goes off | | `ElecShut` | Same scale | When the power goes off | | `WaterShutModifier` | Days | The exact day chosen for water shut-off | | `ElecShutModifier` | Days | The exact day chosen for power shut-off | The scale options choose a range; the modifier holds the actual day picked within it. On a server this is fixed when the world is created and counted from day one, so changing `WaterShut` on a running world does not restart the clock. Water and power going off are major milestones in a Zomboid world - fridges stop, taps run dry, the generator hunt begins - so this is a setting to agree on before the server opens. #### Loot and loot respawn | Option | Values | What it does | | --- | --- | --- | | `FoodLoot`, `CannedFoodLoot` | Rarity scale | Fresh and canned food | | `LiteratureLoot` | Rarity scale | Skill books and magazines | | `SurvivalGearsLoot`, `MedicalLoot` | Rarity scale | Camping gear, medicine | | `WeaponLoot`, `RangedWeaponLoot`, `AmmoLoot` | Rarity scale | Melee, guns, ammunition | | `MechanicsLoot`, `OtherLoot` | Rarity scale | Car parts, everything else | | `LootRespawn` | `1` None, `2` Every day, `3` Every week, `4` Every month, `5` Every two months | Whether containers refill | | `SeenHoursPreventLootRespawn` | Hours, `0` off | Recently seen containers do not refill | | `MaxItemsForLootRespawn` | Number | A container holding more than this does not refill | | `ConstructionPreventsLootRespawn` | `true` / `false` | Areas near player construction do not refill | The rarity scale in most Build 41 releases runs from Extremely Rare to Abundant in five steps, and later releases added steps at the rare end. The comment shows which you have. Split loot by category rather than moving everything together. A survival server that wants food to matter and guns to be rare but ammunition findable is three settings, not one. Literature is worth a thought of its own: skill books are the fastest progression in the game, and their rarity sets how quickly the group outgrows early challenges. Loot respawn changes the long game more than any rarity setting. With `LootRespawn` at `1`, the map is finite: what the group takes is gone, and after a few months the server needs a reset - covered in [Project Zomboid server reset](https://www.renode.space/blog/project-zomboid-map-and-world-reset). With weekly or monthly respawn plus `ConstructionPreventsLootRespawn`, towns slowly refill while bases are left alone, which suits a public server where players come and go. #### The world: weather, nature and events | Option | Values | What it does | | --- | --- | --- | | `Temperature` | `1` Very cold to `5` Very hot | Climate | | `Rain` | `1` Very dry to `5` Very rainy | Rainfall | | `ErosionSpeed` | `1` Very fast to `5` Very slow | How fast nature reclaims the town | | `ErosionDays` | Days | Starting erosion, as if time had passed | | `Farming` | `1` Very fast to `5` Very slow | Crop growth speed | | `NatureAbundance` | `1` Very poor to `5` Very abundant | Foraging and fishing | | `PlantResilience`, `PlantAbundance` | Scales | Crop disease and yield | | `Alarm` | `1` Never to `6` Very often | House alarms | | `LockedHouses` | `1` Never to `6` Very often | Locked doors on houses | | `FoodRotSpeed`, `FridgeFactor` | Scales | Spoiling, and how much a fridge slows it | | `GeneratorSpawning` | Scale | How often generators are found | | `GeneratorFuelConsumption` | Multiplier | Fuel burned per hour | | `Helicopter` | `1` Never, `2` Once, `3` Sometimes, `4` Often | The helicopter event that draws hordes | | `MetaEvent` | `1` Never, `2` Sometimes, `3` Often | Distant gunshots and similar events | | `NightDarkness` | `1` Pitch black to `4` Bright | How dark nights are | | `FireSpread` | `true` / `false` | Whether fire spreads | `Helicopter` deserves care on a multiplayer server. The event pulls large numbers of zombies along its path, and on a server where players are spread across the map, it can flatten one player's preparations while another sees nothing. Some groups switch it off for that reason; others consider it the best part of the first week. `Alarm` and `LockedHouses` shape early play more than they seem to. Frequent alarms punish careless looting with a horde; frequent locked houses push players towards tools and windows. `FireSpread` on a public server is a griefing question. With it on, one Molotov can burn down a street of player bases. Decide with your safehouse rules in mind. #### Characters and progression | Option | Values | What it does | | --- | --- | --- | | `XpMultiplier` | Number, `1.0` default | Multiplies skill experience | | `XpMultiplierAffectsPassive` | `true` / `false` | Whether it also speeds Fitness and Strength | | `StatsDecrease` | `1` Very fast to `5` Very slow | Hunger, thirst and fatigue rate | | `Nutrition` | `true` / `false` | Weight and nutrition simulation | | `StarterKit` | `true` / `false` | Spawn with basic items | | `CharacterFreePoints` | Number, `0` default | Extra trait points at creation | | `ConstructionBonusPoints` | Scale | Health of player-built structures | | `InjurySeverity` | `1` Low, `2` Normal, `3` High | How bad injuries are | | `BoneFracture` | `true` / `false` | Whether bones can break | | `ClothingDegradation` | Scale | How fast clothing wears | `XpMultiplier` is the most-changed option in this section, and the most often overdone. Doubling it makes a server that plays a few evenings a week feel fair; multiplying it by ten turns the early game into a formality and leaves players with nothing to work towards after a fortnight. Remember that `DayLength` already affects progression, because reading and many actions take game time. `CharacterFreePoints` is a softer alternative to raising XP. A few extra points let people take a positive trait or two without strong negative ones, which helps new players without changing the long game. #### Vehicles | Option | Values | What it does | | --- | --- | --- | | `EnableVehicles` | `true` / `false` | Vehicles at all | | `CarSpawnRate` | `1` None to `5` High | How many cars exist | | `ChanceHasGas` | `1` Low, `2` Normal, `3` High | Fuel in found cars | | `InitialGas` | Scale | How full their tanks are | | `FuelStationGas` | Scale | Fuel in pumps | | `LockedCar` | `1` Never to `6` Very often | Locked vehicles | | `CarGeneralCondition` | Scale | State of spawned cars | | `TrafficJam` | `true` / `false` | Wrecks blocking main roads | | `CarAlarm` | `1` Never to `6` Very often | Alarms on cars | | `PlayerDamageFromCrash` | `true` / `false` | Whether crashes hurt the driver | | `SirenShutoffHours` | Hours | When emergency sirens stop | Vehicles cost performance on a server, because driving loads chunks quickly. `CarSpawnRate` and the vehicle speed limit in the ini both matter; the performance side is covered in [Project Zomboid server lag](https://www.renode.space/blog/project-zomboid-server-performance-and-lag). #### Zombie lore `ZombieLore` is a nested table, and it defines what a zombie is. | Option | Values | Default | | --- | --- | --- | | `Speed` | `1` Sprinters, `2` Fast shamblers, `3` Shamblers, `4` Random | `2` | | `Strength` | `1` Superhuman, `2` Normal, `3` Weak, `4` Random | `2` | | `Toughness` | `1` Tough, `2` Normal, `3` Fragile, `4` Random | `2` | | `Transmission` | `1` Blood and saliva, `2` Saliva only, `3` Everyone's infected, `4` None | `1` | | `Mortality` | `1` Instant to `7` Never | `5`, 2-3 days | | `Reanimate` | `1` Instant to `6` 1-2 weeks | `3`, 0-1 minutes | | `Cognition` | `1` Navigate and use doors, `2` Navigate, `3` Basic navigation, `4` Random | `3` | | `Memory` | `1` Long, `2` Normal, `3` Short, `4` None, `5` Random | `2` | | `Sight`, `Hearing` | `1` Eagle / Pinpoint, `2` Normal, `3` Poor, `4` Random | `2` | | `ThumpNoChasing` | `true` / `false` | Idle zombies attack doors and walls | | `ThumpOnConstruction` | `true` / `false` | Zombies damage player-built structures | | `ActiveOnly` | `1` Both, `2` Night, `3` Day | When zombies are more active | `Speed` is the headline. Sprinters on a multiplayer server are a novelty mode; they also look worse under latency, because fast movement exaggerates every bit of desync. `Random` mixes speeds and is a popular compromise. `Transmission` and `Mortality` together decide whether a bite is a death sentence. Vanilla is blood and saliva with death in two to three days, which makes every melee fight a real risk. `Transmission = 4` removes infection entirely, which some groups prefer for a building-focused server. `Cognition = 1` gives zombies the ability to open doors. It changes how players secure bases and is worth announcing. `ThumpOnConstruction` off makes player bases safe from zombies, which turns the game into a builder. Leaving it on keeps walls meaningful. #### Zombie config: population over time | Option | Default | What it does | | --- | --- | --- | | `PopulationMultiplier` | `1.0` | Overall density | | `PopulationStartMultiplier` | `1.0` | Density on day one | | `PopulationPeakMultiplier` | `1.5` | Density at the peak | | `PopulationPeakDay` | `28` | Day the peak is reached | | `RespawnHours` | `72.0` | Hours before a cell can repopulate. `0` disables | | `RespawnUnseenHours` | `16.0` | Hours a cell must go unseen first | | `RespawnMultiplier` | `0.1` | Share of the original population that returns | | `RedistributeHours` | `12.0` | How often zombies migrate between cells | | `FollowSoundDistance` | `100` | How far zombies follow a sound | | `RallyGroupSize` | `20` | Size of migrating groups | Population starts at the start multiplier and rises to the peak by the peak day. A server that seems fine in week one gets harder and heavier through week four by design. `RespawnHours = 0` is the most common change on multiplayer servers. Without it, areas players cleared slowly refill, which on a server with several players who each cleared their own streets feels like running in place. With it off, the map is a resource the group works through. The cost is that the world gets quieter over months, which is what loot respawn or a scheduled reset are for. #### Removal timers | Option | Default | What it does | | --- | --- | --- | | `HoursForCorpseRemoval` | `216.0` | Game hours before corpses vanish | | `HoursForWorldItemRemoval` | `24.0` | Game hours before listed floor items vanish | | `WorldItemRemovalList` | A short list | Which items the timer applies to | | `ItemRemovalListBlacklistToggle` | `false` | `true` means everything except the list | | `DaysForRottenFoodRemoval` | `-1` | Days before rotten food vanishes. `-1` never | These matter for performance on a long-running server more than for gameplay. Corpses left for nine in-game days pile up outside bases after a fight. #### Three worked examples Settings make more sense as a set than one at a time. These are three common server styles and the choices that define them. **The friends' server.** Four to six people, a couple of evenings a week. Keep vanilla zombie lore so the game still feels like Zomboid, but set `RespawnHours = 0` so the streets people clear stay cleared. Raise `XpMultiplier` to about 2 so the group sees progress between sessions, and choose a two-hour `DayLength` so an evening covers a day or so of game time rather than three. Put water and power on the 0-30 day range so the first real milestone arrives in the second or third week of play. Leave loot respawn off and plan a reset when the map runs dry. Pair it with `PauseEmpty=true` in the ini so the world waits for you. **The public survival server.** Twenty or more players who come and go. Here the world must keep producing for newcomers, so loot respawn on a weekly or monthly cycle with `ConstructionPreventsLootRespawn = true` matters more than any rarity setting, and a low `RespawnMultiplier` keeps towns dangerous without refilling them completely. Keep `XpMultiplier` near 1 so long-term players have something to work towards. Turn `FireSpread` off unless your rules can handle arson, and think hard before enabling the helicopter event, which will hit some players and not others. Shorten `HoursForCorpseRemoval` for performance. **The hardcore server.** For groups who want the game to be cruel. `Speed = 4` for a random mix that includes sprinters, `Cognition = 1` so doors are not safety, shorter utility shut-off, `Rain` and `Temperature` pushed towards the extremes, and an autumn `StartMonth` so winter arrives before the group is ready. Keep `XpMultiplier` at 1 and `CharacterFreePoints` at 0. It is worth telling people before they join, because a hardcore server that is not announced as one mostly produces complaints. None of these is right for every group. What they show is that a server's character comes from a handful of choices made together, and that changing one option in isolation - doubling XP, turning on sprinters - often shifts the balance of the others more than expected. Change a few things, play a week, and adjust. #### Building the file and applying it The reliable workflow: 1. In the game client, choose Host, then the sandbox settings, and set everything you want. Save it as a preset if you will reuse it. 2. Start the hosted game once and quit. The client writes `servertest_SandboxVars.lua` - named after the server name you used when hosting - into `Zomboid/Server/` on your PC. 3. Stop the dedicated server. 4. Upload the file to the server's `Zomboid/Server/` folder, renamed to match the server's `-servername` if needed. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers the transfer. 5. Start the server and check a few values in the in-game admin panel. Options tied to the world's creation - start date, utility shut-off timing - only fully take effect on a new world. Everything else applies to the existing world from the next start. #### Troubleshooting **The server ignores my sandbox file.** It is named for a different server name, or it is in the install folder instead of `Zomboid/Server/`. **The server fails to start after an edit.** A Lua syntax error, usually a missing comma. The console names the line. **A setting reverted after restart.** It was changed in the admin panel and saved into the world, or the world kept a value from creation. Set it in both places. **Zombies are far more numerous than expected.** `Zombies` runs backwards: `1` is Insane. Check `PopulationMultiplier` too. **Changing water and power shut-off did nothing.** They are counted from the world's start. On an existing world, the original timing stands. #### FAQ ##### Where is the SandboxVars file on a server? In `Zomboid/Server/_SandboxVars.lua`, beside the ini of the same name. The server name comes from `-servername`, and `servertest` is the default. ##### Can I change sandbox settings without a restart? Through the in-game admin panel, yes, and the change is saved into the world. Edits to the file itself need a restart, and a few options tied to world creation only apply to a new world. ##### What are good settings for a group of friends? A common starting point is vanilla zombies with `Speed = 2`, `RespawnHours = 0`, `XpMultiplier` between 1.5 and 3, `DayLength` of one or two hours, and loot respawn off. Then adjust after the first week. ##### Why do my values not match a guide I copied from? Builds differ. Several scales gained extra steps during Build 41, and Build 42 changed many options. Use the comment above each line in your own generated file. ##### Does XpMultiplier affect fitness and strength? Only if `XpMultiplierAffectsPassive` is `true`. By default the passive skills level at their normal, slow rate. ##### Do sandbox settings affect server performance? Several do: zombie population and respawn, car spawn rate, and the corpse and item removal timers. [Project Zomboid server lag](https://www.renode.space/blog/project-zomboid-server-performance-and-lag) covers which ones matter. Project Zomboid servers on RE:NODE start at 3 GB with an in-browser editor with syntax highlighting, which makes a missing comma easier to spot, plus SFTP for uploading a client-made sandbox file, an admin password generated per server and backup slots on every tier. The install takes your Steam login on the Setup tab - use a spare account. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid server lag: causes and fixes Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-server-performance-and-lag A Project Zomboid server lags for one of five reasons, and they are easy to tell apart once you know where to look. Too many zombies alive in loaded areas. Players spread across the map so the server keeps several regions awake at once. A Java heap that is too small, so the server spends its time collecting garbage - or too large for the plan, so the container is stopped at its memory limit. Thousands of items and corpses that nobody cleans up. Or something periodic: a world save, a zipped backup of a big save folder, or a mod doing heavy Lua work on a timer. "Lag" that only some players see, while others are fine, is usually not the server at all. This guide covers how a Zomboid server spends its time, how to find which of the five you have, and the settings that fix each one. The general settings file is covered in [Project Zomboid server settings](https://www.renode.space/blog/project-zomboid-server-settings), and the sandbox options are explained one by one in [Project Zomboid SandboxVars explained](https://www.renode.space/blog/project-zomboid-sandbox-vars-explained). #### How a Zomboid server spends its time Zomboid's world is made of cells, and cells are made of chunks. The server keeps loaded the chunks around every connected player, and everything inside them is live: zombies, corpses, items on the floor, fires, vehicles, generators, crops. Outside those areas, the world is stored and mostly asleep, apart from coarse bookkeeping such as zombie migration. Two consequences shape everything else. **Spread costs more than count.** Ten players in one town load one area. Four players in four towns load four areas, each with its own zombies and objects. This is why player count is a poor predictor of Zomboid load in both directions, and why the same server can be fine on Saturday and miserable on Sunday with the same people online. **Clients do some of the work.** In Build 41 multiplayer, much of the movement of zombies near a player is computed on that player's machine and synchronised through the server. That keeps the server lighter, but it means a player on a weak PC or a poor connection can make the zombies near them stutter and teleport for everyone standing nearby, while the server's own load looks fine. The server is a Java process and its main simulation leans on one thread, so a fast core matters more than many slow ones. A second core still helps, because saving, networking and garbage collection happen alongside. #### Finding which problem you have Before changing settings, spend an evening watching. On a panel host you have three useful sources: the memory and CPU graphs against your limits, the live console, and `Zomboid/server-console.txt`, which holds the full output of the current run. | Symptom | Likely cause | Where to look | | --- | --- | --- | | Everyone lags at once, all the time | CPU at its limit | CPU graph pinned near the plan's share | | Everyone lags at once, every few minutes | Saves, backups or a timed mod | Lag lines up with save or backup messages | | Stutters getting worse over days, gone after restart | Heap pressure or accumulation | Memory graph climbing steadily | | Server restarts suddenly, no error | Memory limit reached | Memory graph at the limit just before | | Zombies teleport near one player only | That player's PC or connection | Ask who is nearby; check their ping | | Lag when players spread out | Too many loaded areas | Correlate with where people are | | Lag in one place, such as a base | Items, corpses or a complex build there | Visit and look | The console also shows `java.lang.OutOfMemoryError` if the heap itself runs out, which is a different failure from the container limit and points at `-Xmx` being too small for the world. A distinction worth holding on to: lag that everybody sees at the same moment is the server. Lag that one player sees, or that follows one player around, is a client or a connection. [Latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) is the quickest way to tell a player which of those they have. #### The Java heap: the setting most servers get wrong The server's memory is set in `ProjectZomboid64.json` in the server install, not in the ini: ProjectZomboid64.json: ```json { "mainClass": "zombie/network/GameServer", "classpath": ["."], "vmArgs": [ "-Djava.awt.headless=true", "-Xms3g", "-Xmx6g", "-XX:+UseZGC" ] } ``` The real file has more arguments than this; change only the `-Xms` and `-Xmx` values and leave the rest. Recent Build 41 releases ship with the ZGC garbage collector already selected, which keeps pauses short; if your file has a different collector, leave it as shipped unless you know why you are changing it. Two ways to get the heap wrong: **Too small.** The heap fills, the garbage collector runs constantly to make room, and the server spends its time cleaning instead of simulating. You see regular stutters that get worse as the world grows, and eventually an `OutOfMemoryError`. **Too large for the plan.** The heap is not the whole process. Thread stacks, the JVM's own structures and native memory sit outside it, and the container limit counts everything. Set `-Xmx` equal to the plan and the process outgrows its container while Java still believes it has room. On RE:NODE the container is then stopped and restarted clean rather than allowed to swap, so you see an abrupt restart with no error in the log - and an unsaved one. | Plan memory | Sensible `-Xmx` | Typical server | | --- | --- | --- | | 3 GB | `2g` | 2-4 players, vanilla, one area | | 4 GB | `3g` | Small group, a few mods | | 6 GB | `4g` - `5g` | 8-16 players, spread out | | 8 GB | `6g` | 16-32 players, mods and map mods | | 10 GB | `7g` - `8g` | Large modded public server | Seventy to eighty per cent of the limit is the rule. If a server at that ratio still hits the limit, it needs a bigger plan rather than a bigger heap. [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) covers telling which resource is short before you pay for either. #### Zombie population Zombies inside loaded areas are the single biggest simulation cost, and population is controlled in the sandbox file: servertest_SandboxVars.lua: ```lua SandboxVars = { Zombies = 4, ZombieConfig = { PopulationMultiplier = 1.0, PopulationStartMultiplier = 1.0, PopulationPeakMultiplier = 1.5, PopulationPeakDay = 28, RespawnHours = 72.0, RespawnMultiplier = 0.1, RedistributeHours = 12.0, FollowSoundDistance = 100, RallyGroupSize = 20, }, } ``` `PopulationMultiplier` scales everything. `PopulationPeakMultiplier` and `PopulationPeakDay` mean population rises over the first weeks, so a server that runs well on day 3 can struggle on day 28 without any setting changing. If you see a gradual slowdown over the first month that restarts do not fix, check where you are against the peak day. Reducing load without making the game feel empty: - **Lower the peak, not the start.** A `PopulationPeakMultiplier` of `1.2` instead of `1.5` keeps the opening tension and takes the edge off the later weeks. - **Turn respawn down or off.** Respawn refills cleared areas, which keeps the number of zombies in loaded areas high for the whole life of the server. `RespawnHours = 0` stops it entirely. - **Smaller rally groups.** `RallyGroupSize` controls how many zombies group together when they migrate. Very large hordes converging on a base are a spike the server feels. Raising population on a busy server is the most reliable way to make it lag. If the group wants more danger, zombie speed and toughness in `ZombieLore` are cheaper than numbers. Later Build 41 ini files also include `ZombieUpdateMaxHighPriority`, `ZombieUpdateDelta`, `ZombieUpdateRadiusLowPriority` and `ZombieUpdateRadiusHighPriority`, which control how often and how far zombie state is synchronised to clients. They trade smoothness for bandwidth and CPU. Leave them at the values your server generated unless you have measured a problem they would fix and you change one at a time. #### Players, vehicles and spread Since spread is the cost, a few settings reduce how much world each player drags into memory. | Key | File | What it does | | --- | --- | --- | | `SpeedLimit` | ini | Maximum vehicle speed in multiplayer. Fast driving loads new chunks quickly | | `CarEngineAttractionModifier` | ini | How far engine noise draws zombies | | `MaxPlayers` | ini | Slots. Fewer people spread less | | `PauseEmpty` | ini | Stops the world when nobody is on | `SpeedLimit` exists largely because of chunk streaming. A player driving at full speed crosses chunks faster than the server comfortably loads them, which shows as stutter for the driver and load for everyone. The default is a deliberate compromise; raising it makes cross-map driving worse. The other lever is social rather than technical: servers built around a shared town or a few nearby bases run lighter than servers where every player claims a corner of the map. On a public server that is not yours to dictate. On a friends' server, it is worth knowing. #### Items, corpses and accumulation Everything on the floor of a loaded area is part of the simulation and has to be saved. A long-running server accumulates: the corpses from a week of fighting outside a base, the clothes and junk people drop, the furniture they dismantle. | Setting | File | Default | What it does | | --- | --- | --- | --- | | `HoursForCorpseRemoval` | sandbox | `216.0` | Game hours before corpses disappear. `0` keeps them | | `HoursForWorldItemRemoval` | sandbox | `24.0` | Game hours before listed floor items are removed | | `WorldItemRemovalList` | sandbox | a short list | Item types the removal applies to | | `ItemRemovalListBlacklistToggle` | sandbox | `false` | `true` turns the list into "everything except these" | | `ItemNumbersLimitPerContainer` | ini | `0` | Caps items per container. `0` is unlimited | | `BloodSplatLifespanDays` | ini | `0` | Days before blood decals fade. `0` keeps them | The defaults keep corpses for nine in-game days and remove only a few item types from floors. On a busy server, corpses are the bigger problem: a base that has fought off a horde can have hundreds lying outside it. Lowering `HoursForCorpseRemoval` to something like `72` helps more than most settings in this guide, at the cost of a little atmosphere. `WorldItemRemovalList` with `ItemRemovalListBlacklistToggle` set to `true` removes every floor item except the ones you list, which cleans up aggressively. It also removes things players dropped deliberately, so announce it. `ItemNumbersLimitPerContainer` exists for the hoarder who puts four thousand nails in one crate. A container with a huge item list is expensive every time someone opens it or the chunk is saved. #### Saves, backups and periodic stutter A stutter at regular intervals is almost always the server writing to disk. servertest.ini: ```ini SaveWorldEveryMinutes=15 BackupsPeriod=0 BackupsOnStart=true BackupsCount=5 ``` `SaveWorldEveryMinutes` writes the world on a timer; `0` leaves saving to the server's own rhythm and shutdowns. A short interval on a large world means a short stall often. `BackupsPeriod` is worse on a big server: it zips the entire save folder every so many minutes, and on a world measured in gigabytes that is a long, heavy job running while people play. Leave it at `0`, keep `BackupsOnStart=true`, and take real backups at a quiet hour with a restart. On RE:NODE the Schedules tab can do exactly that: a console command warning players, a delay, `/save`, a restart, then a backup, at an hour when nobody is on. Backups taken that way are stored off the machine, which Zomboid's own zips are not. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers picking the hour. #### Mods Mods are where performance problems hide on a modded server. Zomboid mods are Lua, and Lua code that runs every tick, every minute or on every player action adds up across a long mod list. Map mods add their own cost: more cells with more objects, often more detailed than vanilla. What helps: - **Remove mods nobody uses.** A long list collected over months usually contains several. - **Suspect anything that runs on a timer**: weather systems, spawners, NPC frameworks, economy mods that scan containers. - **Bisect.** If a modded server lags and vanilla does not, remove half the mods on a copy of the server, test, and repeat. It is slow and it is the only method that gives an answer. - **Read the console after updates.** A mod that throws errors repeatedly is slower than one that works, and errors scroll past in their hundreds. [Project Zomboid server mods](https://www.renode.space/blog/project-zomboid-mods-and-workshop) covers load order and the workshop, and [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) the general hygiene. #### Restarts A daily or twice-daily restart is normal practice for Zomboid servers, and for good reason: memory use and accumulated objects grow over uptime, and a restart puts the server back to a clean start. Pick an hour when the fewest people are on, warn them in chat beforehand, and save before stopping. A restart costs a minute or two; a server that has been up for a week and is collecting garbage every few seconds costs everyone's evening. > [!NOTE] > A restart is not a fix for a heap that is too small or a population that is too high. If a fresh server lags within an hour, look at the settings above. Restarts manage slow accumulation; they do not repair a wrong setting. #### Troubleshooting **The server restarts suddenly with nothing in the log.** It reached the plan's memory limit. Lower `-Xmx` to about three quarters of the plan, and if that leaves too little heap, move up a plan. **Stutter every few minutes, like clockwork.** Saving or zipped backups. Check `SaveWorldEveryMinutes` and set `BackupsPeriod=0`. **Zombies teleport around one player.** That player's connection or PC. Their client is computing zombie movement near them. Check their ping and frame rate. **The server was fine for a month, then slowed.** Population peaking (`PopulationPeakDay`), corpses and items accumulating, or the save growing. Look at each in turn. **A base is laggy for everyone who visits.** Corpses outside it, overfilled containers, or a very complex build. Clean the corpses and check `ItemNumbersLimitPerContainer`. **Lag started after adding a mod.** Remove it on a copy and test. If that fixes it, look for an alternative or a configuration option in the mod that reduces its work. **Players are kicked for high ping.** `PingLimit` in the ini is the threshold. Raising it lets distant players stay, and they will still lag the zombies around them. #### FAQ ##### How much RAM does a Project Zomboid server need? Three gigabytes for a small group in one area, 4-6 GB for eight to sixteen players spread out, and 8-10 GB for a large modded server. Set `-Xmx` to about three quarters of the plan, never all of it. ##### Why does the server lag when we split up? Each player keeps the area around them loaded and simulated. Players in four towns means four areas of zombies, items and objects live at once. The same people together in one town cost far less. ##### Does more CPU fix Zomboid lag? Only if the CPU graph shows the server at its share. Many Zomboid lag complaints are memory, accumulation or one player's connection, none of which more CPU changes. ##### Should I lower the zombie population? If the server struggles with zombies in loaded areas, lowering the peak multiplier or turning off respawn helps more than lowering the start population. Zombie speed and toughness add difficulty without adding load. ##### Are corpses really a performance problem? On busy servers, yes. Each corpse is an object in the world that is simulated while loaded and saved with its chunk. Hundreds outside a base add up. Lowering `HoursForCorpseRemoval` is one of the most effective changes available. ##### Does PauseEmpty help performance? It stops the world when nobody is online, which saves CPU during empty hours and stops things decaying. It does nothing while people are playing. Project Zomboid servers on RE:NODE run from 3 to 10 GB, with memory and CPU graphs against your limits in the console and a Schedules tab that can warn, save, restart and back up in order. CPU is a hard share of what you bought, and moving up a plan changes the limit on the server you already have, so the world stays where it is. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid whitelist and accounts Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-whitelist-and-accounts A Project Zomboid server has accounts, not just players. Each person joins with a username and a password of their own, and the server keeps those accounts in a SQLite database at `Zomboid/db/.db`. Whether strangers can create an account is decided by one line in the ini: `Open=true` lets anyone register on first join; `Open=false` makes the server whitelist-only, so only accounts you created - or that already existed - get in. To close a server cleanly, have your regulars join once, run `/addalltowhitelist`, set `Open=false` and restart. To add someone afterwards, run `/adduser "name" "password"` and hand them the password. This guide covers how accounts and the whitelist work, every setting involved, adding and removing people, resetting a forgotten password, the Steam ID binding that stops account sharing, permadeath whitelists, and running sign-ups through Discord. The admin account and the command list in general are covered in [Project Zomboid admin commands](https://www.renode.space/blog/project-zomboid-admin-commands). #### Two passwords, and why both exist New admins mix these up more than anything else on a Zomboid server. - **The server password** is `Password=` in `.ini`. Everybody types the same one in the connect screen. It keeps out people who only found your address, and nothing else. - **The account password** belongs to one account. It is set when the account is created - by the player on first join if the server is open, or by you with `/adduser` if it is not - and it proves that the person logging in as "Bob" is Bob. A server can use either or both. A server password with `Open=true` means anyone who knows the shared password can make an account. `Open=false` without a server password means only listed accounts can join, and the server password adds nothing. Both together is belt and braces, and mainly useful while you are changing from one model to the other. #### Where accounts live ```text Zomboid/ Server/servertest.ini Open, Password and the other keys below db/servertest.db accounts: usernames, password hashes, access levels, bans Saves/Multiplayer/servertest/ players.db characters ``` The database holds the account; the save holds the character. That split has three useful consequences: - **Wiping the world does not wipe accounts.** Delete the save and everybody logs in with the same name and password to a fresh world. [Project Zomboid server reset](https://www.renode.space/blog/project-zomboid-map-and-world-reset) goes through the kinds of wipe. - **Deleting the database removes every account**, including `admin`, every access level and every ban. Do it only when you mean to start the roster from scratch. - **Copying the database moves your roster.** To set up a second server or move to a new host with the same people, copy `db/.db` across, renamed for the new server name. Nobody has to register again. Back the database up with the save. Losing it does not lose the world, but it does mean re-creating accounts and re-applying every ban from memory. #### The ini keys that control access | Key | Default | What it does | | --- | --- | --- | | `Open` | `true` | `false` makes the server whitelist-only | | `Password` | empty | Shared server password at connect | | `AutoCreateUserInWhiteList` | `false` | With `Open=true`, new accounts are added to the whitelist as they register | | `DropOffWhiteListAfterDeath` | `false` | Remove an account from the whitelist when its character dies | | `MaxAccountsPerUser` | `0` | Accounts allowed per Steam account. `0` is unlimited | | `MaxPlayers` | `32` | Slots | | `ServerWelcomeMessage` | a default | Shown on join; a good place for rules and a Discord link | | `DisplayUserName` | `true` | Show account names above players | | `ShowFirstAndLastName` | `false` | Show character names instead or as well | Defaults vary slightly by build, and the generated ini comments each key. A few of these deserve more than a line. `AutoCreateUserInWhiteList` is for the transition from open to closed. Run the server open for a launch weekend with it on, and everyone who registered is already on the whitelist when you switch `Open` to `false`. `MaxAccountsPerUser` matters on Steam servers. Accounts are tied to the Steam ID that created them, so a limit of `1` or `2` stops one person registering a stack of alternate accounts to dodge a ban or to hoard. On a friends' server it does not matter; on a public one, set it. `DropOffWhiteListAfterDeath` is the permadeath switch, covered below. #### Closing a server that is already running The common situation: the server ran open for a while, there is a group of regulars, and it is time to stop strangers. 1. Ask everyone who should keep access to log in once, so their account exists. 2. As admin, run `/addalltowhitelist`. It adds every account the server knows about. 3. Stop the server. 4. Set `Open=false` in the ini. 5. Start the server, and try to join with a new name to confirm it is refused. servertest.ini: ```ini Open=false Password= AutoCreateUserInWhiteList=false MaxAccountsPerUser=1 ``` `/addalltowhitelist` adds everybody, including the stranger who made an account last night. Look through the account list in the in-game admin panel afterwards and remove anyone who should not be there. `Open` is also one of the options `/changeoption` can set on a running server, followed by `/reloadoptions`. That is convenient, but write it into the ini as well, so a restart does not quietly reopen the server. #### Adding, removing and banning The commands, run in the console or in chat as an admin: ```text /adduser "Bob" "temporary-password-42" /addusertowhitelist "Bob" /removeuserfromwhitelist "Bob" /addalltowhitelist /banuser "Bob" -ip -r "griefing the Muldraugh bakery" /unbanuser "Bob" /banid "76561198012345678" /unbanid "76561198012345678" /setaccesslevel "Bob" "moderator" ``` | Command | What it does | | --- | --- | | `/adduser` | Create an account with a password you choose | | `/addusertowhitelist` | Whitelist an account that already exists | | `/removeuserfromwhitelist` | Remove an account's whitelist entry | | `/addalltowhitelist` | Whitelist every existing account | | `/banuser` | Ban an account; `-ip` also bans the address | | `/banid` | Ban a Steam ID, which stops new accounts from the same Steam account | | `/setaccesslevel` | Give an account a staff level, or `none` to remove it | Names are account names, not character names, and the quotes matter when a name has a space. On a whitelist server, `/adduser` is how people get in: create the account, then send them the name and password privately. Tell them to change the password, which a player can do in chat with `/changepwd "old" "new"` on builds that include it; `/help` lists the commands your build has. Banning an account on an open server is easy to evade - the player registers a new name. A ban on the Steam ID is the one that sticks. The Steam ID is in the server's connection logs for every login, which is also how you find it after the fact. [Server rules, moderation and staff](https://www.renode.space/blog/server-rules-moderation-and-staff) covers writing bans down and handling appeals. #### Steam ID binding and shared accounts On a Steam server, an account is bound to the Steam account that first used it. Someone who knows Bob's username and password still cannot log in as Bob from a different Steam account. That is a quiet, useful protection: shared passwords do not lead to shared characters, and a leaked password is less of a disaster than it sounds. It also explains two support questions. A player who buys the game on a new Steam account cannot use their old Zomboid account without an admin removing it and creating a new one. And brothers sharing a PC with two Steam accounts need two Zomboid accounts. Servers started with the `-nosteam` option run without Steam, for players on non-Steam copies of the game. There is no Steam ID to bind to, so the account password is the only protection and `/banid` has nothing to act on. Use a server password and a whitelist on any non-Steam server that faces the internet. #### Resetting a forgotten password There is no "forgot password" link. Three ways to fix it, from easiest to most manual. 1. **The admin panel.** Logged in as admin, the in-game panel has a database view listing accounts, where an admin can change an account's details. This is the quickest route on builds that offer it. 2. **Remove and re-create.** `/removeuserfromwhitelist "Bob"`, then `/adduser "Bob" "new-password"`. If the server refuses because the name still exists, delete the row directly as in the third method. On Build 41 multiplayer the character is stored separately in the save, linked by account name, so re-creating the same name gets Bob back to his character. Try it on a test account first if your server is modded. 3. **The database directly.** With the server stopped, the account table can be edited with any SQLite tool. Back up the file first. ```bash $ cp Zomboid/db/servertest.db Zomboid/db/servertest.db.bak $ sqlite3 Zomboid/db/servertest.db ".schema whitelist" $ sqlite3 Zomboid/db/servertest.db "SELECT id, username FROM whitelist;" $ sqlite3 Zomboid/db/servertest.db "DELETE FROM whitelist WHERE username = 'Bob';" ``` The table holding accounts is called `whitelist` even on open servers, which surprises people. Read the schema before changing anything; column names have changed between builds, and passwords are stored hashed, so you cannot simply type a new one into the table. Deleting the row and re-creating the account with `/adduser` is the safe use of direct access. > [!WARNING] > Never edit the database while the server is running. The server holds it open and writes to it, and a file changed underneath it can be corrupted or silently overwritten. Stop, back up, edit, start. #### Permadeath whitelists `DropOffWhiteListAfterDeath=true` removes an account from the whitelist when its character dies. Combined with `Open=false`, a death means the player is locked out until an admin lets them back in. Some roleplay and hardcore servers use this to make death matter: every return goes through a staff member, who might require a new character application, a waiting period, or simply a conversation about how it happened. It works best with a clear written policy - how long the wait is, what a new application needs - because otherwise every death becomes a negotiation. It also makes staff availability part of the game: a death at 3am with no staff awake is a locked-out player until morning. Decide whether that is acceptable before switching it on. #### Sign-ups through Discord Most communities that run whitelists take applications in Discord. The pattern that works: 1. An applications channel, with the questions in a pinned message: name, age if your rules need it, timezone, how they found the server, and agreement to the rules. 2. A staff member reviews it and, if approved, runs `/adduser` with a generated password. 3. The password goes to the applicant by direct message, never in a public channel, with an instruction to change it. 4. The applicant gets a Discord role, so staff can see at a glance who is whitelisted. This keeps the whitelist meaningful without much effort. The weakness is the manual step: someone has to run the command. Giving moderators the access level to do it, rather than sharing the admin password, is the right fix - see [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege) for the general reasoning. Project Zomboid also has a built-in Discord chat bridge, configured in the ini: | Key | What it does | | --- | --- | | `DiscordEnable` | Turns the bridge on | | `DiscordToken` | The bot token, from Discord's developer portal | | `DiscordChannel` | The channel name to bridge | | `DiscordChannelID` | The channel's numeric ID | It relays chat between the game and a Discord channel. It does not manage the whitelist or create accounts, and the token is a credential: keep the ini out of screenshots, and if the token ever leaks, regenerate it in the developer portal. Bots that handle applications automatically exist as separate projects; [Discord webhooks for server status](https://www.renode.space/blog/discord-webhooks-for-server-status) covers the lighter-weight ways to connect a server and a community. #### Troubleshooting **New players are refused after closing the server.** That is the whitelist working. Add them with `/adduser`. **A whitelisted player cannot join.** Check the account name, not the character name. Then check they are using the Steam account the Zomboid account was created with. **The server reopened after a restart.** `Open` was changed with `/changeoption` but not in the ini file. Set it in the file. **Everyone had to register again.** The database was deleted or replaced, or the server is running with a different `-servername` and a different database. Restore the file from backup. **A banned player keeps coming back.** They are making new accounts. Ban the Steam ID with `/banid`, and set `MaxAccountsPerUser`. **A player died and cannot rejoin.** `DropOffWhiteListAfterDeath=true`. Re-add them with `/addusertowhitelist` if your rules allow it. #### FAQ ##### How do I make a Project Zomboid server whitelist-only? Set `Open=false` in the ini and restart. Only accounts that already exist can join. Run `/addalltowhitelist` first if people have been registering while it was open, and add new people with `/adduser`. ##### Where are Project Zomboid accounts stored? In the SQLite database at `Zomboid/db/.db`, in a table named `whitelist`. Characters are stored separately in the world save, which is why a world wipe does not remove accounts. ##### Can a player reset their own password? On builds that include it, `/changepwd` in chat changes a player's own password if they know the current one. A forgotten password needs an admin. ##### Do I need a server password if the server is whitelisted? No. `Open=false` already restricts who can join. A server password adds a second barrier, which is useful while moving from an open server to a closed one. ##### Why can my friend not log in on my account from his PC? Accounts on Steam servers are bound to the Steam account that created them. That is a protection against shared and stolen passwords. Make your friend his own account. ##### Can I move my player list to a new server? Yes. Copy `Zomboid/db/.db` to the new server, renamed to match its server name if that differs. Accounts, access levels and bans come with it. Project Zomboid servers on RE:NODE start at 3 GB, with an admin password generated per server, a console with command history for `/adduser` and friends, SFTP for copying the account database between servers, and backup slots that cover the database along with the world. Panel subusers can be given console access without billing, so moderators never need your login. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid admin commands and access Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-admin-commands Project Zomboid has no RCON. Administration happens in two places: the server console, and the in-game chat box of a character logged in on an account with an access level. The account is called `admin` by default, its password is set at first start, and everything else - kicks, bans, whitelists, item spawns, weather, safehouse disputes - runs through about forty slash commands and one in-game panel. That is the whole model, and it has two consequences worth knowing before you hand anyone a password. There is no remote admin protocol to secure or to leave exposed, which is one fewer thing to get wrong. But there is also no way to run a command without being connected to the server or standing at its console, and no built-in way to give somebody the ability to kick without also giving them a character with powers. This guide covers the account, the five access levels, the command reference, bans and whitelisting, the safehouse system that causes most of the arguments, and the logs you will need when somebody says it was not them. #### Setting up the admin account The first time a dedicated server starts it asks for an administrator password on the console and will not continue until it has one: ```text Enter new administrator password: Confirm the password: ``` The username is `admin`. Hosts that start the server for you pass the credentials as launch arguments instead (`-adminusername` and `-adminpassword`), which is why a panel-installed server never shows that prompt. On RE:NODE the admin password is generated per server at install rather than shipped as a default, and is shown with the server's other generated credentials. To use it, connect to your own server and log in with `admin` and that password rather than creating a character the normal way. The account exists already, so a wrong password is rejected rather than silently creating a second account. Two things to get right straight away: - **Change the password if it was ever typed into a chat window.** `/changeoption` cannot do this; stop the server and set it in the launch arguments or the panel's Startup tab. - **Do not play on the admin account.** Admin powers attach to the character, so it is easy to leave invisibility or god mode on and then wonder why nothing can hurt you. Keep a normal character for playing and log in as `admin` only to do something. Promote other people rather than sharing the password: ```text /setaccesslevel "Bob" "moderator" /grantadmin "Alice" /removeadmin "Alice" ``` The name is the account name, not the character's in-game name, and the quotes are required when it contains a space. Promotions take effect the next time that player connects. #### The five access levels Below `admin` there are four named levels, and a player with none of them is an ordinary survivor: | Level | Roughly what it is for | | --- | --- | | `admin` | Everything, including server options and handing out access levels | | `moderator` | Moderation: kick, ban, teleport, most of the admin panel | | `overseer` | Watching and managing players without full moderation | | `gm` | Game master: spawning items and creatures, weather, events | | `observer` | The read-only level: see players, follow them, no changes | The uncomfortable part is that the exact split has never been documented precisely by the developers and has moved slightly between builds. Treat the table as the intent rather than the specification, and before you hand `gm` to someone, log in on a test account at that level and try the two or three things you care about. The same caution applies to guides listing which command needs which level: check on your own server, on your own build. The general principle is the one from [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege): the person who runs your event nights needs `gm`, not `admin`, and the person who handles arguments at 2am needs `moderator`, not both. #### Command reference Commands are typed into the in-game chat with a leading `/`, or into the server console. Arguments containing spaces go in double quotes. The server confirms each command in the console, which is the quickest way to tell a typo from a permissions problem. Players and moderation: | Command | What it does | | --- | --- | | `/players` | Lists connected players | | `/kick "user" -r "reason"` | Disconnects a player, reason shown to them | | `/banuser "user" -r "reason"` | Bans the account, add `-ip` to ban the address too | | `/unbanuser "user"` | Lifts an account ban | | `/banid ` | Bans a Steam ID, which survives a new account | | `/unbanid ` | Lifts a Steam ID ban | | `/adduser "user" "password"` | Creates an account on a closed server | | `/addusertowhitelist "user"` | Adds an existing account to the whitelist | | `/removeuserfromwhitelist "user"` | Removes it again | | `/addalltowhitelist` | Whitelists everyone currently connected | | `/setaccesslevel "user" "level"` | Sets one of the five levels | | `/voiceban "user" -true` | Mutes voice chat for that player | Players and the world: | Command | What it does | | --- | --- | | `/additem "user" "Base.Axe" 1` | Gives an item by its module and type | | `/addvehicle "Base.CarNormal" "user"` | Spawns a vehicle by script name at a player | | `/addxp "user" Woodwork=200` | Adds experience in one perk | | `/godmod "user" -true` | Invulnerability, note the spelling | | `/invisible "user" -true` | Hides the player from the infected | | `/noclip "user" -true` | Walk through walls | | `/teleport "user1" "user2"` | Teleports the first player to the second | | `/teleportto x,y,z` | Teleports you to coordinates | | `/createhorde ` | Spawns a horde where you are standing | | `/chopper` | Triggers the helicopter event | | `/gunshot` | A gunshot sound near a player | | `/alarm` | Sets off the alarm in the building you are in | | `/startrain`, `/stoprain` | Weather | | `/startstorm`, `/stopweather` | More weather | | `/thunder`, `/lightning` | At your position | | `/releasesafehouse` | Releases the safehouse you are standing in | Server and maintenance: | Command | What it does | | --- | --- | | `/save` | Writes the world to disk now | | `/quit` | Saves and shuts the server down cleanly | | `/servermsg "text"` | Broadcasts a message to everyone | | `/showoptions` | Prints the current server options | | `/changeoption ` | Changes one option live | | `/reloadoptions` | Re-reads the ini and applies what can be applied | | `/reloadlua "filename"` | Reloads one Lua file, for debugging | | `/checkModsNeedUpdate` | Asks Steam whether any workshop mod has updated | | `/help` | Lists the commands your level can run | Item names are `module.type`, almost always `Base.Something`, and they are case sensitive. Vehicle names are the `Base.*` vehicle scripts. Perk names for `/addxp` are the internal ones: `Woodwork`, `Cooking`, `Fitness`, `Strength`, `Sprinting`, `Aiming` and so on, not the display names with spaces. > [!TIP] > `/changeoption` is live but not permanent in every case, and `/showoptions` is the only way to see what the running server actually believes. When you change something that matters, change it in the ini as well, with the server stopped, so the next restart agrees with you. #### Whitelisting, accounts and the user database Two separate things control who gets in, and people mix them up constantly. `Password=` in the ini is a single server password typed at connection. It keeps strangers out and nothing else. `Open=` decides how accounts work. With `Open=true`, the default, a new player types a username and password on first join and the account is created for them. With `Open=false`, only accounts that already exist can connect, and you create them yourself: ```text /adduser "Bob" "a-password-you-tell-Bob" /addusertowhitelist "Bob" ``` For a server that is already running with `Open=true` and a group of regulars, the quickest way to close it is to have everyone connect once, run `/addalltowhitelist`, then set `Open=false` and restart. All of this lives in a SQLite database at `Zomboid/db/.db` - accounts, password hashes, access levels and bans. Two practical consequences: deleting that file resets every account including `admin`, and copying it is how you move your user list to a new server without making everyone register again. Back it up along with the save, not instead of it. Bans by account are trivially defeated by making a new account on an open server, which is why `/banid` exists. The Steam ID appears in the server logs for every connection, so the sequence for a repeat offender is to find the ID in the log, `/banid` it, and then ban the account as well so the name is recorded. #### The in-game admin panel Logged in at a sufficient level, you get an admin button in the game's interface. The panel is the practical interface for the things that are painful to type: - **Players**: the connected list with positions, with teleport, kick and access level in a menu. - **Items and vehicles**: a searchable spawn list, which saves you looking up `Base.` names. - **Sandbox options**: the live sandbox values, editable without a restart. This is the fastest way to change zombie population or loot rarity for an experiment, and the changes apply to the running world. - **Safehouses**: the claimed list, with the owner and members, and a release button. - **Database**: the account list, where you can change a level or a password without the command. Anything you change here happens immediately and is written into the save, not into `.ini` or `_SandboxVars.lua`. That is the trap: a value changed in the panel survives restarts because it is in the save, so when the file and the game disagree, the save wins. If you want a setting to be permanent and obvious, set it in the file too. The full list of those values is in [Project Zomboid server settings](https://www.renode.space/blog/project-zomboid-server-settings). #### Safehouses and why they cause arguments Safehouse rules are the most social settings on a Zomboid server, and they are all off by default. Every one of these keys lives in `.ini`: | Key | Default | What it does | | --- | --- | --- | | `PlayerSafehouse` | `false` | Players can claim a building as a safehouse | | `AdminSafehouse` | `false` | Admins can claim one too | | `SafehouseAllowTrepass` | `true` | Non-members may walk in | | `SafehouseAllowLoot` | `true` | Non-members may take things inside | | `SafehouseAllowFire` | `true` | Fire still damages a safehouse | | `SafehouseAllowRespawn` | `false` | Members respawn at the safehouse on death | | `SafehouseAllowNonResidential` | `false` | Shops and warehouses can be claimed | | `SafehouseDaySurvivedToClaim` | `0` | In-game days survived before a player may claim | | `SafeHouseRemovalTime` | `144` | Hours of owner absence before the claim lapses | | `DisableSafehouseWhenPlayerConnected` | `false` | Protection off while a member is online | Note the capitalisation of `SafeHouseRemovalTime`, which does not match the others. The ini is inconsistent in a few places, so copy keys out of the generated file rather than retyping them from memory. The combination that produces a peaceful server is `PlayerSafehouse=true` with `SafehouseAllowTrepass=false` and `SafehouseAllowLoot=false`: a claimed building is genuinely yours and yours alone. The combination that produces complaints is `SafehouseAllowTrepass=true` with looting allowed, because the claim then protects nothing and people assume it does. `SafehouseDaySurvivedToClaim` is worth setting to something above zero on a public server. It stops a fresh spawn claiming the Rosewood fire station five minutes after joining, which is otherwise the first thing that happens. `SafeHouseRemovalTime` at the default 144 hours means a claim lapses after six real days without the owner - shorten it on a busy server, lengthen it for a group that plays once a week, and tell people the number. `DisableSafehouseWhenPlayerConnected` deserves its own warning. It turns protection off whenever a member is online, which sounds fair and means a player standing in their own base can be robbed while they sleep at the wheel. Leave it false unless you are running a PvP server and want raiding to be possible. An admin standing inside a disputed building can run `/releasesafehouse` to clear the claim, which is the end of most arguments. Write down that you did it, because the person who lost the claim will ask. #### Logs, and proving what happened Project Zomboid writes far more than one log. The full console output goes to `Zomboid/server-console.txt`, and `Zomboid/Logs/` holds dated files split by category. The exact set varies by build, but you can expect files for chat, player connections, admin actions, commands run, item transactions, perk changes, PvP and map changes. The map log is the one people do not know about. It records player-caused changes to the world, which is how you find out who dismantled the generator. The item log is how you find out where the generator went. Between those two and the chat log, almost every griefing dispute is answerable without anyone's word against anyone else's. Two habits make this work. Pull the logs off the server on a schedule rather than after an incident, because rotation will eventually remove the day you needed - [logs worth keeping](https://www.renode.space/blog/logs-worth-keeping) covers what to retain and for how long. And read the console rather than only searching it; the startup output tells you which mods loaded, which anti-cheat types are active and what the server thinks its settings are. [Reading the console](https://www.renode.space/blog/reading-the-console) goes through that in general. #### Anti-cheat and the kicks that are not cheating The server ships with a numbered list of anti-cheat checks, `AntiCheatProtectionType1` through `AntiCheatProtectionType24`, each a boolean with a matching `...ThresholdMultiplier`. They cover things like impossible movement, teleporting, item duplication and inventory changes that the server did not authorise. They also produce false positives, and mods are the usual cause. Anything that legitimately moves a player, changes movement speed, or hands out items through a custom interface can trip a check that was written on the assumption that nothing does that. The symptom is a player being kicked repeatedly at a specific moment - entering a vehicle, using a mod's menu - with the console naming the check that fired. The fix is to disable that specific numbered check, not all of them. Turning the whole list off on a public server means the first person with a cheat table can spawn whatever they like, and you will not find out until the economy is meaningless. If you run a long mod list, see [Project Zomboid server mods](https://www.renode.space/blog/project-zomboid-mods-and-workshop) for how to narrow down which mod is involved, and [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) for the wider hygiene. `DoLuaChecksum` is related and different. It kicks clients whose Lua files do not match the server's, which is exactly what you want, and exactly what breaks when a player has an extra client-side mod. Switching it off is a security decision rather than a convenience one: it is the check that stops somebody shipping their own modified game logic. #### FAQ ##### How do I become admin on my own Project Zomboid server? Log in with the username `admin` and the password set at first start, which on a hosted server is generated for you and shown with the server's credentials. If you have forgotten it, stop the server and set a new one in the launch arguments; the account itself lives in `Zomboid/db/.db`. ##### Does Project Zomboid support RCON? No. There is no RCON port and no remote admin protocol. You administer the server from its console or from a character logged in on an account with an access level, which is why keeping console access limited matters more here than in games where [RCON](https://www.renode.space/blog/rcon-safely) does the job. ##### What is the difference between a whitelist and a server password? The password is one shared string typed at connection. The whitelist is per account: with `Open=false` only accounts that already exist can join, so you create them with `/adduser` and hand out individual credentials. Use the whitelist if you ever want to remove one person without changing everyone's password. ##### Can I change sandbox settings without restarting? Yes, through the admin panel's sandbox options, and the change applies immediately to the running world. It is stored in the save rather than in `_SandboxVars.lua`, so update the file too if you want the setting to survive a rebuild. ##### Why does a player keep getting kicked for cheating? Almost always an anti-cheat check reacting to a mod. Find the numbered type in the console output and disable that one check in the ini rather than the whole list, then confirm the kick stops before you change anything else. ##### How do I take away a safehouse someone else claimed? Stand inside it as an admin and run `/releasesafehouse`, or find it in the admin panel's safehouse list and release it there. Claims also lapse on their own after `SafeHouseRemovalTime` hours without the owner, 144 by default. Every Project Zomboid plan on RE:NODE gets the same panel: an unfiltered console with command history for the admin commands above, an in-browser editor and SFTP for the ini and the Lua files, and per-server subusers with roles, so a moderator can have console access without billing access. The admin password is generated per server at install. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid server mods and load order Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-mods-and-workshop Three lines in one file decide whether a Project Zomboid server has mods: `WorkshopItems`, `Mods` and `Map` in `.ini`. `WorkshopItems` is a list of numbers that tells the server what to download. `Mods` is a list of names that tells it what to load. `Map` is a list of map folders, in priority order, with the vanilla map last. They are three different lists and they do not accept each other's values, which is the single most common reason a mod is installed, downloaded, present on disk and doing absolutely nothing. This guide covers where the files land, how to find the ID a mod actually wants, what load order does and does not fix, how map mods and spawn regions work, what Build 42 changed about mod folders, and the failures that follow a mod update. For the sandbox and server options themselves, see [Project Zomboid server settings](https://www.renode.space/blog/project-zomboid-server-settings); for the admin account and the commands you will need when a mod misbehaves, see [Project Zomboid admin commands](https://www.renode.space/blog/project-zomboid-admin-commands). #### How the server finds a mod at all A Project Zomboid dedicated server (Steam app `380870`) reads mods from more than one place: - **Workshop downloads.** Anything listed in `WorkshopItems` is fetched by the server itself at startup, into `steamapps/workshop/content/108600//`. Note the app id: `108600` is the game, not the server, because workshop content belongs to the game. - **Local mods.** Folders you upload yourself, into `Zomboid/mods//`. This is how you run a mod that was never on the workshop, or pin a version the author has since replaced. The download step is the reason the installer asks for a Steam account. Project Zomboid's dedicated server, like Arma 3, DayZ and 7 Days to Die, cannot be installed or kept updated with an anonymous Steam login, and neither can workshop content. On RE:NODE the server is created immediately and the install waits on the Setup tab until you enter those credentials - which are stored as you typed them, so use a spare account that owns the game rather than your main one. ```diagram title: What the server does with a Workshop ID at boot ini = servertest.ini | WorkshopItems and Mods steam = Steam download | app 108600 content folder = Mod folder | holds mod.info load = Mods= list | load order, left to right client = Player's game | pulls the same items ini -> steam : numeric IDs steam -> folder folder -> load : mod ID from mod.info ini -> client : list sent on join ``` Everything in this guide happens in `Zomboid/`, the server's data directory - `~/Zomboid/` on Linux, `%USERPROFILE%\Zomboid\` on Windows, and the folder the panel drops you into on a managed host. The config files are in `Zomboid/Server/`, the logs in `Zomboid/Logs/`, the saves in `Zomboid/Saves/Multiplayer//`. #### Workshop ID or mod ID: the difference that breaks installs A workshop item and a mod are not the same object. The **Workshop ID** is the number in the item's URL, after `?id=`. It identifies a download. One workshop item can contain several mods, and plenty do - map packs, mod collections published as a single item, mods that ship an optional add-on in the same upload. The **mod ID** is a string declared inside the mod, in its `mod.info` file: mod.info: ```text name=Better Firearms poster=poster.png id=BetterFirearms description=Adds a set of civilian firearms. require=CommonLibrary modversion=2.4.1 ``` `id=` is what goes in `Mods=`. It is case sensitive and is frequently nothing like the display name on the workshop page. The reliable way to read it is to open the downloaded folder and look, rather than guess from the title: after the first start, list what is under `steamapps/workshop/content/108600/` and read each `mod.info`. Many authors also print the mod ID on the workshop page, usually near the bottom, and that is worth trusting only because you can check it against the file. > [!TIP] > When a workshop item contains two mods, `WorkshopItems` still gets one number and `Mods` gets two names. The two lists do not have to be the same length or in the same order. `WorkshopItems` is a shopping list; only `Mods` decides load order. `require=` lists other mod IDs the mod needs. The server does not resolve those for you: if a mod requires a common library, the library needs its own workshop ID in `WorkshopItems` and its own mod ID earlier in `Mods`. #### The three lines that matter in servertest.ini The server's main config file is named after the server, so the default install gives you `Zomboid/Server/servertest.ini` along with `servertest_SandboxVars.lua` and `servertest_spawnregions.lua`. The mod lines look like this: servertest.ini: ```ini WorkshopItems=2392709985;2169435993;2875848298 Mods=CommonLibrary;BetterFirearms;RavenCreek Map=Raven Creek;Muldraugh, KY ``` Semicolons separate entries in all three, with no spaces after them. The semicolon matters more than it looks: map names contain commas (`Muldraugh, KY` is one map), so a comma-separated list would be ambiguous and the game does not accept one. A few other keys in the same file interact with mods: | Key | Default | What it does | | --- | --- | --- | | `CheckModsNeedUpdate` | `false` | Server polls Steam for workshop updates and logs when one appears | | `BackupsOnStart` | `true` | Takes a save backup at every start, including after a mod change | | `BackupsOnVersionChange` | `true` | Takes one when the game version changes | | `BackupsCount` | `5` | How many of those to keep | | `Open` | `true` | Whether an account is created on first join or must exist already | | `DefaultPort` | `16261` | UDP game port | | `UDPPort` | `16262` | UDP direct-connect port | Turn `CheckModsNeedUpdate` on. It costs nothing and it is the only warning you get before a silently updated mod breaks the next restart. Note that the ini's capitalisation is not consistent across every key in the file - copy the key out of the file the server generated rather than out of a guide, including this one. Edit the file with the server stopped. Project Zomboid rewrites its ini on a clean shutdown, so a change made to a running server is usually overwritten the moment you restart it properly. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) covers the edit-in-place workflow; the panel's file editor does the same job with syntax highlighting. #### Load order and conflicts Mods load in the order they appear in `Mods=`, left to right. When two mods change the same file, the one loaded later wins. That gives you a workable ordering rule: 1. Libraries and frameworks first - anything other mods declare in `require=`. 2. Content mods next: guns, vehicles, items, professions. 3. Tweaks and overrides last, because their whole purpose is to beat something already loaded. 4. Map mods anywhere in the list. Their position in `Mods=` barely matters; what matters is `Map=`, which is a separate ordering and covered below. The honest limit of this rule: load order only settles conflicts between mods that patch politely. A Lua mod that replaces a whole vanilla function wins regardless of where it sits, and two mods that both replace the same function will always break each other - the later one simply hides the damage until someone uses the feature the earlier one changed. If two mods are known to conflict, no ordering fixes it and the answer is to drop one. Balance mods that touch the same sandbox values behave the same way, and the symptom is subtle: your loot rarity looks wrong even though you never changed it, because a mod rewrote the value at load. When numbers do not match what the settings file says, suspect a mod before you suspect the setting. #### Map mods, the Map line and spawn regions Map mods are the part people get half-right. A map mod is usually two things at once: a regular mod (so it needs its ID in `Mods=`) and a map (so it needs its folder name in `Map=`). Install only one of the two and you get one of two classic symptoms - the map never appears, or the map appears with its buildings missing their custom furniture. The value in `Map=` is the folder name under the mod's `media/maps/`, and the vanilla entry must be last: ```ini Map=Raven Creek;Grapeseed;Muldraugh, KY ``` Priority runs left to right. The first entry wins for any cell it occupies. Because every map mod is placed at fixed cell coordinates on the same grid as the base map, two mods that were built for the same empty corner of the world will overlap, and the one listed second loses the overlapping cells - which usually means half a town is missing rather than a clean failure. There is no tool that checks this for you. Read each map's workshop page for its cell coordinates, and if two collide, one of them has to go. Two further details: - **Tile packs.** Most custom maps depend on a shared tileset mod, listed as a required item on their workshop page. Without it you get invisible walls, missing furniture or blocks of magenta. Add the tile pack's workshop ID and mod ID like any other dependency. - **Spawn points.** A map being loaded does not make it a place players can start. Spawn regions are declared in `_spawnregions.lua`: servertest_spawnregions.lua: ```lua function SpawnRegions() return { { name = "Muldraugh, KY", file = "media/maps/Muldraugh, KY/spawnpoints.lua" }, { name = "Riverside, KY", file = "media/maps/Riverside, KY/spawnpoints.lua" }, { name = "Raven Creek", file = "media/maps/Raven Creek/spawnpoints.lua" }, } end ``` The `file` path is relative to the game's media folders, and the map mod has to actually contain a `spawnpoints.lua` - not all do, and one that does not can only ever be walked to. If your custom map does not appear in the character creation list, this file is why, nine times out of ten. > [!WARNING] > Adding a map mod to a world that has already been played is safe. Removing one is not: the cells it provided are already written into your save, and the save will keep trying to load geometry that no longer exists. Plan map mods before launch, and treat a change to `Map=` as a wipe. #### What Build 42 changed Build 42 reached the stable branch in July 2026 and brought multiplayer with it, so most new servers are now on 42 rather than 41. For mod administration, the change that matters is the folder layout. - **Build 41** puts `mod.info`, `poster.png` and `media/` at the root of the mod folder. - **Build 42** uses version subfolders. A mod ships a `42/` folder holding `mod.info` and `media/`, alongside a `common/` folder for content shared between builds. The game loads `common/` plus the closest supported version folder. The practical consequence is that a Build 41 mod dropped into a Build 42 server is not seen at all. It does not error, it does not warn in a way you will notice, it simply never appears in the loaded list. If a mod you are sure you installed is missing from the console output at startup, open its folder and check whether there is a `42/` in it. Because the two builds want different layouts, a well-maintained mod supports both and a stale one does not. Check the workshop page for a stated build before adding anything, and expect the point releases after a stable launch to keep breaking things for a while - a mod that works on one 42.x patch can fail on the next. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is the general version of this problem. #### Clients, sync and mod mismatch Project Zomboid handles client distribution better than most games. When a Steam client connects to a server with `WorkshopItems` set, it subscribes to and downloads those items before joining. You do not have to hand out a mod list or a zip. What it does not do is tolerate a mismatch. If a player has a different version of a mod than the server, or has extra mods loaded that change the same content, they are dropped at connection or desync shortly after. Two situations cause this repeatedly: - **The player subscribed manually and Steam has a stale copy.** The fix is to unsubscribe, verify, and let the server's list pull it again. - **The server updated a mod and the player has not restarted Steam.** Steam updates workshop content lazily. A full restart of the client, not just the game, is the reliable fix. Client-only mods - interface tweaks, sorting, minimaps that do not add content - are fine and do not need to be on the server. Anything that adds items, changes recipes or touches the map has to be on both, at the same version. #### Updates, removals and the wipe you did not plan Removing a mod from a live server deletes its content from the save. Items from that mod disappear from every container and every player inventory the next time those chunks load. Vehicles from a vehicle mod vanish with whatever was in them. This is expected behaviour rather than corruption, but it is not reversible without a backup, and the only sane way to try a mod is to try it somewhere you do not mind losing. A practical routine: 1. Stop the server cleanly. A clean stop writes the ini and flushes the save. 2. Take a backup and keep it off the server. `BackupsOnStart` gives you a local copy, which protects you from a bad mod but not from a lost machine - see [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore). 3. Change one thing. One mod added, or one removed, per restart. 4. Start, and read the console. The loaded mod list and any Lua errors print in the first thirty seconds. 5. Join once yourself before telling anyone the server is back. On RE:NODE, steps 2 and 5 are the ones the panel helps with: backup slots are on every Project Zomboid plan and restore with a button, the console shows unfiltered output with the Lua stack traces intact, and the Schedules tab can take a backup before a nightly restart so there is always a recent copy from before the last mod change. Backups are stored off the machine they protect, which is the half that matters when the problem is not the mod. Mods also cost memory. The base server is comfortable in 3 GB for a small group; a list of twenty content mods, a custom map and a vehicle pack is a 6-8 GB server, and the growth is mostly in the Java heap rather than in the save. If the container hits its memory limit it is stopped and restarted clean rather than left to swap, so a mod list that outgrows the plan shows up as repeated restarts rather than as slow play. [Keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) has the general hygiene rules; [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers) covers how the download side works across games. #### Troubleshooting **The mod downloaded but is not loaded.** The mod ID in `Mods=` is wrong, or the workshop item contains a different ID than you assumed. Read `mod.info` in the downloaded folder. **The server starts, then exits with a Lua error.** A mod is incompatible with the build or with another mod. The last mod name printed before the stack trace is usually, though not always, the culprit. Remove mods in halves rather than one at a time. **The map mod loads but nobody can spawn there.** Missing entry in `_spawnregions.lua`, or the map has no `spawnpoints.lua`. **Half a modded town is missing.** Two map mods claim the same cells. The one later in `Map=` lost. Check the coordinates on both workshop pages. **Players are kicked with a mod mismatch.** Version skew. Have them restart Steam entirely; if that fails, unsubscribe and resubscribe the mod named in the message. **Everything worked yesterday.** A workshop item updated overnight. With `CheckModsNeedUpdate=true` the console will have said so. This is the argument for keeping a copy of every mod folder that works, so you can put a version back by hand. **The server hangs for minutes at startup.** Normal with a long mod list and a custom map the first time, because the map needs indexing. If it happens on every start, one of the mods is doing work at load that it should not. #### FAQ ##### Where do I find a mod's ID rather than its Workshop ID? In `mod.info` inside the mod folder, on the `id=` line. After the server has downloaded the item once, the folder is under `steamapps/workshop/content/108600//`. The workshop page often prints it too, but the file is the authority. ##### Do players need to install the mods themselves? No. A Steam client joining a server with `WorkshopItems` set downloads and enables those items automatically. They only act manually when Steam has cached a stale version, which a full Steam restart usually clears. ##### Can I add a map mod to a world people are already playing? Yes, adding is safe - the new cells are empty until someone walks into them. Removing a map mod from a live save is not safe, and changing which maps overlap is effectively a wipe of the overlapping area. ##### How many mods can a Project Zomboid server run? There is no hard limit, and people run fifty. The practical limits are memory and startup time. Budget roughly 3 GB for vanilla plus a group, and 6-8 GB once you have twenty content mods and a custom map. ##### Why did my items disappear after a restart? A mod was removed or failed to load, and the save dropped everything belonging to it. Restore a backup taken before the change, put the mod back at the same version, and only then decide whether you still want it gone. ##### Does load order matter for map mods? In `Mods=` it barely does. In `Map=` it decides everything: the first entry wins any cell two maps both claim, and `Muldraugh, KY` goes last so the vanilla world fills in whatever the mods did not place. Project Zomboid servers on RE:NODE start at 3 GB with three port allocations, SFTP and an in-browser file editor for the ini and the Lua files, and backup slots on every tier that restore with one button. The install waits on the Setup tab for your Steam login, so bring a spare account that owns the game. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) --- ### Project Zomboid server settings that matter Published 2026-06-16, updated 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/project-zomboid-server-settings Project Zomboid gives you several hundred settings across three files, and about six of them decide what your server feels like. The rest is detail you can leave alone until somebody asks. The trouble is that the six are scattered - two live in the ini, three in a Lua file, one in a database - and that editing the wrong copy of any of them is the single most common reason a change appears to do nothing. This guide covers where each setting lives, which ones matter, what the defaults are, how mods and workshop items differ, why the Java heap has to be smaller than your plan, and the errors that actually get reported. #### Where a Zomboid server keeps its settings The dedicated server is a Java application, installed from SteamCMD as app id `380870`. Unlike most Steam servers it will not download anonymously: it needs a Steam account login. Use a spare account for that, on any host, because the credential is stored as you type it. ```bash $ steamcmd +force_install_dir /home/pz/server +login your_spare_account \ +app_update 380870 validate +quit ``` Everything the server remembers lives under the user's `Zomboid` folder, and every file in it is named after the server: ```text Zomboid/ Server/ servertest.ini ports, PVP, safehouses, mods, backups servertest_SandboxVars.lua zombies, loot, time, weather servertest_spawnregions.lua where new characters appear db/ servertest.db accounts, whitelist, admin password, bans Saves/Multiplayer/servertest/ the world, one file per explored cell backups/ the server's own zipped backups ``` `servertest` is the default server name, set by `-servername` on the start script. Change it and you get a different ini, a different sandbox file and a different world - which is a perfectly good way to run two servers from one install and an excellent way to spend an evening editing settings that nothing reads. Before you debug anything else, confirm which name the server is actually started with. ```diagram title: Which file decides what ini = servertest.ini | ports, PVP, safehouses sandbox = SandboxVars.lua | zombies, loot, time db = servertest.db | accounts, admin, bans server = Game server | reads all three at start world = Saves/Multiplayer | the map as played ini -> server sandbox -> server db -> server server -> world : writes as players explore ``` > [!NOTE] > Build 42 renamed some keys and added others. The authoritative list for your build is the file the server writes on its own first start - not a guide, including this one. If a key you are about to add is not already in that file, check it exists before you trust it. #### The ini file: the keys that matter | Key | Default | What it does | | --- | --- | --- | | `DefaultPort` | `16261` | The main UDP port | | `UDPPort` | `16262` | The second UDP port | | `Public` | `false` | List the server publicly | | `PublicName` | - | The name in the list | | `Password` | - | Join password. Separate from the admin password | | `MaxPlayers` | `32` | Slots | | `Open` | `true` | `false` makes it whitelist-only | | `PVP` | `true` | Decide before launch, not after | | `PingLimit` | `400` | Milliseconds before a player is dropped | | `PauseEmpty` | `true` | Freeze the world when nobody is online | | `SaveWorldEveryMinutes` | `0` | Periodic full save. `0` is off | | `BackupsCount` | `5` | Zipped backups kept in `Zomboid/backups` | | `BackupsOnStart` | `true` | Back up every time the server starts | | `BackupsPeriod` | `0` | Minutes between backups. `0` is off | | `RCONPort` | `27015` | RCON, if you set a password | | `ResetID` | a number | Change it to make clients discard their cached world | | `Map` | `Muldraugh, KY` | Map load order, map mods first | | `Mods` | - | Mod ids to load, semicolons between | | `WorkshopItems` | - | Workshop ids to download, semicolons between | | `DoLuaChecksum` | `true` | Kick clients whose Lua does not match | `PauseEmpty` deserves a paragraph because it changes the character of a small server. With it on, time stops when the last player logs out: crops do not grow, generators do not burn fuel, and nothing rots while you are at work. With it off, the world keeps running and a fortnight away is a fortnight of decay. For a group of friends who play together, on is almost always right. For a persistent public server, off is the point. The safehouse keys are the ones people look for in the sandbox file and never find, because they are here: `PlayerSafehouse`, `AdminSafehouse`, `SafehouseAllowTrepass`, `SafehouseAllowLoot`, `SafehouseAllowFire`, `SafehouseAllowRespawn`, `SafehouseDaySurvivedToClaim` and `SafeHouseRemovalTime`. Safehouses are a social setting rather than a mechanical one: they decide whether players can lock each other out of buildings, and therefore whether your server is one where strangers can be robbed. Set them deliberately. There is also a block of numbered anti-cheat checks, `AntiCheatProtectionType1` through `AntiCheatProtectionType24`, each with a matching threshold multiplier. They exist because Zomboid trusts the client with a lot of movement and inventory logic. Mods, particularly ones that add vehicles or change movement, trip them and produce mystifying kicks. The log names the type that fired: disable that one, not all of them. #### The six settings that decide how it feels The original claim holds up: out of everything in those files, six choices make the server. 1. **Zombie population.** How many exist at all. This is the difference between a survival game and a horror game. 2. **Respawn.** Whether cleared areas stay cleared, which decides whether progress is permanent or Sisyphean. 3. **Loot rarity.** The difference between scavenging and shopping. 4. **Day length.** How much real time a survival day costs, and therefore how fast skills, farming and illness move. 5. **Safehouse rules.** In the ini, above. Whether players can be locked out. 6. **PVP.** In the ini. Decide it before launch, because changing it later changes who plays, not just how they play. The first four live in `servertest_SandboxVars.lua`, which is a Lua table rather than a key-value file: servertest_SandboxVars.lua: ```lua SandboxVars = { VERSION = 5, Zombies = 3, Distribution = 1, DayLength = 3, StartYear = 1, StartMonth = 7, StartDay = 9, StartTime = 2, WaterShut = 2, ElecShut = 2, ZombieLore = { Speed = 2, Strength = 2, Toughness = 2, Transmission = 1, Mortality = 5, Reanimate = 3, Cognition = 3, Memory = 2, Sight = 2, Hearing = 2, }, ZombieConfig = { PopulationMultiplier = 1.0, PopulationStartMultiplier = 1.0, PopulationPeakMultiplier = 1.5, PopulationPeakDay = 28, RespawnHours = 72.0, RespawnUnseenHours = 16.0, RespawnMultiplier = 0.1, RedistributeHours = 12.0, }, } ``` Two traps in that file. The first is that `Zombies` runs backwards: `1` is Insane, `2` High, `3` Normal, `4` Low and `5` None. People who set it to `1` expecting a quiet server get the opposite of what they asked for, and it is always funnier from the outside. The second is that most of the other numbered options are positions on a scale that you cannot guess from the number. Because of that, the reliable way to produce a sandbox file is to configure it in the game's own sandbox editor - start a single-player or hosted game with the settings you want, then copy the generated Lua onto the server - rather than typing numbers into a file and hoping. `DayLength = 3` is one hour of real time per in-game day, which is the default and a fair starting point; anything shorter turns farming into a full-time job. #### Zombie population, respawn and lore `ZombieConfig` is where the server's difficulty really lives, and it is worth understanding rather than copying. | Setting | Default | What it does | | --- | --- | --- | | `PopulationMultiplier` | `1.0` | Overall density, applied on top of `Zombies` | | `PopulationStartMultiplier` | `1.0` | Density on day one | | `PopulationPeakMultiplier` | `1.5` | Density at the peak | | `PopulationPeakDay` | `28` | Which day the peak lands on | | `RespawnHours` | `72.0` | Hours before a cell can repopulate. `0` disables respawn | | `RespawnUnseenHours` | `16.0` | How long a cell must go unseen first | | `RespawnMultiplier` | `0.1` | Fraction of the original population that returns | | `RedistributeHours` | `12.0` | How often zombies drift between cells | `RespawnHours = 0` is the single biggest quality-of-life change available to a multiplayer server, and it is the one most admins eventually make. On default settings, a town you spent a week clearing gradually refills, which on a solo playthrough is tension and on a server with eight people who each cleared a street is a reason to stop playing. Turning respawn off entirely makes the map a finite resource that the group consumes, which changes the long game: after two months, safe territory is something you built rather than something you defend. `ZombieLore.Speed` is the other headline: `1` is sprinters, `2` fast shamblers, `3` shamblers. `2` is the default and is what most people mean by "normal Zomboid". Sprinters on a public server with a full map is a novelty server, and it will have the population of one. `RedistributeHours` is subtle and worth leaving alone unless you know why you are touching it. It is what makes hordes wander, and on a multiplayer server it is also what carries the consequences of one player's gunshot into another player's town. #### Ports and connecting | Port | Protocol | Purpose | | --- | --- | --- | | `16261` | UDP | `DefaultPort` - game traffic and the server query | | `16262` | UDP | `UDPPort` - the second channel the client needs | | `27015` | TCP | RCON, if `RCONPassword` is set | Both game ports are UDP and both are required; a firewall that opens one gets you a server that shows in the list and refuses to finish connecting. Older builds also used `8766` and `8767` for Steam, set by `SteamPort1` and `SteamPort2`, so if you are following an old guide and have spare allocations, opening them costs nothing. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) covers testing them properly from outside, which is faster than guessing. RCON is a plain TCP protocol with the password sent in the clear, so treat it accordingly - [using RCON safely](https://www.renode.space/blog/rcon-safely) is two minutes well spent. On a panel host the console does the same job over an internal connection, which is generally the better habit. #### Admins, access levels and live changes The admin password is not in the ini. It is set on the first start, prompted for on the console or passed to the start script, and stored in `db/.db` along with every account, whitelist entry and ban. On RE:NODE it is generated per server rather than shipped as a default, which is the right way round: a default admin password on a public server is a griefing incident with a timer on it. Access levels, from most to least: `admin`, `moderator`, `overseer`, `gm`, `observer`. Promote with `/setaccesslevel "PlayerName" moderator`. | Command | What it does | | --- | --- | | `/players` | Who is connected | | `/kick "name" -r "reason"` | Remove a player | | `/banuser "name" -ip -r "reason"` | Ban, optionally by address too | | `/unbanuser "name"` | Reverse it | | `/save` | Force a world save | | `/quit` | Clean shutdown, saving first | | `/servermsg "text"` | Broadcast to everyone | | `/changeoption Key=Value` | Change an ini option on the running server | | `/reloadoptions` | Apply the ini from disk without restarting | | `/showoptions` | Print the current values | | `/checkModsNeedUpdate` | Ask Steam whether your workshop mods have changed | | `/addusertowhitelist "name"` | Whitelist an existing account | | `/releasesafehouse` | Free a safehouse whose owner has gone | `/changeoption` and `/reloadoptions` together are the feature nobody knows about: most ini options can be changed on a live server without dropping anyone. Sandbox variables cannot. Those are read when the world loads, and several of them - the ones baked into the map at generation - will not change an existing world at all. [Project Zomboid admin commands](https://www.renode.space/blog/project-zomboid-admin-commands) goes through the full list and what each access level can reach. #### Mods, workshop items and load order Two ini keys, and they are not the same thing. This is the most common mod problem on any Zomboid server. servertest.ini: ```ini WorkshopItems=2392709985;2169435993;1299328280 Mods=Authentic Z - Current;ImprovedBuildMenu;Hydrocraft Map=RavenCreek;Muldraugh, KY ``` Those three lines do three different jobs. - **`WorkshopItems`** takes the numeric Steam Workshop id. It tells the server what to download. - **`Mods`** takes the mod id from the mod's own `mod.info` file. It tells the server what to load. A workshop item can contain several mods, and the ids look nothing alike, so listing the number in both places downloads the mod and then loads nothing. Order matters in `Mods`: later entries override earlier ones, which is how compatibility patches work and why a patch listed before the mod it patches does nothing. `Map` is a third list, for map mods, and the base map goes last. Everything before it is layered on top. > [!WARNING] > Never remove a map mod from a world that has already generated chunks in its area. The save holds cells that reference terrain the server can no longer load, and the result ranges from players falling through the world to a save that will not open. Adding a map mod to a running world is fine. Removing one is a wipe. The other thing that catches servers is a workshop mod updating while the server runs. Clients download the new version from Steam, the server is still on the old one, and joins fail with a mismatch that says nothing useful. `/checkModsNeedUpdate` reports it and a restart fixes it. [Mods and the workshop on a Zomboid server](https://www.renode.space/blog/project-zomboid-mods-and-workshop) covers collections and load order in detail, and [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is the general version of the problem. #### Memory, map cells and the Java heap Zomboid holds loaded map cells, and players scatter. Ten players in one town costs less than four players in four towns - the server is loading, simulating and saving four separate regions instead of one. This is why player-count sizing advice is wrong for Zomboid in both directions. | Server | Plan memory | `-Xmx` | Notes | | --- | --- | --- | --- | | 2-4 players, vanilla, one town | 3 GB | `2g` | Comfortable | | 8-16 players, spread out | 4-6 GB | `3g` - `4g` | The common case | | 16-32 players, mods and map mods | 8-10 GB | `6g` - `7g` | Map mods are the expensive part | That third column is not decoration. The server is a JVM, and its heap is set in `ProjectZomboid64.json`: ProjectZomboid64.json: ```json { "mainClass": "zombie/network/GameServer", "classpath": ["."], "vmArgs": [ "-Djava.awt.headless=true", "-Xms2g", "-Xmx6g" ] } ``` The file ships with more arguments than that; change only the `-Xms` and `-Xmx` lines. And leave headroom: the JVM's heap is not the whole process, because metaspace, thread stacks and native buffers sit outside it and the container limit counts all of them. Setting `-Xmx` equal to your plan's memory is how you get a server that is killed while Java still believes it has room to spare. Seventy to eighty per cent of the limit is the rule. On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than being allowed to swap, which is kinder to the node and to your neighbours but does mean an undersized heap setting shows up as an abrupt restart rather than a slow decline. [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) covers telling which of the two you are short of before buying either. Disk grows quietly. The save folder holds one file per explored map cell, so a server that has run for a year with a well-travelled map is measured in gigabytes. Project Zomboid plans here start at 3 GB with three port allocations, from $9 a month, and the Steam login the install needs goes on the Setup tab. #### Backups, resets and the save folder Zomboid's own backups are real and better than nothing: `BackupsOnStart`, `BackupsPeriod` and `BackupsCount` produce zip files in `Zomboid/backups`. They also sit on the same disk as the thing they protect, which makes them a defence against a bad update and no defence at all against a deleted server. Keep real backups somewhere else, and restore one occasionally to prove it works - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is the argument in full. To wipe a world properly: 1. Stop the server with `/quit` so the current state is written out. 2. Take a backup you can go back to. 3. Delete `Zomboid/Saves/Multiplayer//`. 4. Increment `ResetID` in the ini, which tells clients to throw away their cached copy of the old world. 5. Start the server. A new map generates on first load. Player accounts live in the database, not the world, so a map wipe leaves everyone's login, whitelist entry and ban intact. Delete `db/.db` as well only if you actually want to reset the roster. A weekly restart at a quiet hour is worth scheduling regardless. Long-running Zomboid servers accumulate, and a restart is cheap on a game where sessions are short; [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers doing it without dropping someone mid-fight. #### Troubleshooting **The settings I changed did nothing.** Either the server is started with a different `-servername`, or you edited the copy in the install folder rather than the one under `Zomboid/Server/`. Run `/showoptions` and compare. **Players cannot connect but the server is listed.** UDP `16262` is closed. The listing uses the first port; joining needs both. **"Connection lost" a second after joining.** Mod mismatch, almost always. Check `Mods` against what clients are subscribed to, and run `/checkModsNeedUpdate`. **The client says the version does not match.** One side is on a beta branch and the other is on stable. Pin both. **Random kicks with an anti-cheat message.** Read the type number in the log and disable that specific `AntiCheatProtectionType`. Mods that alter movement or vehicles are the usual trigger. **The server restarts on its own under load.** The Java heap is set too close to the plan's limit, so the container is killed before the JVM ever garbage-collects its way out. Lower `-Xmx`. **Zombies keep coming back to a cleared town.** `RespawnHours` and `RespawnMultiplier`. Set `RespawnHours = 0` if you want clearing to be permanent. **The world will not load after a mod change.** A map mod was removed. Restore the backup, put the mod back, and move players out of that region before removing it properly. #### FAQ ##### How much RAM does a Project Zomboid server need? Three gigabytes runs a small group in one town, 4-6 GB covers eight to sixteen players spread out, and 8-10 GB is a large modded server. Set the Java heap to roughly three quarters of that, never all of it. ##### Where is the admin password stored? In `Zomboid/db/.db`, not in the ini. It is set on the first start or passed to the start script, and it is separate from the `Password` key that players use to join. ##### Can I change sandbox settings on a running server? Most ini options, yes, with `/changeoption` and `/reloadoptions`. Sandbox variables are read when the world loads, so they need a restart, and the ones baked into the map at generation will not change an existing world at all. ##### What is the difference between Mods and WorkshopItems? `WorkshopItems` is the numeric Steam Workshop id and controls what gets downloaded. `Mods` is the mod id from `mod.info` and controls what gets loaded. You need both, and they are different strings. ##### Does turning off zombie respawn break the game? No, it changes it. The map becomes a finite resource the group works through, which suits a persistent server with regular players far better than the default slow refill does. ##### Why does the server lag when everyone splits up? Because each player loads and simulates the map cells around them. Four players in four towns is four regions being kept alive; ten players in one town is one. It is the clearest example in any game of why player count is a bad sizing input. Project Zomboid servers on RE:NODE start at 3 GB from $9 a month, with three port allocations, an admin password generated per server rather than shipped as a default, backup slots on every tier and a Schedules tab for the weekly restart. The Steam login the install needs goes on the Setup tab - use a spare account, since it is stored as typed. [See Project Zomboid plans](https://www.renode.space/game-servers/project-zomboid) ## Rules for the assistant - Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead. - Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository. - An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port. - On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker. - Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak. - Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository. - Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current. - For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one. - If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.