How to set up a 7 Days to Die server: world generation and the blood moon

This guide builds a working 7 Days to Die server from scratch: choosing the operating system, installing through SteamCMD, configuring serverconfig.xml, opening ports, waiting out world generation and preparing for blood moon night. One sentence decides the hardware in this game: a server's real capacity shows on the seventh night, not on an average evening.

Before you start: what you need

• A server with headroom for the peak. An 8-player server runs at around 6 GB in normal play, but peak use rises noticeably on blood moon night, which is why 8 GB is the practical baseline. For 8-24 players on a large random world 16 GB is realistic, and above 24 players 32 GB. How the per-slot calculation works out: game server slot planning
• A high-clocked processor. Entity AI and block physics are largely single-threaded. What keeps the server standing on blood moon night is per-core performance, not core count.
• Patience. World generation takes a long time on first boot, and the step cannot be interrupted.

To pick resources with headroom left for the peak and see the monthly total: server configurator

1. Operating system

Choose Ubuntu 22.04 LTS and tie the server process to a separate user created only for the game. Install the 32-bit compatibility packages SteamCMD depends on in advance; when they are missing the first command fails with an opaque error.

Define swap on the machine. The point is not to substitute for RAM but to absorb the temporary peak during world generation: memory use in that step rises above normal play, and if the process hits the ceiling and is killed by the operating system, what is left behind is a half-generated world.

2. Installing with SteamCMD

Server files are downloaded with an anonymous Steam session:

./steamcmd.sh +force_install_dir /home/7dtd/server +login anonymous \
  +app_update 294420 validate +quit

Use the validate parameter both on first install and after every update. Define the server as a systemd service with Restart=always; a server left attached to your SSH session shuts down the moment that session closes.

3. Configuring serverconfig.xml

The server name, passwords, player cap, world size, difficulty and blood moon frequency all live in serverconfig.xml.

Do not edit the file where it sits in the install directory. Take a copy and point the server at that copy when starting it; every update overwrites the original and your edits vanish silently. This is the mistake that costs the most time and is noticed the latest — your settings work one day and revert to defaults the day after an update.

The real decisions here are: whether the world is the fixed map or randomly generated, at what size if random, how often the blood moon comes, and what the player cap is. Do not choose the world size independently of the player count; the two determine RAM together. Picking an enormous world for a handful of players both wastes RAM and produces a deserted server where players never run into each other.

Write down the world name: it is the name of your save folder. Starting the server under a different name drops your players into an empty new world.

4. Ports

All three must be reachable from outside, otherwise your server will not appear in the public list. Opening only 26900 is a common mistake: the server is listed but nobody can connect, because game traffic travels over UDP.

The server's web control panel and remote command (telnet) interface run on separate ports. Do not expose them; both are full control of the server. If you need them, allow only your own IP address in the firewall.

5. First boot: world generation

If you chose a random world, the server generates the map on first boot. That step has three properties, and all three come as a surprise.

Generation is single-threaded, so it progresses at the speed of one core even on a 16-core machine. It takes a while depending on world size, and during that time the server accepts no connections at all — with no movement in the console, people assume it has frozen. Interrupting the process leaves a corrupted save and means starting over.

So run the first boot well before the hour you announced to players, wait for it to finish, and join once yourself to check when the world is ready.

Blood moon night: the real test

On the seventh night the number of simultaneously simulated entities multiplies. A plan that runs comfortably in normal play can fall short that night, which is why sizing hardware against average use is misleading.

Preparing for the blood moon is three steps: choose the plan with headroom for the peak, back up the save folder the day before, and watch the first blood moon yourself. If the server stumbles that night, the answer is not adding cores but upgrading the processor family, or pulling the player count and world size down. A virtual server that genuinely reserves your resource ceiling makes a visible difference against a shared environment at exactly that peak.

Backups

Block changes are persistent, and a destructible world makes the save grow noticeably over time. A lost base cannot be brought back.

The right approach is not copying the save folder while the server runs; it is stopping the server briefly, moving the folder to a remote target and actually testing a restore once: server backup strategy

The most common first-boot mistakes

1. Interrupting world generation. What remains is a corrupted save.
2. Editing the configuration file inside the install directory. The first update wipes your settings.
3. Opening only 26900. The server is listed and nobody can connect.
4. Exposing the control panel or telnet port. You have handed full control of the server outside.
5. Sizing hardware for average load. Peak load on blood moon night is noticeably higher.
6. Choosing world size independently of player count. The two determine RAM together.
7. Not recording the world name. Your save folder carries that name.

On DDoS

Because game traffic runs over UDP and a UDP source address can be forged, floods cannot be blocked at the application layer; filtering has to happen at the network layer. How the protection works, in a separate post: what is DDoS protection?

On Datafex servers, layered Fexwall DDoS protection is included free on every plan, and floods on 26900 are absorbed by those layers.

Next step

We have put the recommended plans by player count and world size, the processor options and the 7 Days to Die-specific questions on one page: 7 Days to Die server plans.