SCUM Server Requirements: RAM and Player Slots Explained

The published figures, and what they actually mean

The official numbers for a SCUM dedicated server are a starting point, not a full sizing guide. The server is a separate free Steam app, runs from SCUM\Binaries\Win64\SCUMServer.exe, and is 64-bit Windows only. If you rent on a Linux host, the usual approach is Wine or another compatibility layer rather than a native Linux build. If you want the broader logic behind CPU, RAM, disk and bandwidth choices, this is the same pattern covered in how game server hardware requirements work.

Do not confuse that with the Steam client requirements for players’ PCs. The client minimum mentions 16GB RAM and 80GB storage, but those are for running the game locally, not for hosting the dedicated server.

The chart puts the start-up figure next to what a SCUM server actually holds while idle, and next to the disk space you need today.

Why an empty SCUM server already uses so much

SCUM is not a lobby server that sits nearly empty until players arrive. It is a persistent island, and the island is large: a 225 square kilometre map with systems that continue to exist between sessions. Even with nobody connected, the server still has to keep the world loaded enough to manage its rules, the save state and the background simulation. That is why the setup documentation says the server needs 8GB just to start, and why one Linux host reports about 10.6GB in use on an idle server with nobody connected.

The first CPU clue is the tick rate. By default, scum.MinServerTickRate is 5 Hz when no player is connected, while scum.MaxServerTickRate is 30 Hz once at least one player is online. In plain terms, the empty server is doing fewer update cycles per second to save CPU. The moment somebody joins, the server begins stepping the world much more often. That raises demand on the main game thread before you have even filled many slots.

RAM use also makes more sense once you think in world objects rather than players. Puppets, animals, vehicles, bases and items all have to exist somewhere in server state, even when nobody is standing next to them. SCUM virtualises items that are far from players, which keeps them out of the live simulation, but the save still has to track everything that exists.

Disk ties into this through SCUM.db, the SQLite save database stored under SCUM/Saved/SaveFiles/. As your community leaves behind more vehicles, more base elements and more general clutter, the save grows. Bigger saves do not just cost storage; they can also mean more memory pressure and heavier save-related disk activity over time.

How player count multiplies the load

Player count does not only add a little network traffic per person. In SCUM it can directly increase how many AI characters the server is trying to support around them. The encounter system uses this formula: standard number + (players – 1) × extra per player × multiplier. The default multiplier is 1, and the base encounter size depends on zone: low threat zones start at 1-2 characters, medium at 2-3, and high at 4-5.

That matters because a squad does not cost the same as four lone players who log in one at a time. More people together can ask the server to create larger encounters in one area, while many people spread across the map can make the server keep more parts of the world busy at once. Hordes scale by the same per-player logic through scum.EncounterHordeExtraCharacterPerPlayerMultiplier.

There is also a wider world cap: scum.MaxAllowedCharacters defaults to -1, which means the game default of 128 characters in the world. That pool covers players, NPCs, mechs, animals and puppets together, with high threat zones counted separately. Do the arithmetic for a busy server: with 64 players online at the default slot cap, players alone would fill half of that budget, leaving less room for the puppets and animals that make the island feel alive. If you raise it, you give the server permission to hold more active characters, which increases RAM use and adds more work to the main thread each tick.

When the server reaches its spawn limits, SCUM tries to stay alive by design. scum.EncounterCanRemoveLowPriorityCharacters=True lets it remove inactive puppets further from players so new ones can spawn where they matter. scum.EncounterCanClampCharacterNumWhenOutOfResources=True lets it cut an encounter down to its minimum. That is why overloaded servers often feel oddly empty rather than crashing straight away: the game is shedding spawn load first.

Here is how the same rules play out for a lone player, a squad and a spread-out community.

Player slots explained: cap, not reservation

SCUM’s player-slot setting is simple in one sense and misleading in another. scum.MaxPlayers defaults to 64, and the allowed range is 1-128. That number is only the maximum simultaneous connections the server will accept. It does not pre-allocate a fixed amount of RAM per slot, and it does not guarantee the server has enough CPU headroom to run well at that population.

