7 Days to Die Server Size: Disk Space & Save Growth

A 7 Days to Die server size is more than the first download: the install, generated world, changed chunks, mods, logs, updates, and backups all compete for storage. The Fun Pimps’ current dedicated-server guidance starts at 20 GB available and says a large RWG map, the client, and substantial player data may need up to 15 GB more. Treat that as a planning range, not a promise that every modded server will fit. This guide separates the pieces and shows you what to measure before a full drive interrupts your world.

The map’s square footprint is a separate choice from your storage budget. Compare the 6, 8 and 10 km world sizes for exploration scale, then use the guidance below to plan disk space from the actual install and save.

Start with the current 7 Days to Die server size guidance#

The Fun Pimps lists 20 GB available space for both minimum and recommended dedicated-server systems. Its note adds that a large random-world-generation (RWG) map, the client, and a large amount of player data may require up to 15 GB more. For that high-usage case, plan around 35 GB of available disk before adding room for mods, logs, backups, and update staging. That is a planning total derived from the developer’s figures, not a hard game limit or a guarantee that 35 GB is enough for every server.

The requirements page is the more useful planning source than a client store listing: it specifically labels its figures for dedicated servers. Read the current dedicated-server requirements from The Fun Pimps before sizing your drive. If your host advertises a number, ask whether it means installed game files, active server files, backup storage, or some combination. Those are different buckets.

For managed hosting, Game Hosting’s 7 Days to Die service is our recommendation if you value a published 40 GB per-server game-disk allocation and an in-panel warning at 90%. Choose it only if your measured install, save, mods, and logs fit; its public allocation does not state how backup archives count against that quota.

Separate the installed server from your save data#

The server application and the world it creates are separate storage items. On October 12, a clean Windows SteamCMD install of App 294420, public build 25661908, contained 17,582 files totaling 17,857,945,514 bytes (16.63 GiB) on disk. That measurement is from one completed install, not the size of a save or a universal future patch. Steam lists the 7 Days to Die Dedicated Server tool; your install can differ if you use Linux, another branch, or a later build.

Do not subtract that GiB figure from TFP’s 20 GB baseline and treat the remainder as a safe save allowance. The units differ, and the developer’s figure is a minimum/recommended system requirement rather than a per-folder quota. Keep both facts in view: the application takes a substantial part of the disk, and a large RWG world plus player data can need additional room.

Your active save may sit outside the install directory. The server’s launch arguments, user-data setting, container, or host panel can redirect it. The Fun Pimps’ save-location guide describes the standard client locations and how a client path can be changed; a dedicated server may use a different path. On a rental server, use the provider’s file manager or ask support which directory contains the live save. On a self-hosted server, check the configuration and launch command for the data path actually in use.

Give a generated world room to change#

An empty new world is not a useful upper bound for a server your group has played for weeks. As players explore, build, alter terrain, and add data to their profiles, the live save can change. The amount depends on what the group does, the chosen world, the game build, and installed server-side mods. Neither TFP’s requirements page nor the current release notes publishes a per-day or per-player save-growth rate.

So do not promise yourself that a particular map size will stay below a guessed number. Record the active save folder’s size just after world generation, then compare it after a few sessions and again after a longer interval. Keep the build, world name and generation settings, player count, and activity period beside each reading. That gives you a measurement for your own group instead of a borrowed estimate from a different map or version.

The stable release checked for this guide is V3.3.0, announced October 5, 2026. Its notes mention an optimization to prefab-cell memory and a fix involving save processing of culled/reset chunks, but do not publish a new world-size figure. The V3.3.0 notes therefore do not replace the disk guidance above. When you change stable or experimental builds, measure the resulting server and save again; do not assume the old figure transfers unchanged.

Count mods, logs, updates, and backups separately#

The base installation is only one line in your budget. A modded setup adds its own files, and an update can temporarily need room while new files are downloaded or staged. Logs also accumulate until they are rotated or removed. The current game does not publish one modded-server size that applies to every overhaul, and this guide does not claim a measured V3.3 mod footprint. Check the exact packages and update behavior you intend to use, then leave headroom beyond the vanilla figures.

