# 7 Days to Die Server Hosting - everything RE:NODE has published

> A 7 Days to Die 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/7-days-to-die, 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/7-days-to-die.

Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant.

## What it is

Dedicated 7 Days to Die servers with room for a full horde night.

- Genres: Action, Adventure, Indie, RPG
- Developer: The Fun Pimps
- Released: 25 Jul, 2024
- Steam: https://store.steampowered.com/app/251570/

### You supply two things yourself

7 Days to Die 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 7 Days to Die 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 7 Days to Die 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.
- 2 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 7 Days to Die plan do you need?

Memory is what decides whether a server holds together, so start there. The Advanced tier gives 8 GB and 2 vCPU, which suits a private group. The Pro tier at 10 GB is where most public servers sit, and Premium at 14 GB exists for the servers that stay full.

Storage matters more than people expect once mods and backups are involved - plans here run from 55 GB to 100 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 01:45 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/7-days-to-die or in the panel shop at https://panel.renode.space before quoting one.

- You supply: Steam username - 7 Days to Die server files are not downloadable anonymously — Valve serves them only to an account that owns the game. Use an account that owns 7 Days to Die, 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 |
|---|---|---|---|---|---|---|---|
| Advanced | $20 | 8 GB | 2 vCPU | 55 GB | 1 | 2 | 2 |
| Pro | $26 | 10 GB | 2.5 vCPU | 70 GB | 1 | 2 | 2 |
| Premium | $40 | 14 GB | 3.5 vCPU | 100 GB | 1 | 2 | 2 |


## 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

6 posts, newest first. Each one follows in full after the list.