There is one extra catch that causes a lot of confusion: the launch argument overrides the config file. If the server starts with SCUMServer.exe -log -port=7777 -MaxPlayers=64, that command-line value wins over the scum.MaxPlayers value in ServerSettings.ini. So if you edit the file and nothing changes, check the launch line or your host panel’s start-up options first.

This is also why host plans can look inconsistent. Some sell by slots, some by RAM, and some tie the two together. The safer way to read them is to treat slots as a ceiling and RAM as the real performance budget. If you want a clearer picture of that packaging difference, read our explainer on slot-based versus RAM-based pricing.

• Set the cap to your realistic peak, not the biggest number the panel allows.
• If your group is a private squad, a high public slot cap just invites load you did not size for.
• If you run events, leave room for the event peak rather than the weekly average.

RAM by community size: pick for your actual peak

The practical way to size a SCUM server is to start from your community pattern, then move up only when your save, mods or settings justify it. Host plans on the market range from 6GB to 48GB and from 10 to 128 slots, but the useful part is how providers tend to pair memory with expected activity. One player-based example sizes 12 players with 12GB, 24 players with 14GB, and 36 or more players with 16GB or more. That lines up with our own guidance below.

What pushes RAM up fastest is persistent world clutter: bases, vehicles, stored items, old player data and any modded systems you bolt on top. SCUM has no Steam Workshop support. Mods are installed by hand through FTP, often with the UE4SS framework, every player needs the same client mods, and some mods use far more memory than others. If you plan a modded server, size up from the start rather than after the first crash.

The chart lines up one host’s player-based SCUM plans with our community bands, so you can see where your group sits.

The settings that change the resource bill

SCUM exposes enough world settings that you can make a modest server feel busy or make a strong server work much harder than it needs to. The rule is simple: change one thing at a time, stop the server before editing, and restart afterwards because the file is read at start-up. Keep defaults unless you have a clear reason to move them.

Two settings that often get misread are the spawn-limit safety valves. Leaving scum.EncounterCanRemoveLowPriorityCharacters and scum.EncounterCanClampCharacterNumWhenOutOfResources on means the server will cut spawn pressure when it is short of room. That helps stability, but the player-facing trade-off is a world that feels thinner during peak times.

For replication range, the cull distance overrides (scum.PuppetCullDistanceOverride, scum.ArmedNPCNetCullDistanceOverride and scum.AnimalNetCullDistanceOverride) for puppets, armed NPCs and animals default to -1. Pushing replication farther means players can receive those entities from further away, which increases bandwidth and some server work. The gain is fewer visible pop-ins; the cost is more traffic and more to manage per client. Item virtualisation settings exist too, but unless you know exactly why you are changing them, leave them alone.

This is what those defaults look like in SCUM\Saved\Config\WindowsServer\ServerSettings.ini. Your own file has many more keys, and Gamepires adds or removes settings with its roughly monthly feature updates, so search your file for a key before you change it.

[General]
scum.MaxPlayers=64
scum.MinServerTickRate=5
scum.MaxServerTickRate=30

[World]
scum.MaxAllowedCharacters=-1
scum.MaxAllowedPuppets=-1
scum.MaxAllowedNPCs=-1
scum.EncounterExtraCharacterPerPlayerMultiplier=1.000000
scum.EncounterHordeExtraCharacterPerPlayerMultiplier=1.000000
scum.EncounterCanRemoveLowPriorityCharacters=True
scum.EncounterCanClampCharacterNumWhenOutOfResources=True

[Vehicles]
scum.MaximumTimeOfVehicleInactivity=240:00:00
scum.LaikaMaxAmount=50
scum.LaikaMaxFunctionalAmount=20

[Features]
scum.MaximumAmountOfElementsPerFlag=100
scum.ExtraElementsPerFlagForAdditionalSquadMember=25
scum.BaseElementsDecayRateMultiplier=1.000000

CPU and storage: where smooth servers usually win