Backups need a direct answer from your provider: are archives inside the live server quota, on separate node storage, or subject to a separate limit? A number of backup slots says how many copies the panel can manage; it does not state their total GB capacity or retention. Game Hosting documents three free backup slots and a 40 GB per-server game disk, while its panel’s active-disk meter covers game files, world, mods, and logs. The public allocation does not specify whether backup archives count against that same per-server figure, so ask before budgeting the same space twice.

For a second example of why labels matter, G-Portal currently advertises 50 GB of “backup space” for savegames and configs, without stating a matching live-server disk quota on that page. That backup figure cannot be compared one-for-one with a provider’s game-disk allocation. Our G-Portal 7 Days to Die review covers its public offer and the limits of what the page discloses.

Choose a hosted disk allocation that fits your plan#

The service lists 40 GB on mirrored NVMe, and the panel turns the active-disk warning red at 90%. The meter names game files, world, mods, and logs. That gives you a visible signal before the active server directory fills; it does not prove a speed advantage or guarantee that every large world and overhaul fits.

Compare the allocation with your own measured install, save, mod, log, and update needs. In particular, do not treat the three backup slots as 3 × 40 GB, and do not assume their archives use a separate unlimited pool. If your world is already close to the high end of TFP’s guidance before mods and backups, ask the host to explain the live quota and backup accounting in writing. The 7 Days to Die hosting page lists the published plan details, while the host comparison guide helps compare the rest of the service.

Self-hosting is still a sensible route if you already have a machine with enough free space and can monitor it. The warning sign is not simply a big-looking folder: it is a disk that keeps shrinking toward its limit while the save or update needs more room. If that machine also stores other games, operating-system files, and unrelated backups, count those uses before deciding the server has a spare 20 GB.

Measure the folders your server actually uses#

Take a baseline after the server has installed and generated the world, then repeat it after your group plays. Measure the install folder, live save folder, mods, logs, and backup directory separately where your setup exposes them. A combined “server folder” total is useful for disk safety, but separate totals tell you what is growing. If the panel provides only one usage meter, ask whether it includes backups and temporary update files.

On Windows, point this PowerShell command at the folder you have confirmed is the live save or server-data directory:

Get-ChildItem -LiteralPath 'C:\path\to\server-data' -Force -Recurse -File |
  Measure-Object -Property Length -Sum

The Sum field is bytes; compare readings from the same path and convert them consistently. On Linux, du -sh /path/to/server-data gives a compact folder total. Do not copy the client save path from a guide into a dedicated-server machine without checking the actual data directory first. If your host hides the filesystem, use its storage meter and ask support what it counts.

Measure again after a major update or after adding an overhaul. Keep a separate backup outside the server’s only disk when you self-host; a backup stored on the same drive may not help if that drive fails. For rented servers, confirm the backup’s location, retention, and restore process instead of inferring them from a slot count or marketing label.

Treat save-size limits as a recovery choice#

The V3.3.0 Windows package checked for this article includes MaxChunkAge and SaveDataLimit in its shipped serverconfig.xml; both default to -1. The comments describe chunk-reset behavior: SaveDataLimit is a per-save allowance in MB and saved chunks may be forced back to their original state when the limit is reached; its negative default disables that cap. MaxChunkAge can reset old, unvisited chunks after the configured in-game age, subject to protected areas. The same V3.3 file contains SandboxCode for the game’s sandbox rules; it is separate from disk budgeting. These settings can trade retained world changes for lower save storage, so they are not a replacement for a properly sized disk and a restorable backup.

Before changing either property, read the XML that came with your exact build and keep a copy of the current world. The stable and experimental labels do not always mean different files: when checked, the public/V3.3.0 Stable branch and latest_experimental pointed to the same build ID, 25661908. That can change later. For general V3 settings—including the distinction between server properties and SandboxCode gameplay options—see our V3 settings reference, and verify any setting against the file shipped with your own branch.