- [7 Days to Die server RAM: real figures](https://www.renode.space/blog/how-much-ram-does-a-7-days-to-die-server-need) (2026-10-07): 7 Days to Die server memory by world size and player count, the serverconfig.xml keys that move it, blood moon peaks, the log line that shows it and when to restart.
- [7 Days to Die blood moon and horde lag](https://www.renode.space/blog/seven-days-to-die-blood-moon-and-performance) (2026-10-07): How 7 Days to Die blood moon hordes are sized on a server, which settings change zombie counts, how to read the stats line, and how to stop horde night lag.
- [7 Days to Die overhaul mods on a server](https://www.renode.space/blog/seven-days-to-die-overhaul-mods) (2026-10-07): Running Darkness Falls, Undead Legacy, Rebirth or another 7 Days to Die overhaul on a dedicated server: versions, EAC, client installs, new worlds and memory.
- [7 Days to Die world generation and RWG](https://www.renode.space/blog/seven-days-to-die-world-generation-rwg) (2026-10-07): How random world generation works on a 7 Days to Die server: seeds, map sizes, generation time and memory, Navezgane vs RWG, and uploading a world you made.
- [7 Days to Die admin commands and modlets](https://www.renode.space/blog/seven-days-to-die-admin-commands-and-mods) (2026-09-21): How to run a 7 Days to Die server: serveradmin.xml permission levels, telnet, the console commands worth knowing, and installing modlets safely.
- [7 Days to Die serverconfig.xml settings](https://www.renode.space/blog/seven-days-to-die-server-settings) (2026-07-31): Every serverconfig.xml setting that matters, what blood moon really costs, ports, telnet and admin commands, modlets, and how region files go bad.

---

### 7 Days to Die server RAM: real figures

Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/how-much-ram-does-a-7-days-to-die-server-need

A 7 Days to Die dedicated server needs 8 GB of memory for Navezgane or a 6k random world with up to four players, 10 to 12 GB for an 8k world with six to eight players, and 12 to 14 GB for a 10k world with eight or more players spread across the map. Overhaul mods add another 2 to 4 GB on top. Those are peak figures, and the peak has a date: horde night, when every player is fighting a wave of zombies at once, after a week of memory growth since the last restart. The two settings that move memory most are the world size you generate and the view distance you allow, and both are easier to get right before the world exists than after.

#### What a 7 Days to Die server holds in memory

7 Days to Die is a Unity server simulating a voxel world that players dig through, build on and blow up. Memory is made of four parts.

- **Loaded chunks.** The world is stored in chunks, and the server keeps the chunks around each player loaded and active. More players spread further apart means more chunks; a group in one base loads a fraction of what the same group exploring in four directions does.
- **Entities.** Zombies, animals, players, vehicles, dropped backpacks and loot bags. Each zombie is an AI with pathing, and pathing through a destructible voxel world is expensive in memory and CPU.
- **The world's static data.** The generated terrain, the POI layout, the road network, the prefab data for every building that can appear. A larger generated world has more of all of it.
- **Dynamic mesh.** The system that lets players see distant POIs and player builds with their damage. It caches meshes for the areas it tracks, controlled by `DynamicMeshEnabled` and its related keys.

The Unity runtime and the managed heap sit underneath, and like any managed runtime it needs free space to collect in. A server whose live data fills the container leaves the collector no room, and that is when the hitches start before anything runs out.

#### RAM by world size and players

| World and group | RAM | vCPU | Notes |
| --- | --- | --- | --- |
| Navezgane or 6k world, up to 4 players | 8 GB | 2 | The floor for a comfortable server |
| 8k random world, 6-8 players | 10-12 GB | 2-3 | The common community size |
| 10k world, 8+ players, spread out | 12-14 GB | 3 | Spread matters more than count |
| Overhaul mods (Darkness Falls and similar) | add 2-4 GB | add 0.5-1 | More zombies, more items, more blocks |
| World generation on first start | peak above all of these | - | A one-off spike |

7 Days to Die is one of the few games where 8 GB is a floor rather than a comfortable middle. Below it the server will start and run a quiet afternoon, then fall over on its first horde night. The [7 Days to Die server settings guide](https://www.renode.space/blog/seven-days-to-die-server-settings) uses the same figures and goes through the whole configuration.

The player column is honest about one thing that surprises people: the default `ServerMaxPlayerCount` is 8, and the game is designed around groups that size. Larger servers exist and run, but each extra player who goes off on their own loads another region of chunks and triggers another set of zombie spawns, so memory and CPU rise faster than linearly once a server is past about ten.

#### The settings that move memory

All of these are properties in `serverconfig.xml`. Defaults have shifted between releases, so read the values in your own file rather than trusting any table, including this one.

serverconfig.xml:

```xml
<property name="GameWorld"                       value="RWG"/>
<property name="WorldGenSize"                    value="8192"/>
<property name="WorldGenSeed"                    value="tuesday-group"/>
<property name="ServerMaxPlayerCount"            value="8"/>
<property name="ServerMaxAllowedViewDistance"    value="10"/>
<property name="MaxSpawnedZombies"               value="64"/>
<property name="MaxSpawnedAnimals"               value="50"/>
<property name="BloodMoonEnemyCount"             value="8"/>
<property name="DynamicMeshEnabled"              value="true"/>
<property name="DynamicMeshLandClaimOnly"        value="true"/>
<property name="DynamicMeshMaxItemCache"         value="3"/>
```

| Property | Typical default | Effect on memory |
| --- | --- | --- |
| `WorldGenSize` | `6144` | Size of a random world; bigger means more static data and more to explore |
| `ServerMaxAllowedViewDistance` | `12` | Caps each client's view distance in chunks; lower means fewer loaded chunks |
| `MaxSpawnedZombies` | `64` | Zombies alive across the whole map at once |
| `MaxSpawnedAnimals` | `50` | Animals alive at once |
| `BloodMoonEnemyCount` | `8` | Horde zombies per player at a time on blood moon |
| `DynamicMeshEnabled` | `true` | Distant POI and build meshes; costs memory to cache |
| `DynamicMeshLandClaimOnly` | `true` | Limits dynamic mesh to land-claimed areas |
| `DynamicMeshMaxItemCache` | `3` | How many mesh items are held in memory |

The two worth acting on first:

**`ServerMaxAllowedViewDistance`.** The range is 6 to 12, and it caps what any client may request. Dropping from 12 to 10 or 8 reduces the chunks each player keeps loaded on the server, and most players barely notice in a world full of fog, trees and buildings. It is the cheapest memory saving on the list.

**`WorldGenSize`.** A 10k world is not just larger; it has more cities, more POIs and more road, and its first generation takes long enough that people assume the server has hung. If your group is four people, a 6k or 8k world gives them more than enough to explore and costs noticeably less. Size the world to the group, not to the biggest number in the dropdown. [7 Days to Die world generation](https://www.renode.space/blog/seven-days-to-die-world-generation-rwg) covers RWG sizes, seeds and generation time in detail.

> [!NOTE]
> `MaxSpawnedZombies` is a server-wide cap, not per player. On an eight-player server the 64 zombies are shared between everyone, which is why spread-out groups each see fewer zombies than a group that sticks together. Raising it for a harder game costs memory and CPU in direct proportion.

#### Horde night is the load test

Every seventh day by default, the blood moon sends waves of zombies at every player. `BloodMoonEnemyCount` is how many are alive per player at a time, so eight players at the default mean 64 horde zombies pathing towards eight positions, often through player-built defences that are being destroyed and recalculated as they go. On top of that sit the normal spawns, the loaded chunks around each base and the block damage being written.

That evening is the peak for memory and for CPU, and it comes at the end of a week of steady growth since the last restart. Three habits make it survivable:

1. **Restart before horde night, not after.** A restart in the afternoon of day seven returns the server to its floor right before the heaviest hour. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers picking the time and warning players.
2. **Fight in fewer places.** Four separate horde bases are four separate pathing problems and four sets of loaded chunks. Two shared bases are half of that.
3. **Do not raise `BloodMoonEnemyCount` for a big group.** It is per player. A twelve-player server at 8 is already 96 zombies at a time; the difficulty comes from the count per base, not per player.

[Blood moon and performance](https://www.renode.space/blog/seven-days-to-die-blood-moon-and-performance) covers the horde settings and their costs in more depth.

#### The log line that tells you the truth

The 7 Days to Die server writes a status line to its log roughly once a minute. It looks like this, with the exact fields varying a little between versions:

```text
Time: 412.03m FPS: 38.21 Heap: 3215.4MB Max: 4120.7MB Chunks: 612 CGO: 74 Ply: 6 Zom: 41 Ent: 63 (112) Items: 0 CO: 6 RSS: 9874.2MB
```

The fields worth reading:

- **`FPS`** is the server's simulation rate. It is CPU, not memory. Sustained values below about 20 are where players notice zombies teleporting.
- **`Heap`** and **`Max`** are the managed heap in use and the largest it has been. A heap that keeps setting new maximums across days is growth or a leak.
- **`RSS`** is the whole process's resident memory - the number the container limit actually counts. Compare it with your plan's limit. If `RSS` at the end of horde night is within about 10% of the limit, you are one bad evening from being stopped.
- **`Chunks`** and **`Zom`** and **`Ent`** show what drives the numbers: chunks loaded, zombies alive, entities in total.

Grep the log for these lines and you have a memory history without any extra tools. The admin console's `mem` command prints a similar summary on demand and triggers a garbage collection, which is useful for checking whether a high reading is live data or just garbage waiting to be collected. [7 Days to Die admin commands](https://www.renode.space/blog/seven-days-to-die-admin-commands-and-mods) lists the rest of the console.

#### World generation and the save folder

A random world is generated on the first start with a given name, seed and size. Generation builds the terrain, places towns and POIs, lays roads and writes the result to the generated worlds folder. It is a heavy, one-off job: memory during generation can exceed what the finished world needs to run, and a 10k world can take a long time. On a plan that is fine for running the world, generation can still fail.

Two ways around it:

1. **Generate on a quiet server** with nobody connected and nothing else running, then take a backup the moment it finishes.
2. **Generate in the game client** on your own PC with the same name, seed and size, then upload the generated world folder to the server. The server finds it and skips generation.

After that, the save grows as players play. Each region of the world is a `.7rg` file under the save's `Region` folder, and regions that have been dug, built on or damaged carry that data. A well-travelled 10k world's region files can reach several gigabytes, which is disk rather than memory, but loading and saving them is part of what the server does each time a player moves into a new area.

#### Mods: modlets and overhauls

7 Days to Die mods range from single-file modlets that change one recipe to complete overhauls that replace most of the game's content.

- **Modlets** that adjust XML - recipes, loot, stack sizes - cost almost nothing in memory.
- **Content modlets** that add blocks, items or zombie types add their assets and their spawns.
- **Overhauls** such as Darkness Falls add new zombie classes, many new blocks and items, new POIs and changed spawning. They are effectively a different game with different requirements: add 2 to 4 GB and half a core, and expect a slower start.

Overhauls follow the base game's major versions with a delay, so check that the version you install matches the server's game version exactly; a mismatch usually stops the server at load rather than using extra memory. [Overhaul mods on a server](https://www.renode.space/blog/seven-days-to-die-overhaul-mods) covers installing them and keeping clients in step.

#### A worked example: six players on an 8k world

A group of six wants an 8k random world, default zombie counts, one modlet pack of quality-of-life changes and blood moon every seven days. The table says 10 to 12 GB. Here is how to confirm it on real data rather than trusting the table.

1. **Generate first, size second.** Generate the world on a quiet server or in the client and upload it, so the generation spike does not decide the plan.
2. **Note the floor.** Start the server with nobody online and read `RSS` from the status line after five minutes. On an 8k world that is the engine, the world's static data and the modlets.
3. **Read a normal evening.** With all six online and spread across the map, watch `RSS`, `Chunks` and `Zom` during the busiest hour. Spread shows up as a high `Chunks` figure.
4. **Read horde night.** The same fields at the height of the blood moon on day seven, without a restart beforehand, give the true peak of the week.
5. **Decide.** If that peak is under about 85% of the plan, it fits. If it is close, the cheapest fixes are a restart before horde night and `ServerMaxAllowedViewDistance` lowered by two. If neither is enough, move up a tier.

Most groups of this shape land comfortably on 10 GB with a pre-horde restart, and on 12 GB without one. The difference between those two plans is often one scheduled task.

#### What happens at the limit

When a 7 Days to Die server runs out of memory inside a container, it does not log a friendly error. The process is stopped, the log ends mid-line, and the last region files written are what you have. Region files caught mid-write are one of the ways a 7 Days save is damaged, which is why the habit of keeping backups matters more on this game than most.

On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than being left to swap; a swapping 7 Days server is unplayable anyway. Backup slots come with every plan and the Schedules tab can run a backup before the pre-horde-night restart. 7 Days to Die plans start at 8 GB from $20 a month and go up to 14 GB, and the Steam login the install needs goes on the Setup tab. Moving up a tier raises the limit on the server you already have, so the world stays where it is.

#### FAQ

##### Is 8 GB enough for a 7 Days to Die server?

For Navezgane or a 6k random world with up to four players, yes. For an 8k world with six to eight players it will run but will be tight on horde night at the end of a week without a restart. Below 8 GB the server is not worth running.

##### Why does my 7 Days server lag on horde night?

Because horde night is the peak for both memory and CPU: dozens of zombies pathing through destructible blocks at several bases at once. Check the `FPS` field in the log. If it collapses while `RSS` is well below your limit, it is CPU and fewer horde bases will help more than memory. If `RSS` is near the limit, restart before the next one.

##### Does a bigger world need more RAM?

Yes, more than in most games. A larger random world carries more static data and more POIs, and players spread further across it, loading more chunks. A 10k world for four players is paying for map they will never visit.

##### How much RAM does Darkness Falls need?

Plan on 2 to 4 GB more than the same world would need in vanilla, and an extra half core. Overhauls add zombie types, blocks and items and change spawns, so they raise both the floor and the horde night peak.

##### Does restarting help 7 Days to Die memory?

Yes. Memory grows across days of uptime, and a restart returns the server to its floor. Time it before horde night, not after, so the heaviest hour of the week starts from the lowest point.

7 Days to Die servers on RE:NODE start at 8 GB and go up to 14 GB, with two port allocations, backup slots on every tier and a Schedules tab that can run the backup and the pre-horde restart for you. The console graphs memory against the plan's limit, so you can see the horde night peak rather than guess at it.

[See 7 Days to Die plans](https://www.renode.space/game-servers/7-days-to-die)

---

### 7 Days to Die blood moon and horde lag

Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/seven-days-to-die-blood-moon-and-performance

A 7 Days to Die blood moon is sized by two numbers: `BloodMoonEnemyCount`, the zombies alive at once **per player**, and `MaxSpawnedZombies`, the ceiling for the whole server. Four players at the default 8 means 32 zombies at a time, replaced as they die from 22:00 until 04:00. When horde night lags, the cause is almost always one of four things: too many zombies alive for the CPU, players defending several separate bases, a base design that makes pathfinding expensive, or a server that has been running all week and is short of memory. Every one of them can be measured from the console and fixed without making the night boring.

This guide explains how the horde is actually built, every setting that changes it, how to read the line the server prints about its own health, and the changes that help most. The wider config file is covered in [7 Days to Die server settings](https://www.renode.space/blog/seven-days-to-die-server-settings).

#### How a blood moon horde is built

Every `BloodMoonFrequency` days the sky turns red, and at 22:00 game time the horde starts spawning around each player. Three things decide what arrives:

1. **How many at once.** `BloodMoonEnemyCount` per player, capped by `MaxSpawnedZombies` across the server.
2. **Which zombies.** The game stage. Each player has a game stage that rises with their level and days survived, adjusted by difficulty. Players close together are treated as a party, and the party's game stage - weighted towards the strongest member - picks the spawn groups from `gamestages.xml`. That is why a level 10 player defending with a level 80 friend sees ferals and radiated zombies they would never meet alone.
3. **How fast.** `ZombieBMMove`, the movement speed used during the horde.

As zombies die, more spawn to keep the count topped up, until the night ends at 04:00 or the wave's budget is spent. So the number that matters for the server is not the total killed overnight but the number alive at any moment, and the cost of each one depends on what it is doing.

The cost of an alive zombie is mostly pathfinding. Each one is working out how to reach a player through or around player-built blocks, choosing what to hit, and recalculating every time a block breaks. A zombie walking across open ground is cheap. A zombie inside a maze of half-broken concrete is not.

#### Every setting that changes horde night

| Property | Default | What it does |
| --- | --- | --- |
| `BloodMoonFrequency` | `7` | Days between blood moons. `0` turns them off |
| `BloodMoonRange` | `0` | Random days added or subtracted around the frequency |
| `BloodMoonWarning` | `8` | The hour the day counter turns red. `-1` for no warning |
| `BloodMoonEnemyCount` | `8` | Zombies alive at once, per player |
| `MaxSpawnedZombies` | `64` | Server-wide cap on zombies alive |
| `ZombieBMMove` | `3` | Horde speed: `0` walk, `1` jog, `2` run, `3` sprint, `4` nightmare |
| `EnemyDifficulty` | `0` | `0` normal, `1` feral |
| `GameDifficulty` | `1` | `0` to `5`. Damage dealt and taken, and game stage scaling |
| `DayNightLength` | `60` | Real minutes per game day, so it sets how long the horde lasts in real time |

serverconfig.xml:

```xml
<property name="BloodMoonFrequency"   value="7"/>
<property name="BloodMoonRange"       value="0"/>
<property name="BloodMoonWarning"     value="8"/>
<property name="BloodMoonEnemyCount"  value="8"/>
<property name="MaxSpawnedZombies"    value="64"/>
<property name="ZombieBMMove"         value="3"/>
```

A few of these interact in ways the comments do not spell out.

`DayNightLength` is a horde setting in disguise. The horde runs from 22:00 to 04:00, six game hours. At the default 60-minute day that is fifteen real minutes; at 120 minutes it is thirty. Longer days mean a longer stretch of sustained load, which matters more than any peak.

`BloodMoonRange` makes the night unpredictable, which some groups like. It also makes it impossible to schedule a restart before the horde, which is one of the most useful things you can do. If you use it, keep `BloodMoonWarning` on so people at least see it coming.

`GameDifficulty` changes the game stage, and the game stage changes which zombies spawn. Raising difficulty without lowering `BloodMoonEnemyCount` gives you the same number of zombies, each of them tougher and more often feral or radiated - so they live longer, which means each spends longer pathfinding.

#### The arithmetic: per player, then capped

The single most misunderstood thing about horde night is that `BloodMoonEnemyCount` is not a total.

| Players | `BloodMoonEnemyCount` | Requested | Actually alive with `MaxSpawnedZombies` 64 |
| --- | --- | --- | --- |
| 2 | 8 | 16 | 16 |
| 4 | 8 | 32 | 32 |
| 8 | 8 | 64 | 64 |
| 8 | 16 | 128 | 64 |
| 12 | 8 | 96 | 64 |

Two consequences come out of that table. A server that runs well for four players on night 7 can fall over on night 14 because eight people logged in, with no setting changed at all. And raising `BloodMoonEnemyCount` on a busy server often changes nothing, because the cap is already the limit - which is why players report that "the horde did not get bigger" after an admin raised it.

The cap is also shared with everything else. `MaxSpawnedZombies` covers the whole server, so zombies wandering around a player who is out in the wilderness during the horde count against the same budget as the ones at the main base. A player who stays out looting on blood moon night is quietly taking zombies away from everyone else's defence.

Raising `MaxSpawnedZombies` above 64 is possible, and the shipped comment warns that large values will cost server framerate and therefore lag for every client. It is the one number on the server where "more" is reliably worse. If you want a harder night, raise difficulty or speed before you raise the count.

#### Reading the server's stats line

You do not have to guess whether the server is struggling. The dedicated server writes a status line to its log at a regular interval, which the panel console shows as it arrives:

```text
Time: 412.37m FPS: 31.52 Heap: 5210.4MB Max: 6012.8MB Chunks: 1844 CGO: 212 Ply: 4 Zom: 32 Ent: 71 (148) Items: 23 CO: 4 RSS: 9120.5MB
```

| Field | Meaning | What to watch for |
| --- | --- | --- |
| `Time` | Minutes since the server started | Long uptime before a horde is a warning sign |
| `FPS` | The server's simulation rate | Falling into single digits is lag everyone feels |
| `Heap`, `Max` | Managed memory in use and allocated | Growth across the week |
| `Chunks` | Chunks loaded | High when players are spread out |
| `Ply` | Players connected | |
| `Zom` | Zombies alive | Should sit near your expected horde count |
| `Ent` | Entities, active and total | Climbing totals mean something is not despawning |
| `Items` | Dropped items in the world | Loot bags from the horde pile up here |
| `RSS` | Memory the process holds | The number your plan's limit is compared to |

The fields have been stable for years but their exact set varies a little between versions. What matters is reading them across the evening. Take a note of the line at 21:00 game time, again at the peak of the horde, and again after 04:00. If `FPS` drops hard while `Zom` sits at 32, the server cannot carry 32 zombies around those bases. If `FPS` holds and players still complain, look at their connections rather than the server - [latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) is how to tell. If `RSS` is near your plan's limit before the horde starts, it is a memory problem, not a zombie problem.

The console commands `mem` and `le` give the same information on demand. `le` lists every entity, which is how you find out that the "lag" is two hundred dropped loot bags or a herd of animals stuck in a canyon.

> [!TIP]
> Before the first horde of a new server, spend five minutes on a test: run `settime` to put the clock just before 22:00 on a blood moon day, play it with the group, and read the stats line. It is far better to discover the limit on a Tuesday than on the night everyone booked.

#### Bases, pathing and why one group lags and another does not

Two groups with the same settings and the same player count can have completely different horde nights, and the difference is usually the base.

**Several bases are several hordes.** The horde spawns around players. Four players in four bases is four separate sieges, four sets of chunks loaded, and four pathfinding problems. Four players in one base is one. Asking a group to defend together on horde night is the single biggest performance improvement available, and it costs nothing.

**Structural collapses are expensive.** When zombies break a support, everything resting on it has to be recalculated, and falling blocks become physics objects for a moment. A tall base on thin supports that collapses in sections creates a burst of work the server feels immediately. Lower, wider, well-supported structures are kinder.

**Mazes make zombies think.** Zombies pick a route by evaluating block strength along possible paths. A long switchback corridor with many alternative breakable walls gives them more to evaluate every time a block changes. Funnel designs that present one obvious route are cheaper than labyrinths.

**Dynamic mesh does work in the background.** `DynamicMeshEnabled` recalculates structural data for player-modified areas. With `DynamicMeshLandClaimOnly` left at `true`, that work is limited to claimed areas, which is what you want. Turning it off everywhere saves some CPU; turning `LandClaimOnly` off makes things worse on an old server.

**Loot bags accumulate.** Killed zombies drop bags, and a long horde leaves many of them. They count as items and entities until they despawn. It is not usually the main cost, but on a busy night it adds up, and `Items` in the stats line shows it.

None of this is a reason to tell players how to build. It is a reason to know where to look when one base's defence makes everybody's night stutter.

#### The settings changes that help most

In order of how much they help and how little players notice:

1. **Restart before the horde.** Memory grows across a week on most 7 Days servers. A restart in the afternoon of blood moon day, with a warning, starts the horde with a clean heap. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers choosing the hour. With `BloodMoonRange` at `0` this is easy to schedule, because the horde is always on a multiple of `BloodMoonFrequency`.
2. **Defend together.** Not a setting, but worth more than any.
3. **Lower `BloodMoonEnemyCount`, not `MaxSpawnedZombies`.** For eight players, 6 each is 48 alive rather than 64, spread evenly across bases. Lowering the global cap instead means whichever base spawns first takes the budget.
4. **Use speed and difficulty for challenge.** `ZombieBMMove` at `4` with 6 per player is a harder night than `3` with 12 per player, and it is cheaper.
5. **Keep `DayNightLength` reasonable.** Ninety minutes is a common compromise for evening groups. Very long days stretch horde load across an hour of real time.
6. **Check the plan.** If `FPS` falls on a clean, recently restarted server with a modest horde and one base, the CPU share is the limit. The rule in [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) applies: check which resource is at its limit before buying more of the other.

A sensible starting point for different groups:

| Group | `BloodMoonEnemyCount` | `MaxSpawnedZombies` | `ZombieBMMove` |
| --- | --- | --- | --- |
| 2-4 friends, relaxed | `8` | `64` | `2` |
| 4-6 players, standard | `8` | `64` | `3` |
| 8 players, one shared base | `6` | `64` | `3` |
| 8+ players, several bases | `4` | `64` | `3` |
| Small group wanting pain | `12` | `64` | `4` |

#### Scheduling around horde night

On a server with a fixed blood moon every seven days, the useful automation is simple. Restart a few hours before, save and back up the morning after.

On RE:NODE the Schedules tab takes a cron expression and a list of ordered tasks with delays. A pre-horde schedule might be: a console command `say "Restart in 5 minutes for horde night"`, a five-minute delay, `saveworld`, a short delay, then a restart power action. A morning-after schedule: `saveworld`, a delay, then a backup. The panel's Restart sends a clean stop, so the world is written before the process exits, and if a horde ever does push the server to its memory limit it is stopped and restarted clean rather than left swapping - which is better than the alternative, but is still a stop without a save, so the pre-horde restart is the thing to rely on. [Cron expressions explained](https://www.renode.space/blog/cron-expressions-explained) has the syntax.

Matching a schedule to the game calendar takes a little arithmetic. Game days do not line up with real days, so a fixed weekly cron entry will drift relative to blood moons unless the group plays at predictable times. Most groups end up with a daily restart at an hour nobody plays, which covers horde night along with every other night.

#### Troubleshooting

**Zombies rubber-band and teleport during the horde.** The server's `FPS` has dropped. Check the stats line. Lower the per-player count, get players into one base, restart before the next horde.

**The horde is smaller than the setting says.** `MaxSpawnedZombies` is capping it, or players are spread out and the budget is being shared with zombies around someone in the wilderness.

**The horde never arrived.** `BloodMoonFrequency` is `0`, or `BloodMoonRange` moved it. `gettime` shows the current day; count from there.

**The server crashed at the peak of the horde.** Look at `RSS` against the plan's limit in the lines before the crash. If it was close, it is memory: restart before hordes and consider the next plan. If memory was fine, read the last lines of the log for a mod error, which is the other common cause.

**Horde night is fine but day 1 of a fresh server lags.** That is world generation and first exploration, not the horde. See [7 Days to Die world generation](https://www.renode.space/blog/seven-days-to-die-world-generation-rwg).

**Lag continues after 04:00.** Leftover zombies and loot bags, or a collapse still settling. `le` shows what is still alive.

#### FAQ

##### Is BloodMoonEnemyCount per player?

Yes. It is the number alive at once for each player, so the total grows with the number of people online. `MaxSpawnedZombies` caps the total for the whole server.

##### What is a safe MaxSpawnedZombies value?

Leave it at 64 unless you have measured that the server holds a good simulation rate above it. Raising it is the most reliable way to make horde night lag, and a harder night is better achieved through speed and difficulty.

##### Why is horde night worse for us than for a friend's server with the same settings?

Base design and spread. Several separate bases mean several sieges, and tall structures that collapse in sections create bursts of physics and pathfinding work. More players than usual online on that night also multiplies the count.

##### Can I turn blood moons off?

Yes, `BloodMoonFrequency` set to `0`. Wandering hordes still happen. Many groups prefer a longer frequency, such as 14 days, to removing the event entirely.

##### How do I test the horde without waiting a week?

As an admin, use `settime` to move the clock to the evening of a blood moon day, play it, and watch the stats line in the console. Restore the clock afterwards, or do the test on a copy of the server.

##### Does a bigger plan fix horde lag?

Only if the server is actually short of CPU or memory. Read the stats line first. If `FPS` holds and players still lag, the problem is their connections or the base, and more resources will not change it.

7 Days to Die servers on RE:NODE start at 8 GB, with the live console showing the stats line as it is written, memory and CPU graphs against your limits, and a Schedules tab that can warn, save, restart and back up in order. CPU is a hard share of the cores you bought, and a server at 100% is slow, never suspended for it.

[See 7 Days to Die plans](https://www.renode.space/game-servers/7-days-to-die)

---

### 7 Days to Die overhaul mods on a server

Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/seven-days-to-die-overhaul-mods

An overhaul mod for 7 Days to Die is a whole different game wearing the same engine: new items, recipes, zombies, classes, progression and often new world generation. Darkness Falls, Undead Legacy, Rebirth, Ravenhearst and War3zuk's all-in-one are the well-known ones. Running one on a dedicated server is not hard, but it has five rules that a small modlet does not. The server must run exactly the game version the overhaul was built for. Easy Anti-Cheat must be off. Every player must install the same overhaul at the same version. You almost always start a new world and save. And you should plan for 2-4 GB more memory than vanilla. Get those five right and the rest is following the mod's own instructions.

This guide covers what makes an overhaul different from a modlet, the main ones and how they differ for a server owner, the install, getting players onto the same version, pinning the game so an update does not break the server, and the failures you will actually see. For small modlets, XPath patching and load order, see [the admin commands and modlets guide](https://www.renode.space/blog/seven-days-to-die-admin-commands-and-mods).

#### What makes an overhaul different from a modlet

7 Days to Die mods are folders in a `Mods` directory, each with a `ModInfo.xml`. A modlet is usually small: a handful of XML patches to loot, recipes or spawns, often working with nobody installing anything on their client because the server sends its XML configuration to joining players.

An overhaul is the same mechanism at a scale that changes the rules:

- **It ships code.** Almost every overhaul includes compiled `.dll` files that patch the game at runtime with Harmony. Code is the reason EAC has to be off, and the reason the mod only works on the exact game build it was compiled against.
- **It ships assets.** New models, icons, sounds, UI and blocks live in Unity asset bundles. Assets cannot be sent from the server, so every client has to have them.
- **It rewrites progression.** Skill trees, crafting stations, loot tiers and zombie lists are replaced wholesale, not adjusted. A save made with vanilla progression does not translate.
- **It often changes world generation.** Custom POIs, biome rules or extra prefabs mean a random world built without the mod lacks things the mod expects to exist.
- **It usually has dependencies.** Many overhauls build on shared libraries - `0-SCore` is the common one - and ship them inside their download. Do not mix in a separately downloaded copy of a library the overhaul already includes.

That is why an overhaul is a server decision taken at the start of a season, not something added on a Tuesday.

#### The main overhauls, for a server owner

Each of these is maintained by its own author or team, on its own schedule. Which game version each supports changes over time, so the first job is always the mod's own page.

| Overhaul | Character | Server notes |
| --- | --- | --- |
| Darkness Falls | Harder, darker, classes and new enemies | Long-running, popular for groups; needs a new world |
| Undead Legacy | Deep crafting and item overhaul | Very large content set; has historically trailed game releases |
| Rebirth | Big, current-feeling overhaul with many systems | Large download for clients; heavy on memory |
| Ravenhearst | Long, grindy progression and new POIs | Built for long seasons; custom world content |
| War3zuk AIO | Large all-in-one content collection | Very large; budget memory and disk generously |

Some practical differences matter more than the feature lists.

**Pace of updates.** When the game ships a major version, each overhaul has to be reworked, and some take weeks or months. If your group wants a specific overhaul, the game version you run is chosen by that overhaul, not by Steam. A server on the newest game build may simply have no compatible version of the mod you want yet.

**Download size.** Some overhauls are a few hundred megabytes; the biggest are several gigabytes. Every player downloads it, and the server needs the space for the mod, a larger save and backups of both.

**Distribution.** Several overhauls are installed through a community launcher - the 7D2D Mod Launcher is the long-standing one - which creates a separate copy of the game with the mod applied, so a player's vanilla install stays clean. Others are a zip you extract into the `Mods` folder. Find out which your choice uses before you tell players how to join.

#### Requirements: memory, CPU and disk

| Setup | RAM | Disk | Notes |
| --- | --- | --- | --- |
| Vanilla, 6k world, 4 players | 8 GB | 40 GB | The baseline |
| Light overhaul, 8k world, 4-6 players | 10-12 GB | 55 GB | More items and entities |
| Large overhaul, 8k world, 6-8 players | 12-14 GB | 70 GB | Assets and extra systems |
| Largest overhauls, 10k world, 8+ | 14 GB and up | 80 GB and up | Test before promising a full server |

Overhauls cost memory in three places: the extra assets and definitions loaded at start, larger and more varied zombie and loot tables in play, and more complex systems running per tick. They cost CPU mostly through the horde, because many overhauls add tougher and more varied enemies, and [horde night](https://www.renode.space/blog/seven-days-to-die-blood-moon-and-performance) is where that shows. The first start of an overhauled server is also slower than vanilla, especially when it is also generating a random world, so expect a long wait and watch the console rather than the clock.

7 Days to Die plans on RE:NODE run from 8 GB to 14 GB with up to 100 GB of NVMe, which covers most overhauls for a group. For the very largest packs with a full public server, measure on a test run before committing to a player count.

#### Installing an overhaul on the server

The steps below are the general shape. If the overhaul's own instructions differ, theirs win.

1. **Check the version.** Read the overhaul's page for the exact game build it targets. Check the server's build with `version` in the console. If they do not match, pin the server first (next section).
2. **Back up.** Take a backup of the whole server - install, `Mods` and the user data folder with saves. On RE:NODE, lock it so it survives rotation; you will want it if the season goes wrong.
3. **Stop the server.**
4. **Clear the old `Mods` folder.** Move any existing modlets out. Overhauls are tested alone, and mixing them with random modlets is how you get errors nobody can help with.
5. **Upload the overhaul.** Most ship a `Mods` folder containing several subfolders. Those subfolders go directly inside the server's `Mods` directory, each with its `ModInfo.xml` at its own top level. Upload as a zip and unpack it on the server if you can; it is much faster than thousands of small files over SFTP.
6. **Turn off EAC.** Set `EACEnabled` to `false` in `serverconfig.xml`.
7. **Start a new save.** New `GameName`, and a new world if the overhaul changes generation or POIs - which most do. `GameWorld` `RWG` with a new seed is the usual choice.
8. **Start and read the log.** Let it generate. Then read the startup output for every mod loading and for red errors.

```text
Mods/
  0-SCore/
    ModInfo.xml
  0-OverhaulCore/
    ModInfo.xml
    Config/
    Resources/
  1-OverhaulPOIs/
    ModInfo.xml
    Prefabs/
```

The numbered prefixes in folder names are deliberate. Mods load in alphabetical folder order, and overhaul authors use the prefixes to make libraries load before the content that depends on them. Do not rename them.

serverconfig.xml:

```xml
<property name="EACEnabled" value="false"/>
<property name="GameWorld"  value="RWG"/>
<property name="WorldGenSeed" value="Darkness Season 1"/>
<property name="WorldGenSize" value="8192"/>
<property name="GameName"   value="DFSeason1"/>
```

> [!WARNING]
> Never install an overhaul onto an existing vanilla save, and never remove one from a save made with it. Blocks, items and entities the save references stop existing, and the result ranges from vanishing bases to regions that will not load. An overhaul is a new season. Keep the old season's backup and treat the two as separate worlds.

Some overhauls publish a separate server package or say which folders are only needed on clients. If yours does, use it: a server does not need client-only UI and audio, and a smaller `Mods` folder starts faster.

#### EAC, and what turning it off means

`EACEnabled` set to `false` is not optional for a code-based overhaul. The overhaul's `.dll` files patch the game in a way Easy Anti-Cheat exists to block, and with EAC on the server will either refuse the mod or kick clients that load it.

Players have to start the game with EAC off too. The game's own launcher has an option to start without EAC; with a community mod launcher, the modded copy normally starts without it.

The cost is real. EAC is the game's main defence against client-side cheats - flying, spawning items, seeing through walls. On a private server for a group who know each other, that cost is close to zero. On a public overhaul server, it means your defence is moderation and logs. Use a password or a whitelist via `serveradmin.xml` for anything that is not genuinely public, and see [server rules, moderation and staff](https://www.renode.space/blog/server-rules-moderation-and-staff) for the moderation side.

#### Getting every player onto the same version

The commonest overhaul problem is not the server. It is one player with a different version of the mod.

- **Publish the exact version.** Pin a message in your Discord with the overhaul name, version number and the game build it runs on, and update it every time you update the server.
- **Prefer one source.** If the overhaul uses a launcher, point everyone to it. If it is a zip, link the exact release you installed, not the mod's front page, which will move on.
- **Update together.** When the overhaul releases an update, players must update at the same time as the server. Announce a time, update the server, and expect a wave of "cannot join" messages from people who did not read the announcement.
- **Check mid-season updates.** Many overhaul updates are save-compatible within a version line; some are not. The author's changelog says which. If it says a new game is required, it means it.

What a mismatch looks like depends on what differs. Missing assets show as errors on load or a kick with a mismatch message; mismatched XML often lets the player in and then fails in odd ways - items that cannot be crafted, recipes that do not appear, crashes when looking at something specific. If one player has strange problems that nobody else has, compare their mod version before debugging anything else.

#### Pinning the game version

Overhauls are compiled for one game build. When Steam updates the game, the server updates with it unless you stop it, and the overhaul breaks until its author catches up - which can take a long time after a major release.

The fix is to pin the server to a branch. 7 Days to Die publishes older versions as beta branches, and SteamCMD can install one:

```bash
$ steamcmd +force_install_dir /home/7dtd/server +login your_spare_account \
    +app_update 294420 -beta <branch_name> validate +quit
```

Branch names change as versions come and go, so read the list from the game's Betas tab in the Steam client or from the overhaul's instructions, which usually name the branch to use. Players have to select the same branch in their own Steam client. [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers branches, `validate` and update scripts in detail.

On a panel-based host, the branch is normally a variable on the Startup tab rather than a command you type, and an automatic update on restart has to be off - or set to the pinned branch - for a modded server. Check both before your first scheduled restart, not after it.

#### Testing an overhaul before launch night

Launching an overhaul for a group without a test run is how you spend launch night reading logs.

1. Install it and start the server with only yourself online.
2. Read the whole startup log. Every mod should report loading; search for `ERR` and `Exception`.
3. Join from a client with the same version. Craft something from the overhaul's early tiers, open its new menus, and walk into a POI the mod adds.
4. Run a blood moon with `settime` and watch the server's stats line in the console - the [blood moon guide](https://www.renode.space/blog/seven-days-to-die-blood-moon-and-performance) explains how to read it.
5. Stop with `shutdown`, start again, and confirm the save loads with your progress.
6. Take a backup, and restore it once to make sure it works.

If you can, do this on a separate test server so the real one is untouched until launch. [Keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) covers the wider habits, and [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is the routine for the day the overhaul and the game disagree.

#### Troubleshooting

**The server starts but the overhaul is not active.** The folders are nested one level too deep. Each mod folder with its `ModInfo.xml` must sit directly inside `Mods/`, not inside `Mods/Overhaul/Mods/`.

**Red XML errors at startup.** Usually a version mismatch between overhaul and game, or a leftover modlet patching something the overhaul removed. Check the version first, then empty the `Mods` folder except for the overhaul.

**Exceptions mentioning Harmony or a mod's DLL.** The game build does not match the one the code was compiled for. Pin the server to the right branch.

**Players are kicked immediately.** EAC is still on, on the server or on their client, or their mod version differs.

**Some players have broken recipes or missing items.** Their mod version differs from the server's, or they have an extra modlet locally. Compare versions.

**The first start takes a very long time and then restarts.** Generating a world with a large overhaul uses more memory than running it. If it reached the plan's memory limit, it was stopped and restarted. Generate with nobody online, use a smaller world, or move up a plan; on RE:NODE a plan change keeps the same server and files.

**Everything broke after a Steam update.** The server updated past the overhaul's supported build. Restore the backup, pin the branch, and turn off automatic updates.

#### FAQ

##### Can I add Darkness Falls to our existing world?

No. Overhauls replace progression, items and usually world content, so they need a new save and normally a new world. Keep the old world's backup if you want to go back to it.

##### Do players need to install the overhaul?

Yes. Overhauls include assets and code, which cannot be sent from the server. Every player needs the same overhaul at the same version, usually through the mod's launcher or its release zip.

##### Can I run an overhaul with EAC on?

Not one that includes code, and almost all do. Set `EACEnabled` to `false` and have players start without EAC. Protect the server with a password or whitelist instead.

##### Can I combine two overhauls?

Generally no. Each replaces the same core systems, and they are not tested together. Pick one. Small modlets on top are sometimes supported by the overhaul's author; if they publish a list of compatible add-ons, stay inside it.

##### How much more memory does an overhaul need?

Plan for 2-4 GB above what the same world would need in vanilla, more for the largest packs. Generation of a new world with an overhaul is the peak, so leave headroom for the first start.

##### What happens when the game updates?

If the server updates past the build the overhaul supports, the overhaul breaks. Pin the server to the branch the mod names, keep automatic updates off, and move to a new game version only when the overhaul announces support for it.

7 Days to Die servers on RE:NODE run from 8 to 14 GB with up to 100 GB of NVMe, room for an overhaul, its world and backups. Mods are yours to upload through SFTP or the file manager, which unpacks archives in place; there is no whitelist of allowed mods, and backups can be locked so last season's world survives. The install takes your Steam login on the Setup tab - use a spare account.

[See 7 Days to Die plans](https://www.renode.space/game-servers/7-days-to-die)

---

### 7 Days to Die world generation and RWG

Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/seven-days-to-die-world-generation-rwg

A 7 Days to Die server builds its map from three lines in `serverconfig.xml`: `GameWorld` picks Navezgane, a random world (`RWG`) or a world folder you already have; `WorldGenSeed` and `WorldGenSize` describe the random world to build. The same seed at the same size on the same game version gives the same map. A 6k world generates in a few minutes and suits up to about four players; 8k is the sweet spot for a group of six to eight; 10k is for a public server that can afford the memory and the long first start. The most reliable way to get a map you actually like is to generate it in the game client, where you can preview it and tune towns and terrain, and upload the folder to the server.

This guide covers how generation works, what each size costs, the settings the server exposes and the ones it does not, how to bring a client-made world onto a server, and the mistakes that leave a group on a fresh map they did not ask for. For the rest of the config file, see [7 Days to Die server settings](https://www.renode.space/blog/seven-days-to-die-server-settings).

#### World and save: two different things

Everything about map handling makes sense once you hold two folders apart.

- **The world** is the terrain: a heightmap, biome and splat images, water data and a list of every point of interest (POI) placed on it. For a random world it lives in `GeneratedWorlds/<World Name>/` under the server's user data folder. Navezgane and any shipped pregenerated worlds live in the install, under `Data/Worlds/`. The world never changes while you play.
- **The save** is everything players did to it: broken blocks, bases, loot taken, the clock, quests, land claims and player files. It lives in `Saves/<World Name>/<GameName>/`.

`GameWorld` chooses the world. `GameName` chooses the save inside it. That split is what lets you wipe a server without regenerating the map (new `GameName`, same world), and regenerate the map without losing the old one (new seed, old world folder stays on disk until you delete it).

```diagram
title: How serverconfig.xml picks a map and a save
cfg = serverconfig.xml | GameWorld, seed, size
rwg = Generator | runs once per seed
world = GeneratedWorlds | terrain and POIs
save = Saves folder | world name / GameName
server = Running server
cfg -> rwg : GameWorld RWG
rwg -> world : first start only
world -> server
save <-> server : regions, players
```

A random world's folder name is not the seed. The generator turns seed and size into a name - two or three made-up words, often ending in something like "Territory" or "County" - and prints it in the log on first start. Note it down. It is the name of the folder you will be backing up, and the name to put in `GameWorld` if you ever want to pin the server to that exact world.

#### Navezgane, RWG or a pregenerated world

| Option | Size | Strengths | Weaknesses |
| --- | --- | --- | --- |
| `Navezgane` | Roughly 6k | Hand-built, tested, instant start, players know it | Same map every time, small |
| `RWG` | You choose | New map per seed, any supported size | Long first start, quality varies by seed |
| Shipped pregenerated world | Fixed | No generation wait, reasonable layouts | Fewer choices, still random-built |
| A world you generated and uploaded | Your choice | Previewed and tuned before players see it | Needs an upload step |

Navezgane is the hand-made map the game was designed around. It is compact, its towns are placed with some thought, and it starts immediately because there is nothing to generate. For a group of three or four who want a familiar map and a quick start, it is a perfectly good answer, and it has the lowest memory and disk footprint of any option.

`RWG` is what most servers run, because a new map is half the point of a new season. Its weakness is that the generator is a generator: some seeds put the only trader in a corner, scatter towns thinly, or give you a desert where everyone wanted forest. On a client you can look at the result before committing. On a headless server you find out when players do.

Recent versions also ship a few pregenerated random worlds in `Data/Worlds/`, with names beginning `Pregen`. Their exact names and sizes change between releases, so look in that folder on your install rather than copying a name from a guide. Setting `GameWorld` to one of those names skips generation entirely.

#### Map size: memory, disk and how long the first start takes

`WorldGenSize` is the edge length of the square map in blocks. The comment in the shipped config describes the officially supported range as 6144 to 10240, in multiples of 2048 - so `6144`, `8192` and `10240`. Larger values are accepted by some builds and are entirely at your own risk: generation time, memory and the chance of a broken world all grow faster than the map does.

| `WorldGenSize` | Area vs 6k | Typical group | First start | Running RAM |
| --- | --- | --- | --- | --- |
| `6144` | 1x | 1-4 players | A few minutes | 8 GB |
| `8192` | 1.8x | 4-8 players | Noticeably longer | 10-12 GB |
| `10240` | 2.8x | 8+ players, public | Can run well past ten minutes | 12-14 GB |

The times depend heavily on CPU speed and game version, so treat them as relative rather than promised. Three practical points follow from the table.

**Generation is a memory spike.** Building the world needs more memory than running it, because the generator holds whole-map images and the POI layout in memory at once. A server that runs a 10k world comfortably in 12 GB can still be stopped during generation if it is close to its limit. If that happens on RE:NODE, the container is stopped at the limit and restarted clean, which mid-generation means starting the generation again. Generate the world with the server otherwise idle and nobody connected.

**Do not interrupt it.** The log goes quiet for long stretches while the generator works, and the instinct is to assume it has hung. It has not. Stopping half-way leaves a partial folder that may load and be wrong, or not load at all. Watch the console until the log reports the world loaded and the server is accepting connections.

**Bigger is not more content per player.** A 10k map has more towns, but the players are the same people, and they spread out further. Spread is what costs a 7 Days server, because every player keeps their own set of chunks awake. For a group of five, an 8k world means you meet each other; a 10k world means four separate servers that happen to share a chat.

Disk is less dramatic than memory. The generated world folder is modest. The save is what grows, through region files written only for areas players have actually visited, so a well-travelled 10k world reaches several gigabytes over a season while a barely explored one stays small.

#### The generation settings the server exposes

On a dedicated server, generation is controlled by just these properties:

serverconfig.xml:

```xml
<property name="GameWorld"      value="RWG"/>
<property name="WorldGenSeed"   value="Thursday Season 4"/>
<property name="WorldGenSize"   value="8192"/>
<property name="GameName"       value="Season4"/>
```

| Property | Default | What it does |
| --- | --- | --- |
| `GameWorld` | `Navezgane` | `RWG` to generate, or the name of an existing world folder |
| `WorldGenSeed` | - | Any string. Same seed and size on the same build, same world |
| `WorldGenSize` | `6144` | Edge length in blocks, only used for `RWG` |
| `GameName` | - | The save inside the world |

The seed is a string, not a number, so `Thursday Season 4` is a perfectly good seed. Spaces and capitals matter: `thursday season 4` is a different map.

What the server does not expose is everything the client's world generator lets you choose: town count, wilderness POI density, rivers, lakes, craters, cracks, and the balance of plains, hills and mountains. A server generating from `RWG` uses the defaults defined in `Data/Config/rwgmixer.xml`. You can change those defaults with a modlet that patches `rwgmixer.xml`, the same XPath mechanism described in [the admin commands and modlets guide](https://www.renode.space/blog/seven-days-to-die-admin-commands-and-mods), but it is a blunt instrument for something the client does with sliders and a preview.

> [!WARNING]
> Changing `WorldGenSeed` or `WorldGenSize` on a server with `GameWorld` set to `RWG` does not edit the current map. On the next start the server generates a brand new world under a new name, and loads a save for it. Your group's old world and save are still on disk, untouched, which is good, but everyone will log in at a fresh spawn with nothing.

#### Generating in the client and uploading the world

This is the method worth learning, because it gives you a map you have looked at before anyone plays it.

1. In the game client, go to the new game screen and open the world generator. Enter a seed, choose the size, and set towns, wilderness, rivers, lakes and terrain to taste.
2. Generate it and look at the preview map. Check the things that matter for a group: whether there is a trader near the middle, whether the starting area is forest rather than wasteland, whether towns are spread or clumped. If you dislike it, change the seed and generate again. It costs you minutes, not a server restart.
3. Find the result on your PC. On Windows the client writes to `%APPDATA%\7DaysToDie\GeneratedWorlds\<World Name>\`.
4. Stop the server. Upload that whole folder into the server's `GeneratedWorlds/` directory, keeping the folder name exactly as it is. SFTP is the sensible way to move a folder of this size; [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) has the connection details.
5. Set `GameWorld` to the folder name, set a new `GameName`, and start the server.
6. Watch the log for the world loading under that name. If it starts generating instead, the name does not match the folder.

serverconfig.xml:

```xml
<property name="GameWorld" value="East Nikazohi Territory"/>
<property name="GameName"  value="Season4"/>
```

Two details catch people. The game version that generated the world and the version running it should match; a world made on an older build may load on a newer one, but POI layouts and world file formats do change between major versions, and a mismatch shows up as missing or broken buildings. And once `GameWorld` names a folder rather than `RWG`, the seed and size properties are ignored, so do not change them expecting an effect.

On RE:NODE the file manager unpacks archives in place, so you can also zip the world folder on your PC, upload one file and extract it on the server, which is faster than uploading thousands of small files individually.

#### Biomes, traders and what makes a seed good

A random world is assembled from biomes - pine forest, burnt forest, desert, snow and wasteland - with towns and POIs placed on top. Since 1.0, biomes carry difficulty: harder biomes have tougher spawns and better loot, and recent versions add biome hazards that need gear or buffs to survive for long. That makes the layout matter more than it used to. A seed that spawns half the group in snow and half in forest is a seed where the first week plays very differently for different people.

What to check in a preview before committing:

- **Traders.** Quests and the early economy run through traders, and the generator places them in towns. A map with a trader within reasonable reach of the likely spawn area plays far better for a group than one where the first trip is a two-day walk.
- **Starting biome.** Forest is the forgiving start. Look at where the spawn points sit relative to biome borders.
- **Town distribution.** Clumped towns concentrate players, which is cheap for the server and good for a social group. Scattered towns spread them out, which costs memory and makes the map feel empty.
- **Water and roads.** Long stretches without either make vehicles miserable before they are available and repetitive after.

None of this can be tuned on a headless `RWG` start, which is the whole argument for generating in the client.

#### Exploration cost, pregenerating and keeping the world healthy

The map exists as a design from the moment generation finishes, but chunks are only built and saved as players visit them. That has two consequences.

The first time anybody walks into an area, the server creates those chunks, populates POIs and writes new region files. On a fresh server where everybody runs off in different directions, the first couple of evenings are the heaviest the server will see outside horde night. It settles once the commonly travelled areas exist.

7 Days to Die has a `visitmap` console command that walks the server through an area and generates its chunks ahead of time, much as Chunky does for Minecraft. It is useful for rendering a full web map with the dashboard, and occasionally for smoothing out a launch. It is also slow, it writes region files for the entire area, and a full 10k map pregenerated this way is many gigabytes of save before anybody has built a thing. Run `help visitmap` on your build for its exact syntax, and use it on a part of the map rather than all of it unless you have a reason.

Two settings help a mature world:

| Property | Default | What it does |
| --- | --- | --- |
| `MaxUncoveredMapChunksPerPlayer` | `131072` | Cap on each player's revealed map, which is stored in their player file |
| `ServerMaxWorldTransferSpeedKiBs` | `512` | How fast explored world data is sent to a joining player |

On a big, well-explored world, new players can take a long time to join because they are being sent a lot of world. Raising the transfer speed helps if the server has the uplink and the player has the connection.

Region files are where world damage happens. Each `.7rg` file covers a square of the map, and a server killed mid-write can leave one damaged, which appears as a specific area that crashes anyone who walks into it while the rest of the map is fine. Stop the server with `shutdown` or the panel's Stop, never by killing it, and keep backups you can browse file by file so you can restore one region rather than the whole season.

#### Wipes, new seasons and keeping the old world

Because world and save are separate, there are three kinds of reset, and they are worth naming before a group argues about which one they meant.

| Reset | Change | Result |
| --- | --- | --- |
| Save wipe, same map | New `GameName` | Same terrain, fresh POIs and loot, everyone starts over |
| New map | New seed, or a new uploaded world, plus new `GameName` | New terrain and a fresh save |
| Player wipe only | Delete the save's `Player` folder | Same world state, characters reset, rarely what anyone wants |

The safe routine for a new season:

1. Announce it, with a date.
2. On the day, run `saveworld`, then stop the server.
3. Take a backup of the old world folder and the old save folder together, and lock it so rotation does not remove it. On RE:NODE, backups can be locked against rotation for exactly this.
4. Change `GameName`, and the seed or `GameWorld` if the map is changing.
5. Start the server, let the world generate or load, and join once yourself before telling anyone it is open.
6. Once you are sure nobody wants anything from the old season, delete the old save and world folders to reclaim disk.

Keeping last season's world is cheaper than it looks and occasionally priceless - for the player who swears their base had a chest you are now being asked to recreate, or for a "finale weekend" on the old map. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) covers why you should test that a backup like this opens before you need it.

#### Troubleshooting

**The server has been "stuck" for fifteen minutes on first start.** It is generating. Large worlds on modest CPUs take a long time. Watch the console; it will report the world loading when it is done.

**The server restarted during generation and started again.** It reached its memory limit. Make sure nothing else is happening, try again, and consider a smaller size or a world generated on your PC and uploaded instead.

**Everyone spawned on a fresh map after a config change.** Seed, size or `GameWorld` changed, so a new world and save loaded. The old ones are still on disk. Put the old values back, or set `GameWorld` to the old world's folder name.

**The uploaded world generates a new map instead of loading.** The `GameWorld` value does not match the folder name exactly, including spaces and capitals, or the folder was uploaded one level too deep (`GeneratedWorlds/Name/Name/`).

**Buildings are missing or half-built in an uploaded world.** The world was generated on a different game version. Generate it again on the version the server runs.

**One area crashes players who walk into it.** A damaged region file. Restore that `.7rg` from a backup.

**Joining takes minutes on an old server.** Players are downloading explored world data. Raise `ServerMaxWorldTransferSpeedKiBs`, and consider whether a long-running world is due a new season.

#### FAQ

##### What is the best map size for a 7 Days to Die server?

8192 for most groups of four to eight. It has enough towns and traders that the map does not run out, while keeping players close enough to meet. 6144 or Navezgane suits small groups and smaller plans; 10240 is for public servers with the memory to carry it.

##### Will the same seed give me the same map as a friend's game?

On the same game version and the same size, yes for a world generated on the server from `RWG`. A world generated in the client also depends on the sliders chosen there, so a client world only matches if those settings match too. Across major versions the generator changes and the same seed produces a different map.

##### Can I make an existing world bigger?

No. Size is fixed at generation. A larger world is a new world, which means a new save for it. Your current world stays on disk so the change can be undone.

##### Can I set town count or terrain on a headless server?

Not through `serverconfig.xml`. The server uses the defaults in `rwgmixer.xml`. Either patch that file with a modlet, or generate the world in the client with the options you want and upload the folder.

##### Is Navezgane worse than a random world?

Not worse, just known. It is hand-designed, compact and starts instantly, which suits small groups and short seasons. Its drawback is that everybody who has played the game before already knows where the good loot is.

##### How much disk does a world need?

The generated world itself is small. The save is what grows: region files appear as players explore, and a long season on a 10k map can reach several gigabytes. Budget for the save plus at least two backups of it.

7 Days to Die servers on RE:NODE start at 8 GB and go to 14 GB with 100 GB of NVMe, enough to generate a 10k world and keep last season's beside it. The file manager unpacks an uploaded world archive in place, SFTP is on every server, and backup slots can be locked so the old season survives rotation. The install takes your Steam login on the Setup tab - use a spare account.

[See 7 Days to Die plans](https://www.renode.space/game-servers/7-days-to-die)

---

### 7 Days to Die admin commands and modlets

Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/seven-days-to-die-admin-commands-and-mods

Administering a 7 Days to Die server comes down to two files and one console. `serveradmin.xml` decides who is an admin, who is banned, and which commands each permission level may run. The console - reachable from the game with `F1` as an admin, from telnet, or from your host's panel - runs the commands. Everything else, from horde night tuning to the loot table, is either a setting in `serverconfig.xml` or a modlet in the `Mods` folder.

This guide covers the permission system in detail, the remote paths and why one of them should never face the internet, the console commands that are actually useful, and how modlets work: where they go, how XPath patching applies them, what EAC blocks, and what happens to a world when you remove a mod that added blocks. For the settings file itself - world size, zombie counts, blood moon - see [7 Days to Die server settings](https://www.renode.space/blog/seven-days-to-die-server-settings).

#### Where admin lives: serveradmin.xml

The file sits in the server's user data folder, beside the saves, and its name comes from the `AdminFileName` property in `serverconfig.xml` (default `serveradmin.xml`). The folder itself is `UserDataFolder`, which on a Linux server defaults to `~/.local/share/7DaysToDie/` and on Windows to `%APPDATA%\7DaysToDie\`. If you cannot find it, set `UserDataFolder` explicitly in `serverconfig.xml` so you always know where it is.

A file for version 1.0 and later looks like this:

serveradmin.xml:

```xml
<adminTools>
    <admins>
        <user platform="Steam" userid="76561198000000000" permission_level="0" name="you" />
        <user platform="Steam" userid="76561198000000001" permission_level="100" name="a moderator" />
    </admins>
    <permissions>
        <permission cmd="kick" permission_level="100" />
        <permission cmd="ban" permission_level="100" />
        <permission cmd="say" permission_level="100" />
        <permission cmd="lp" permission_level="1000" />
    </permissions>
    <whitelist>
        <user platform="Steam" userid="76561198000000002" name="a friend" />
    </whitelist>
    <blacklist>
        <user platform="Steam" userid="76561198000000003" reason="griefing" />
    </blacklist>
</adminTools>
```

> [!WARNING]
> The element shape changed around Alpha 20, when crossplay made a plain Steam ID insufficient. Older guides show `<admin steamID="...">`, `<whitelisted>` and `<blacklisted>`; paste those into a current server and the section is ignored or the file fails to load. The safest way to write this file is to not write it: run `admin add`, `ban add` and `whitelist add` in the console once, then open the file and copy the shape the server produced.

`platform` is the account network - `Steam` for a Steam client, a different identifier for Epic, Xbox or PlayStation accounts on a crossplay server. `userid` is that platform's ID, a 17-digit number beginning `76561198` for Steam. `name` is a comment for you; it has no effect.

Use `lp` in the console to get the exact platform and ID for a connected player, rather than typing a Steam ID from a profile URL and hoping.

#### Permission levels, and the rule that trips people up

Levels run from 0 to 1000. **Lower is more powerful.** A player with no entry in `<admins>` is 1000.

- `0` is the owner level: every command, no exceptions.
- `1` to `999` is an admin who can be restricted by the `<permissions>` list.
- `1000` is an ordinary player.

The rule for whether a command runs is worth reading twice: a player may run any command whose required level is **greater than or equal to** their own. So a command listed at `permission_level="1000"` can be run by everybody, and a command listed at `permission_level="0"` can be run only by a level 0 admin. A command not listed in `<permissions>` at all defaults to level 0, which is why a fresh server lets nobody but the owner do anything.

That gives you a simple staffing model. Put your moderators at level 100 in `<admins>`, then list exactly the commands they need at 100:

| Command | Suggested level | Why |
| --- | --- | --- |
| `kick`, `ban`, `say`, `pm` | `100` | Moderation without world editing |
| `lp`, `lkp`, `gettime` | `1000` | Harmless information, fine for everyone |
| `give`, `giveself`, `cm`, `dm` | `0` | Item creation stays with the owner |
| `shutdown`, `setgamepref` | `0` | Anything that changes the server itself |

Changes to `serveradmin.xml` are picked up without a restart on current builds, but the console commands are still the reliable route, because they write and reload in one step.

#### Telnet, the control panel and the port you should not open

7 Days to Die ships its own remote admin interface, configured in `serverconfig.xml`:

| Property | Default | What it does |
| --- | --- | --- |
| `TelnetEnabled` | `true` | Turns the telnet console on |
| `TelnetPort` | `8081` | Where it listens |
| `TelnetPassword` | empty | Required for anything but a local connection |
| `TelnetFailedLoginLimit` | set | Failed attempts before an address is blocked |
| `TelnetFailedLoginsBlocktime` | set | How long that block lasts |
| `ControlPanelEnabled` | `false` | The built-in web panel |
| `ControlPanelPort` | `8080` | Its HTTP port |

Telnet is plain text. The password crosses the network unencrypted, every command is readable by anything on the path, and the protocol has no concept of a session key. It was designed for a control panel talking to a server on the same machine, and that is the only place it belongs. The same is true of the built-in web control panel, which is plain HTTP.

So: leave telnet enabled with a password, and do not expose port `8081` to the internet. If you need remote administration, use your host's console, which reaches the server over the local network rather than across the world. The general argument is in [RCON safely](https://www.renode.space/blog/rcon-safely) and the port-by-port version is in [firewall rules that matter](https://www.renode.space/blog/firewall-rules-that-matter).

The game ports themselves:

| Port | Protocol | Purpose |
| --- | --- | --- |
| `26900` | TCP and UDP | `ServerPort`, the main game and Steam port |
| `26901` | UDP | Game traffic |
| `26902` | UDP | Game traffic |
| `8081` | TCP | Telnet, local only |
| `8080` | TCP | Web control panel if enabled, local only |

Changing `ServerPort` moves the two UDP ports above it as well. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) covers why a game needs more than one and what breaks when only some of them are reachable.

#### The console commands worth knowing

There are well over a hundred. These are the ones you will use. Most have a short alias, given in brackets.

Moderation:

| Command | What it does |
| --- | --- |
| `admin add <name/id> <level>` | Adds an admin at a permission level |
| `admin remove <name/id>` | Removes one |
| `admin list` | Prints the admin list |
| `kick <name/id> [reason]` | Disconnects a player |
| `kickall [reason]` | Disconnects everybody, useful before a shutdown |
| `ban add <name/id> <duration> <unit> [reason]` | Bans, for example `ban add Bob 3 days "griefing"` |
| `ban remove <name/id>` | Lifts a ban |
| `ban list` | Prints the ban list |
| `whitelist add/remove/list` | Manages the whitelist |
| `say "message"` | Broadcasts to everyone |
| `pm <name> "message"` | Private message |

Information:

| Command | What it does |
| --- | --- |
| `listplayers` (`lp`) | Connected players with IDs, positions, health and ping |
| `listknownplayers` (`lkp`) | Everyone the server has ever seen |
| `listents` (`le`) | Every entity, which is how you find out what is eating the frame time |
| `gettime` (`gt`) | Current day and time |
| `getgamepref` (`gg`) | Every game preference and its current value |
| `mem` | Memory and object counts |
| `version` | Build version, the first thing to check against a mod |

World and players:

| Command | What it does |
| --- | --- |
| `settime <day> <hour> <minute>` (`st`) | Also accepts `day` and `night` |
| `teleportplayer <player> <x> <y> <z>` | Moves someone, or to another player's name |
| `tele <x> <y> <z>` | Moves you |
| `give <player> <item> <count> [quality]` | Gives an item by its internal name |
| `giveself <item> [quality] [count]` | Gives it to you |
| `giveselfxp <amount>` | Experience |
| `spawnentity <playerid> <entityid>` (`se`) | Spawns near a player |
| `spawnairdrop` | Drops a supply crate |
| `spawnwanderinghorde` (`swh`) | Sends a wandering horde |
| `buffplayer <player> <buff>` | Applies a buff, `debuffplayer` removes one |
| `creativemenu` (`cm`) | Opens the creative menu for your client |
| `debugmenu` (`dm`) | Debug mode for your client |

Server:

| Command | What it does |
| --- | --- |
| `saveworld` (`sa`) | Forces a save now |
| `shutdown` | Saves and exits cleanly |
| `setgamepref <pref> <value>` (`sg`) | Changes a game preference live |
| `help <command>` | The authoritative syntax for your build |

Two of those deserve more than a table row.

`shutdown` is the only correct way to stop a 7 Days to Die server. The world is stored as region files, and a process killed mid-write leaves one damaged - which shows up later as a specific area that crashes anyone who walks into it, not as an error at startup. Use the panel's Stop button, which sends a clean signal, or run `shutdown` first. Restoring a single damaged region from a backup is far quicker than restoring the world, so keep backups you can browse rather than only whole-world archives.

`setgamepref` changes a preference on the running server and does not write it to `serverconfig.xml`. That makes it perfect for an experiment - drop `BloodMoonEnemyCount` mid-week and see what the CPU does - and a trap for anything you want to keep, because the next restart reverts it. Some preferences are read only at world generation and will not change anything at all, whatever the console says. Check with `gg` after you set one.

#### Modlets: where they go and how they load

7 Days to Die has no workshop. Mods are folders you place in a `Mods` directory at the server root, next to `Data/` and the server binary. Create it if it does not exist. Each modlet is one subfolder with a `ModInfo.xml` at its root:

```text
Mods/
  MyTweaks/
    ModInfo.xml
    Config/
      blocks.xml
      loot.xml
  SomeUIMod/
    ModInfo.xml
    Config/
    Resources/
```

`ModInfo.xml` in 1.0 and later is flat:

Mods/MyTweaks/ModInfo.xml:

```xml
<?xml version="1.0" encoding="UTF-8" ?>
<xml>
    <Name value="MyTweaks" />
    <DisplayName value="My Tweaks" />
    <Version value="1.0.0" />
    <Description value="Small balance changes" />
    <Author value="you" />
    <Website value="" />
</xml>
```

Older modlets wrap all of that in a `<ModInfo>` element inside `<xml>`. The wrapper form stopped being the current one at 1.0, so a modlet that has not been touched since Alpha 21 may not be recognised at all. A mod that simply does not appear in the startup log is usually this, not a bad install.

Modlets load in alphabetical order of their folder names, and later patches beat earlier ones when both touch the same value. That is the whole load-order mechanism: if you need one modlet to win, rename its folder so it sorts last. Prefixes like `00_` and `zz_` are the community convention and they work because they are just filenames.

#### Writing and debugging an XPath patch

A modlet does not replace a vanilla config file; it patches one. Put a file in `Config/` with the same name as the vanilla file in `Data/Config/`, wrap the contents in `<configs>`, and describe the change:

Mods/MyTweaks/Config/blocks.xml:

```xml
<configs>
    <set xpath="/blocks/block[@name='BLOCK_NAME']/property[@name='MaxDamage']/@value">1200</set>

    <append xpath="/blocks">
        <block name="myNewBlock">
            <property name="Extends" value="BLOCK_TO_COPY" />
        </block>
    </append>

    <remove xpath="/blocks/block[@name='BLOCK_NAME']/property[@name='DowngradeBlock']" />
</configs>
```

The instructions available are `set`, `setattribute`, `removeattribute`, `append`, `insertBefore`, `insertAfter`, `remove` and `csv`. The xpath has to match the vanilla file exactly, so open `Data/Config/blocks.xml` on the server and copy the path out of it rather than guessing at element names.

The important debugging fact: a patch whose xpath matches nothing does not crash the server. It logs a warning and the game carries on with the original value. So a modlet that "does nothing" has almost always failed to apply, and the reason is in the server's output log, which the panel console shows at startup. Search it for the modlet's name; you will get either a line saying it loaded and applied, or a line saying a patch did not match.

This is also why version churn hurts. When a game update renames a property, every modlet that patched it silently stops working while appearing to be installed. After any update, read the startup log before you read the forums.

#### EAC, clients and what players have to install

`EACEnabled` in `serverconfig.xml` controls Easy Anti-Cheat. The rule of thumb:

- A modlet that is **only XML** normally runs with EAC enabled.
- A modlet that ships a **`.dll`** does not. Set `EACEnabled` to `false`, and players who need the client half have to start the game without EAC from the launcher.

Turning EAC off is a real cost, not a formality. It is what stops the common flying and item-spawn cheats, and on a public server you will notice. If you can get what you want from XML alone, do.

There is no automatic mod delivery to clients. Nothing subscribes players to anything, and nothing is pushed on connection. What each player needs depends on what the modlet changes:

- **Server only** is possible for things the server alone evaluates: loot table weights, spawning rules, quest rewards.
- **Both sides** is required for anything the client draws or predicts: new items, new blocks, recipes, icons, models, sounds, UI.

Assume both sides unless the author says otherwise, and hand players a zip of the exact `Mods` folder you are running, not a list of links. A player who downloads a newer version of one mod than the server has will fail in confusing ways rather than being told.

On a crossplay server this settles itself: console players cannot install anything, so a modded server that needs client files is a PC-only server whatever the crossplay setting says.

> [!WARNING]
> Removing a modlet that added blocks or items from a world that has already been played leaves that world referencing things that no longer exist. Best case the blocks vanish; worst case the region will not load. Decide your block-adding mods before launch, keep a backup from before every mod change, and see [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) for why an untested backup is only a hypothesis.

#### Troubleshooting

**Nothing I type in the console works.** You are not an admin, or you are an admin at a level above the command's requirement. Run `admin list` from the server console itself, which always has level 0.

**A ban did nothing.** You banned the player name on a server where they can reconnect under a different one. Ban the platform ID from `lp` instead.

**Telnet refuses my password.** `TelnetPassword` is empty, which allows local connections only, or the address is blocked after failed attempts - wait out `TelnetFailedLoginsBlocktime`.

**The modlet is in the folder and does nothing.** Three candidates, in order: the `ModInfo.xml` format is the old nested one; the folder structure is wrong, with the modlet nested one level too deep inside its download; or the xpath does not match. The startup log tells you which.

**Settings I changed in the console reverted.** `setgamepref` is session-only. Write it into `serverconfig.xml` too.

**A specific area crashes players.** A damaged region file, almost always from a server killed rather than shut down. Restore that region from a backup rather than the whole world.

**Performance collapses on horde night and not before.** That is the load test, and it is a sizing question rather than an admin one. `le` during the horde tells you how many entities are alive, and [7 Days to Die server settings](https://www.renode.space/blog/seven-days-to-die-server-settings) covers which numbers to cut.

#### FAQ

##### How do I make myself admin on a 7 Days to Die server?

From the server console, run `admin add <your platform id> 0`. Get the ID from `lp` while you are connected. Editing `serveradmin.xml` by hand works too, but the command writes it in the format your build expects.

##### What permission level should moderators have?

100 is the usual choice. It is well below the 1000 that ordinary players get and well above 0, so you can grant `kick`, `ban` and `say` at 100 in the `<permissions>` section while leaving item spawning and `shutdown` at 0.

##### Is it safe to open the telnet port?

No. Telnet sends the password and every command in clear text. Keep `TelnetEnabled` on with a password for local tools, keep port `8081` closed to the internet, and administer the server through your host's console instead.

##### Do my players need to install the mods?

Usually yes. There is no workshop and nothing is pushed to clients. Server-only modlets exist for loot and spawning rules, but anything that adds an item, block, recipe or icon has to be on both sides at the same version.

##### Can I run mods with EAC enabled?

XML-only modlets generally work with EAC on. Anything containing a compiled `.dll` needs `EACEnabled` set to `false` in `serverconfig.xml`, and affected players must launch without EAC as well.

##### Why did my modlet stop working after an update?

A game update renamed or moved whatever its xpath was pointing at, so the patch no longer matches and is skipped with a warning. Check the startup log, then check the mod's page for a build-specific release. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) has the wider routine.

7 Days to Die servers on RE:NODE start at 8 GB, with an unfiltered console for the commands above, SFTP and an in-browser editor for `serveradmin.xml` and the `Mods` folder, and backup slots that restore with a button. The install waits on the Setup tab for your Steam login, so use a spare account that owns the game.

[See 7 Days to Die plans](https://www.renode.space/game-servers/7-days-to-die)

---

### 7 Days to Die serverconfig.xml settings

Published 2026-07-31, updated 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/seven-days-to-die-server-settings

7 Days to Die keeps a voxel world that players are actively destroying, which is a harder problem than it looks. A server wants 8 GB to start and 12 or more once eight people are spread across a 10k random world, one fast core it can keep, and three ports. The settings that matter for performance are the ones that decide how much of that world is awake at once, and horde night is where every choice you made shows up in a single evening. This guide goes through the whole file - what each setting does, what it costs, the ports, the admin and telnet interfaces, modlets, and the specific way a 7 Days save goes bad.

#### What the dedicated server is, and what makes it heavy

The dedicated server is free and comes from SteamCMD as app id `294420`. It runs headless, loads one world and one save, and simulates it whether or not anybody is online.

Four things drive the load, and only one of them is player count:

1. **Loaded chunks.** Each player keeps a set of chunks around them alive. Eight players in one town are cheap; eight players in eight corners of a 10k map each hold their own working set, and the totals add up.
2. **Entities.** Zombies, animals and dropped items each tick. `MaxSpawnedZombies` is the single most important number on the server for this reason.
3. **The dynamic mesh.** Modern versions recalculate structural support and collapse for player-modified buildings in the background. It is the reason a server writes to disk constantly, and it can be narrowed or turned off.
4. **World size**, mostly at generation time and on disk. A 10k random world takes real time and real memory to build the first time, and then a large number of region files to store.

The world is generated once, into a `GeneratedWorlds` folder holding a heightmap, biome and splat images and a `prefabs.xml` listing every point of interest placed. The save that players affect is separate. Knowing the two are different is what lets you reset a server without regenerating the map, and regenerate the map without a fresh install.

#### Requirements and resource usage

| Setup | RAM | CPU | Disk |
| --- | --- | --- | --- |
| Navezgane or a 6k world, up to 4 players | 8 GB | 2 cores | 40 GB |
| 8k random world, 6-8 players | 10-12 GB | 2-3 cores | 55 GB |
| 10k world, 8+ players, spread out | 12-14 GB | 3 cores | 70 GB |
| Modlets, especially overhauls | add 2-4 GB | - | add 10 GB |

- **Generation is a spike.** Building a 10k random world on first start uses far more memory than running it, and takes long enough that people assume the server has hung. It has not. Generate the world once, then take a backup of it.
- **CPU**: the world simulation is dominated by one thread. Clock speed decides how many zombies can path at once, which is the same as saying it decides horde night.
- **Disk**: the install is around 20 GB, and the save grows with every block a player breaks. Region files for a well-travelled 10k world can reach several gigabytes.
- **Network**: the heaviest moment is a new player's first join, when the server streams the explored world to them.

#### Installing and starting the server

```bash
$ steamcmd +force_install_dir /home/7dtd/server +login anonymous \
    +app_update 294420 validate +quit
$ cd /home/7dtd/server
$ ./startserver.sh -configfile=serverconfig.xml
```

On Windows the same job is done by `startdedicated.bat`, which calls `7DaysToDieServer.exe` with the same argument. [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers branches and update scripts if you want to pin a version rather than take every update.

On RE:NODE the 7 Days to Die install asks for a Steam login on the Setup tab. The server is created straight away and the install waits for those credentials, which are stored as you type them - so use a spare Steam account rather than your main one.

#### serverconfig.xml: the settings that matter

The file is XML, one property per line, and it ships with a comment on nearly every entry. Do not delete the comments; they are the best documentation the game has.

serverconfig.xml:

```xml
<?xml version="1.0"?>
<ServerSettings>
  <property name="ServerName" value="Longship Crew"/>
  <property name="ServerPassword" value=""/>
  <property name="ServerMaxPlayerCount" value="8"/>
  <property name="ServerVisibility" value="2"/>
  <property name="ServerPort" value="26900"/>
  <property name="GameWorld" value="RWG"/>
  <property name="WorldGenSeed" value="Longship"/>
  <property name="WorldGenSize" value="8192"/>
  <property name="GameName" value="LongshipSave"/>
  <property name="GameDifficulty" value="2"/>
  <property name="DayNightLength" value="60"/>
  <property name="MaxSpawnedZombies" value="64"/>
  <property name="BloodMoonEnemyCount" value="8"/>
  <property name="EACEnabled" value="true"/>
</ServerSettings>
```

##### World and identity

| Property | Default | What it does |
| --- | --- | --- |
| `GameWorld` | `Navezgane` | `Navezgane`, `RWG`, or a pregenerated map named in the file |
| `WorldGenSeed` | - | Seed string for `RWG`. Same seed, same map |
| `WorldGenSize` | `6144` | A multiple of 2048 from 4096 to 16384. Only for `RWG` |
| `GameName` | - | The save name. Change it and you start a new save |
| `ServerMaxPlayerCount` | `8` | Player cap |
| `ServerVisibility` | `2` | `2` public, `1` friends, `0` unlisted |
| `ServerPort` | `26900` | Game port |
| `ServerPassword` | empty | Join password |

`GameWorld` and `GameName` together decide which save loads. Changing either starts a new one beside the old, which is both how you reset a server deliberately and how people lose a world by accident.

##### Difficulty and rates

| Property | Default | What it does |
| --- | --- | --- |
| `GameDifficulty` | `1` | `0` to `5`. Affects damage taken and dealt, not zombie count |
| `XPMultiplier` | `100` | Percent |
| `LootAbundance` | `100` | Percent |
| `LootRespawnDays` | `7` | Days before a looted container refills |
| `DayNightLength` | `60` | Real minutes per in-game day |
| `DayLightLength` | `18` | In-game hours of daylight |
| `DropOnDeath` | `1` | `0` nothing, `1` everything, `2` toolbelt, `3` backpack |
| `AirDropFrequency` | `72` | In-game hours. `0` disables |
| `PlayerKillingMode` | `3` | `0` no PvP through to `3` kill everyone |

`DayNightLength` is the setting groups argue about most and it costs nothing either way. Sixty minutes is the default; ninety gives a working day that fits an evening session, and it also stretches the week between blood moons by half.

##### Zombies and blood moon

| Property | Default | What it does |
| --- | --- | --- |
| `MaxSpawnedZombies` | `64` | Server-wide cap. The setting that saves you |
| `MaxSpawnedAnimals` | `50` | Server-wide cap for animals |
| `ZombieMove` | `0` | Day speed, `0` walk to `4` nightmare |
| `ZombieMoveNight` | `3` | Night speed |
| `ZombieFeralMove` | `3` | Feral speed |
| `ZombieBMMove` | `3` | Blood moon speed |
| `BloodMoonFrequency` | `7` | Days between blood moons. `0` disables |
| `BloodMoonRange` | `0` | Random variation in days around that frequency |
| `BloodMoonWarning` | `8` | Hour the sky turns red. `-1` for no warning |
| `BloodMoonEnemyCount` | `8` | Zombies alive at once **per player** |
| `EnemyDifficulty` | `0` | `0` normal, `1` feral |

##### Land claims, bases and decay

| Property | Default | What it does |
| --- | --- | --- |
| `LandClaimCount` | `3` | Claim blocks a player may have active |
| `LandClaimSize` | `41` | Blocks across, centred on the claim |
| `LandClaimDeadZone` | `30` | Minimum blocks between different players' claims |
| `LandClaimExpiryTime` | `7` | Days offline before a claim starts decaying |
| `LandClaimDecayMode` | `0` | How durability falls off after that |
| `LandClaimOnlineDurabilityModifier` | `4` | Block hardness inside a claim while the owner is online |
| `LandClaimOfflineDurabilityModifier` | `4` | The same while they are offline |
| `BedrollDeadZoneSize` | `15` | Blocks around a bedroll where zombies will not spawn |
| `BedrollExpiryTime` | `45` | Days before an unused bedroll stops counting |

##### Performance and housekeeping

| Property | Default | What it does |
| --- | --- | --- |
| `DynamicMeshEnabled` | `true` | Structural recalculation for player-changed buildings |
| `DynamicMeshLandClaimOnly` | `true` | Limit that work to claimed areas |
| `DynamicMeshLandClaimBuffer` | `3` | Chunk buffer around a claim |
| `DynamicMeshMaxItemCache` | `3` | How many mesh items are held in memory |
| `MaxUncoveredMapChunksPerPlayer` | `131072` | Cap on each player's revealed map |
| `ServerMaxWorldTransferSpeedKiBs` | `512` | Speed the world is sent to a joining player |
| `PersistentPlayerProfiles` | `false` | `true` means only known players may rejoin |
| `EACEnabled` | `true` | Easy Anti-Cheat. Must be `false` for most DLL mods |

`DynamicMeshLandClaimOnly` is the performance setting nobody mentions. Left on, the expensive structural work happens only around claimed bases. Turned off, it happens everywhere players have dug, which on a months-old server is most of the map.

#### Blood moon is the load test

Everything is fine until night seven, when the zombie count multiplies across every player at once. If the server is going to fall over, it will do it then. Size for the horde and the rest of the week takes care of itself.

The arithmetic is the part people get wrong. `BloodMoonEnemyCount` is **per player**: four players at eight each is thirty-two zombies, eight players at eight each is sixty-four, and eight players at sixteen each would be a hundred and twenty-eight. `MaxSpawnedZombies` caps the total for the whole server, so at its default of 64 that last configuration quietly becomes 64 anyway - and players who have been told the horde is bigger will report that the game is broken when it is only clamped.

> [!TIP]
> If horde night drops the server to a crawl, lower `BloodMoonEnemyCount` before you lower `MaxSpawnedZombies`. The first spreads the same zombies more evenly and keeps each base defensible; the second makes the whole night quieter in a way players notice.

Two more habits help. Ask players to fight the horde from bases reasonably close together, because four separate horde bases means four separate pathfinding problems running at once. And restart the server before horde night rather than after - memory use climbs across a week, and horde night is the worst moment to discover the limit. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers picking the hour, and on RE:NODE the Schedules tab will run it for you with a warning message first.

#### Ports, telnet and the web dashboard

| Port | Protocol | Purpose |
| --- | --- | --- |
| `26900` | TCP and UDP | Game traffic and server listing |
| `26901` | UDP | Game traffic |
| `26902` | UDP | Game traffic |
| `8081` | TCP | Telnet, if `TelnetEnabled` is true |
| `8080` | TCP | Web dashboard, if `WebDashboardEnabled` is true |

Port `26900` needs both TCP and UDP, which is unusual enough that it is worth checking rather than assuming - a UDP-only rule leaves the server unlistable. Some documentation extends the block to `26903`; opening `26900-26903` costs nothing and removes the question. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) covers why the listing and the game use different paths in the first place.

RE:NODE's 7 Days to Die plans come with two allocations, and the Network tab adds the rest - including a separate one if you want telnet or the dashboard reachable.

Telnet is the remote admin interface, and it is plain text: the password crosses the network in the clear, and anything typed into it has full server rights. If `TelnetPassword` is empty the server only listens on loopback, which is the safe default. If you open it, set a strong password, restrict the source address, and read [RCON safely](https://www.renode.space/blog/rcon-safely) first - the same reasoning applies to every remote console.

`WebDashboardEnabled` turns on a small web interface on port `8080`. `EnableMapRendering` makes it draw the explored map, which is genuinely nice and costs both CPU and a steadily growing folder of tiles.

#### Admins and console commands

Admin rights live in `serveradmin.xml` beside the config file. The server writes it on first start, and that generated file is the authority for the exact format - older versions identified people by a `steamID` attribute, and current versions use a platform and user id pair, because console players are on the same servers now.

serveradmin.xml:

```xml
<adminTools>
  <admins>
    <admin platform="Steam" userid="76561198012345678" permission_level="0" />
  </admins>
  <permissions>
    <permission cmd="dm" permission_level="0" />
  </permissions>
  <whitelist />
  <blacklist />
</adminTools>
```

Permission levels run from `0`, which is the owner and can do everything, to `1000`, which is every player. Each command has its own required level, so you can hand a moderator kick and ban without handing them the creative menu.

| Command | What it does |
| --- | --- |
| `help` | Lists commands, or explains one |
| `lp` | List connected players with ids and positions |
| `le` | List entities, including every zombie alive |
| `mem` | Memory use, entity and chunk counts |
| `saveworld` | Write the save immediately |
| `shutdown` | Save and stop cleanly |
| `kick <name>` | Disconnect a player |
| `ban add <name> <n> <unit>` | Ban for a period, unit in minutes, hours or days |
| `admin add <name> <level>` | Grant a permission level |
| `say "<text>"` | Speak to everyone as the server |
| `settime <day> <hour> <minute>` | Set the clock |
| `llp` | List land claims |
| `dm` | Toggle debug mode |

`mem` is the one to learn. It prints entity counts alongside memory, and an entity count that keeps climbing between restarts tells you something is not despawning - usually dropped bags or animals - long before the server runs out of memory. [Reading a server load graph](https://www.renode.space/blog/reading-a-server-load-graph) covers what the memory side of the same story looks like from outside.

#### Mods and modlets

Mods go in a `Mods` folder in the server root, one folder each, containing a `ModInfo.xml` and usually a `Config` directory of XML files that patch the game's own configuration with XPath operations. That design has an unusually pleasant consequence:

- **A modlet that only patches XML is server-side.** The server sends its configuration to joining clients, so a modlet that changes recipes, loot, spawns or progression works with nobody installing anything. This covers a large share of the popular quality-of-life mods.
- **A mod that adds assets or code is not.** New icons, models, sounds or a DLL mean every client must install it too, and `EACEnabled` must be `false` for anything using Harmony patching. Turning EAC off is a real trade - you are removing the anti-cheat to gain the mod.
- **Overhauls are both, plus a new world.** Darkness Falls and its peers expect a fresh save, not an existing one.

Add one modlet, restart, play an evening, add the next. It is slower than pasting a list and it is the only method that tells you which one broke the server, because the answer is always the last one you added. Every game update invalidates modlets until their authors catch up, so a modded server should not take updates automatically - [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) has the wider version of that argument, and [the admin commands and modlets guide](https://www.renode.space/blog/seven-days-to-die-admin-commands-and-mods) goes deeper into the XPath side.

#### Saves, region files and the slow corruption

The save lives under the user data folder, in `Saves/<World>/<GameName>/`: the game state, a `Player` folder with one file per person who has ever joined, and a `Region` folder of `.7rg` files, each covering a square of the map.

That last detail is the useful one. The world is not one file, it is hundreds, and a server killed mid-write can leave exactly one of them damaged. The symptom is odd and specific: a particular area that crashes clients who walk into it, while the rest of the map is fine. The repair is proportionate - restore that one `.7rg` from a backup and lose only what was built inside it, rather than rolling the whole world back.

- **Stop the server properly.** `shutdown`, or the panel's Stop, both of which save first. Killing the process is what damages region files in the first place.
- **Back up the whole save folder**, not just the region directory. The player files hold everybody's inventory and skill points, and restoring a world without them is its own disaster.
- **Test a restore once.** A backup nobody has restored is a hypothesis - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is the short version of why.
- **Keep a copy of the generated world too.** Regenerating from the same seed should produce the same map, but "should" is doing work in that sentence across game versions.

On RE:NODE, backup slots are on every 7 Days to Die plan, backups are stored off the machine they protect and can be locked against rotation, and the Schedules tab can run an ordered task list - a `saveworld` command, a short delay, then the backup. If the server ever reaches its memory limit the container is stopped and restarted clean rather than left to swap, which is safer than the alternative but is still an unsaved stop, so a nightly scheduled backup matters more on a server running near its ceiling.

#### Troubleshooting

**The server does not appear in the list.** Check `ServerVisibility` is `2`, check `26900` is open on both TCP and UDP, then wait a few minutes. Test by connecting directly to the address from the client's Connect to IP option; if that works, it is a listing problem, not a server problem.

**The first start takes forever.** Random world generation on a 10k map is slow. Watch the log rather than the clock, and let it finish - stopping halfway leaves a partial world that will have to be regenerated anyway.

**New players time out while joining.** They are downloading the explored world. Raise `ServerMaxWorldTransferSpeedKiBs` from its default of 512.

**Modded clients are kicked immediately.** Easy Anti-Cheat. Set `EACEnabled` to `false` if the mod needs it, and accept what that means.

**One area crashes everybody who enters it.** A damaged region file. Find the `.7rg` covering those coordinates and restore that one file.

**Memory climbs all week and the server dies on horde night.** Restart daily. 7 Days does not release everything it allocates, and horde night is the worst possible moment to find the limit.

**Players lost their characters after a config change.** `GameName` or `GameWorld` changed, so a new save loaded. The old save is still on disk under its own name.

#### FAQ

##### How much RAM does a 7 Days to Die server need?

Eight gigabytes for Navezgane or a 6k world with a few friends, ten to twelve for an 8k random world with a full group, and more with overhaul mods. World generation spikes above the running figure, so the map you can create is a smaller map than the one you can run.

##### Is BloodMoonEnemyCount per player or for the whole server?

Per player. Four players at eight each means thirty-two zombies. `MaxSpawnedZombies` is the server-wide ceiling and silently clamps the total, which is why raising the per-player count sometimes changes nothing at all.

##### Do players need to install the server's mods?

Only if the mod adds assets or code. A modlet that just patches XML - loot, recipes, spawns, progression - is sent to clients by the server and needs nothing installed. Anything with new models, icons or a DLL has to be on both sides.

##### Can I change the world size without losing our save?

No. World size is a property of the generated world, and changing it generates a new one. Your existing save stays on disk under its old `GameName`, so the change is reversible, but there is no way to expand a world in place.

##### Why does the server stutter on a schedule?

It is saving, or it is the dynamic mesh doing structural work. A regular hitch every few minutes is the save; an irregular one after a base collapses is the mesh, and `DynamicMeshLandClaimOnly` narrows where that work happens.

##### Should I turn Easy Anti-Cheat off?

Only if a mod you want requires it, and only on a server where you know everyone. EAC is the main defence against client-side cheating in 7 Days to Die, and there is no partial setting.

7 Days to Die servers on RE:NODE start at 8 GB, which is where this game genuinely begins, and run to 14 GB with 100 GB of NVMe for a large world and its region files. Backup slots are on every tier and can be locked against rotation, the Schedules tab runs `saveworld` and the backup as ordered tasks, and the install takes your Steam login on the Setup tab - use a spare account.

[See 7 Days to Die plans](https://www.renode.space/game-servers/7-days-to-die)

## 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.