There is no official CPU figure for SCUM’s dedicated server, and that is sensible because the important part is not a single headline number. What matters most is how well one core can keep the main game thread moving at the active tick rate while handling AI, world updates and replication. If a server struggles only when players cluster into fights, compounds or high-threat areas, that points more towards tick-time CPU pressure than towards raw slot count.

You can sometimes tune around that by lowering character pressure or being more conservative with world persistence, but there is a limit. If you already run sensible settings and still get rubber-banding at peak times, stronger per-core CPU performance is the upgrade that usually changes the feel of the server most.

On storage, SCUM benefits from SSD or NVMe not because average gameplay constantly streams huge files, but because persistent data has to be written and maintained reliably. The save database is SCUM.db, a SQLite database running in WAL mode, so copy it only with the server stopped. Plan disk headroom for the install itself, monthly feature updates, and game server backups. If the drive is nearly full, updates and restore work become much riskier than they need to be.

Self-host or rent for SCUM?

Self-hosting can work well for a private group, but SCUM is not the lightest game to leave running at home. The server is Windows only, needs 8GB just to start, needs the Visual C++ redistributables and DirectX End-User Runtimes from _CommonRedist, and it still uses CPU while idle because the world never fully disappears. If you want the general pros and cons first, start with our guide to self-hosting a game server.

For a private squad, self-hosting is often about convenience versus hassle. For an active public server, rented hosting usually makes more sense because SCUM’s persistent world keeps asking for RAM, storage headroom and steady CPU time even outside peak hours.

Symptom, likely cause, first fix

Quick sizing checklist

1. Decide your real concurrent peak: private squad, active community or large public server.
2. Set MaxPlayers to that peak, not the highest number that looks impressive.
3. Start from 8GB only for a small private server; treat 12-16GB as the normal range for a busy community.
4. Keep default character and encounter settings unless you have a clear design reason to raise them.
5. Remember that vehicles, bases and long-lived items cost disk and RAM over time, not just on day one.
6. Prefer strong per-core CPU performance over chasing an arbitrary slot figure.
7. Leave disk headroom for updates, logs and backups, not just the current install size.
8. If self-hosting, forward UDP 7777, 7778 and 7779 and plan around the server’s idle resource use as well as peak use.
9. After each change, judge the result by busy-hour behaviour: smoother movement, fewer spawn complaints, faster restarts and stable browser visibility.

SCUM server FAQ

How much RAM does a SCUM server need?

The official floor is 8GB just to start the dedicated server. In practice, that suits a small private group as a starting point, while active communities usually want 12-16GB and larger public servers should plan on 16GB or more. The main reason is that RAM use grows with players, world settings, mods and the amount of persistent clutter in the save.

Is 8GB enough for a SCUM server?

It can be enough for a private squad if you keep settings sensible and do not let the world fill up with bases, vehicles and added systems. It is not the whole story, because SCUM already uses substantial memory when empty and shifts to a higher active tick rate as soon as a player joins. If you expect regular busy periods, 8GB is a floor, not a comfort zone.

How many players can a SCUM server hold?

The default scum.MaxPlayers value is 64, and the allowed range is 1-128. That is only the simultaneous connection cap, not a promise that the machine can run well with that many players. Real capacity depends on CPU speed, RAM, world settings, and how widely your players spread across the map.

Does SCUM need a fast CPU for a dedicated server?

Yes, more for per-core speed than for a headline core count. SCUM runs on an Unreal dedicated server model where the main game thread and tick rate matter, especially once players join and the server moves from the lower idle tick to the higher active tick. A faster CPU core helps most when players gather, fights intensify and the server has to process more AI and replication work each tick.

Can I run a SCUM server on Linux?

Not as a native Linux dedicated server, because the official executable is Windows only. Linux hosts can still run SCUM through Wine or another compatibility layer, which is common on rented platforms. If you self-host and want the simplest route, a Windows machine is the direct fit.

More SCUM server help

The host comparison, plus the explainers behind RAM, slots and server location.