HumanitZ Server Requirements: RAM and Player Slots Explained

What the developers publish — and what they do not

Yodubzz Studios publish the dedicated server files and the reference settings, but they do not publish a dedicated server RAM, CPU or per-player hardware figure. That is the awkward part of HumanitZ server requirements: you cannot size the server from an official spec sheet. Steam’s 16 GB RAM minimum belongs to the game client, alongside the client CPU and disk requirement, so it is the wrong figure to use when buying a server plan.

So the sensible route is simple: start from what an empty server already consumes, then add headroom for the way your group actually plays.

The baseline: an empty HumanitZ server already uses a lot of RAM

HumanitZ does not start from near-zero memory and grow neatly per player. Host reports for an empty 1.1 server land at about 3.3 GB, about 3.9 GB, or close to 5 GB before anyone joins. That is a large fixed baseline: the server loads the map, the save and its spawn systems before the first player connects, and that memory stays in use whether one person is online or twelve.

These charts show the baseline itself, and then how little headroom common plan sizes leave once that baseline is taken off the top.

This is why 4 GB is a trap. In the best reported case, a 4 GB plan leaves only 0.7 GB of headroom; in the higher reported case, the server is already brushing the limit while empty. By contrast, 6 GB at least leaves room for actual play, and 8 GB gives breathing space for normal evenings instead of surviving one login at a time.

The gap between hosts does not mean one of them is wrong. They may be measuring a fresh world or an older one, checking a few minutes after boot or later, and reporting from different game versions. The safe reading is not “pick the lowest number”; it is “the first few GB are spoken for before slots matter”. If a low-memory server restarts or stops as players join, adding RAM is the first fix, not aggressive world tuning.

What grows with players: map spread, spawned cells, cars and dogs

The cleanest way to think about player load in HumanitZ is not “one player equals X RAM”. It is “how much of the world is active at once”. The server treats the map as grids: MapSeg0=12 means a 12 by 12 grid for one category of objects, with houses in Seg0 and broken cars and similar objects in Seg1. Once a player is inside a cell, the objects in that cell spawn.

That means four players in one base or one town can be easier on the server than four players scattered across four towns. Spread-out players keep more cells active at once, so the server holds more objects in memory, simulates more state on the main thread, and sends more updates over the network. A “16 slot” label tells you nothing about this pattern.

Use this diagram to picture why the same player count can produce very different server load.

Vehicles and companions add to the same problem. More active players usually means more claimed cars to track and more dogs moving around the world. Dogs add AI work; vehicles add persistent state, position updates and later save-file bulk. This is also why a quiet co-op group that stays together often runs better than a public server with the same slot count but players roaming everywhere.

The developers say to leave the MapSeg values alone unless you deliberately want to trade performance against spawn distance. For most admins, it is more useful as an explanation of server load than as a first tuning lever.

What hits CPU hardest: AI population, raids and respawns

After that fixed memory baseline, the next hard limit is CPU time. HumanitZ is an Unreal Engine game, and an Unreal server runs its game logic on one main thread, so per-core speed matters more than a big headline core count. If RAM still looks healthy but players get rubber-banding, delayed hits, frozen zombies or short teleports at busy times, the likely bottleneck is the main thread dealing with AI and spawn work, not memory.

[World Settings]
ZombieAmountMulti=1
HumanAmountMulti=1
ZombieDogMulti=1
AnimalMulti=1
ZombieRespawnTimer=90
HumanRespawnTimer=90
AnimalRespawnTimer=90
AIEvent=2
DogNum=8

The multipliers scale how many zombies, bandits, zombie dogs and animals the world is trying to maintain. AIEvent=2 means raids on player locations are active at the default level, which can create sudden bursts of AI work exactly where players are built up. Lower respawn timers keep the population pressure coming back more quickly; setting a respawn timer to 0 disables that respawn entirely.

One host suggests ZombieAmountMulti=0.7 and HumanAmountMulti=0.7 on full servers because it cuts AI load noticeably while the world still feels dangerous. The cost is straightforward: fewer threats, slightly lighter pressure on towns and bases, and fewer raid-heavy moments. You can test that live with RCON overrides such as overridezeekmulti 0.7, overridebanditmulti 0.7 or even suspendspawners true before writing permanent changes to the file. If the server immediately becomes steadier at the same player count, you have identified a CPU bottleneck rather than a RAM one.

The same logic explains why cheap, heavily shared CPU time hurts this game. When several busy servers compete for the same physical cores, that one main thread waits its turn, and players feel it as rubber-banding even though the memory graph looks calm.

What grows over time: the save file, clutter and cleanup

A HumanitZ server that felt fine in week one can struggle in week six even with the same slots and the same regular group. The reason is not mysterious: bases, dropped items, claimed cars, blueprints and old world state accumulate in the save. More persistent world state means more to load into RAM, more objects to track, and more data to write every autosave.

[World Settings]
PickupCleanup=6
BackpackCleanup=0
FakeBuildingCleanup=3000
BuildingDecay=7
Decay=7
RecycleCar=14
MaxOwnedCars=2

These keys are your long-term housekeeping. PickupCleanup removes dropped pickups after in-game days; BackpackCleanup, added in 1.1, does the same for dropped unworn backpacks but defaults to 0, which means never; FakeBuildingCleanup clears abandoned white blueprint pieces; RecycleCar=14 stops claimed vehicles sitting in the save forever; and the decay settings stop dead builds and stale spawn points living forever. The trade-off is obvious: more cleanup means less abandoned clutter but less tolerance for players who like leaving half-finished or unused things around.

FreezeTime=true means in-game time does not pass when the server is empty, so in-game-day cleanup does not progress during empty hours. Real-day settings such as building decay and car recycling are what keep a long-running, mostly empty community world from fossilising.

A quiet-hour restart is also worth doing because it returns memory the server has accumulated during the session. That costs players a short interruption, but if late-session performance is worse than fresh-boot performance, it often helps. For autosaves, the default is SaveIntervalSec=300. Do not set it to 0. If you feel a hitch every five minutes on a large world, the fix is faster storage such as SSD or NVMe, not turning saves off.

Update 1.1 reached the default branch on 19 October 2026 and the developers strongly recommend a full wipe on dedicated servers for it. That matters for performance as well as correctness, especially as 1.1 fixed guard towers that could retain leftover items after damage and cause server instability. Before any wipe or aggressive cleanup change, make a proper copy of the save and follow good practice for backing up a game server.

Published host advice side by side

The host guides cluster around a fairly clear band even though their wording differs. Host A reports about 3.3 GB empty and suggests 6 to 8 GB for a small group, more as the world fills up. Host B reports close to 5 GB on a brand new world and starts plans at 6 GB, with 8 GB for up to around 16 players and a growing base. Host D says 6 GB for a few friends, 8 GB up to the default 16, and 12 GB for a full 24 or a long-running save. Host E maps 6, 8, 10 and 16 GB to 8, 12, 16 and 24 players, but assumes 6 vCores.

This matrix is useful for seeing the overlap rather than the differences.

Why do they differ? Because they are not measuring the same world age, the same CPU allowance, or the same standard for “runs well”. Taken together, though, they point to a practical buying rule: 6 GB is the floor, 8 GB is the normal starting point, and 12 GB or more is where 16 to 24 players or ageing saves stop feeling squeezed.

Player slots explained: MaxPlayers, the 24 cap and what a slot plan really sells

[Host Settings]
MaxPlayers=16
ReserveSlots=0

MaxPlayers=16 is the default player limit in the shipped settings, and the game cap is 24. If your host sells 8, 16 or 24 slots, those tiers usually mirror the game’s own limits. What they do not tell you is how much RAM, CPU time or storage performance sits behind that slot count.

ReserveSlots is separate. At 0, reserve capacity is off. If you raise it, the reserved spaces apply to players listed by NetID in F_ReservedSlots.txt, which is useful for admins, moderators or regulars on a busy public server. It does not create more total capacity; it just decides who may use part of it.

Conversion used: £1 = $1.33

If you want the longer version on packaging, billing and why two hosts can price the same game so differently, this guide explains why slots and RAM are priced differently. For HumanitZ, the practical question to put to any slot host is blunt: “How much RAM does your 16-slot plan include?”

Our starting-point sizing table for HumanitZ RAM

If you want a quick yes-or-no route, this flow is the simplest way to place your server in the right starting band.

Self-host or rent: what changes on your own hardware

Self-hosting works, but the big catch is shared resources. If you run the server on the same PC you play on, the client’s Steam minimum of 16 GB RAM and the server’s own 3.3 to 5 GB baseline are competing for the same memory before you count Windows or Linux, browser tabs, voice chat and save writes. That makes “it runs the game” a poor guide to “it can host the server well too”.

For networking, the important ports are straightforward:

• UDP 7777 for the game port
• UDP 27015 for the Steam query port
• TCP 8888 for RCON, only if RCONEnabled=true

If you are deciding between home hosting and renting, read the basics of self-hosting a game server and then compare your machine against broader game server hardware requirements. HumanitZ supports a Windows server and a native Linux server on linuxbranch, so you are not forced into a workaround.

Check again after a week: measure the real world, then tune or upgrade

The best time to judge a HumanitZ server is not five minutes after first boot. Read memory with players actually online, and judge changes after at least two hours of normal play. Right after a restart the world has fewer active objects and less session build-up, so almost everything looks healthier than it really is.

When people say “lag”, split the symptoms apart first. Rubber-banding with spare RAM is a different problem from crashes on join, and both differ from five-minute save hitches. This is a useful point to understand what game server lag really is.

If you are comparing packages now that you know your memory band, our HumanitZ server hosting comparison is the easiest next step.

HumanitZ server FAQ

How much RAM does a HumanitZ server need?

There is no official dedicated server RAM figure from the developers. Real host reports put an empty server at roughly 3.3 to 5 GB, which is why 6 GB is the practical floor, 8 GB is a sensible normal start, and 12 GB or more suits 16 to 24 players or older, heavier saves.

Is 4 GB enough for a HumanitZ server?

Usually no. On the lightest reported empty-server figure it leaves only 0.7 GB of headroom, and on higher reported figures it is already too close to the baseline before players even join. If a server restarts as people connect, more RAM is the first fix.

How many players can a HumanitZ server hold?

The default MaxPlayers setting is 16, and the game cap is 24. That does not mean every 16-slot or 24-slot plan will run well at that number, because spread-out players, AI settings and save age decide the real workload.

Do more slots mean more RAM?

Not automatically. Some hosts price by slots and some by RAM, so a higher slot tier may simply raise the connection limit unless memory is increased too. Always ask what RAM and CPU sit behind the slot count.

Why does my HumanitZ server get slower over time?

Persistent world state builds up: bases, cars, dropped items, backpacks, blueprints and general save-file clutter. That increases memory use, autosave work and object tracking, so cleanup timers, decay settings, car recycling and occasional quiet-hour restarts become more important as the world ages.

More HumanitZ server help

Compare hosts, back up your world before a wipe, or weigh up hosting at home.