Comprendre ce qui fait vraiment tourner un serveur Palworld

Palworld server requirements are easy to misread, because the numbers usually quoted describe an empty world on day one. A freshly generated map with four players behaves nothing like a six-month-old guild world with twenty bases and a thousand captured Pals. This guide breaks down what really drives performance: memory per player slot, single-core clock speed, base and Pal density, and save file growth.

What Palworld server requirements actually measure

Palworld runs on Unreal Engine 5, and its server build inherits the engine's characteristics: one dominant game thread, heavy replication traffic, and a world state that is serialised to disk in one big blob. That means three metrics matter far more than a raw core count:

• Resident memory (RSS) — grows with world objects, not just with connected players.
• Single-thread throughput — determines whether the server keeps a stable tick when Pals are working and raids spawn.
• Save write time — how long the world freeze lasts every autosave cycle, which depends on save size and disk latency.

If you want to skip the sizing maths and run your world on Ryzen cores with NVMe storage and anti-DDoS filtering already in place, our Palworld server hosting page lists the available configurations and slot counts.

The official baseline, and why it is only a starting point

Pocketpair publishes a minimum of roughly 8 GB of RAM and recommends 16 GB for the server build, with 4 cores as a floor. Those figures are documented in the official Palworld technical documentation. They are accurate for a young world with a handful of players. They stop being accurate the moment your community starts breeding Pals at scale.

RAM: the first ceiling you will hit

Memory is where most Palworld worlds die first. The server process does not allocate memory per connected player in any linear, predictable way — it allocates for persistent world state. Every base, every worker Pal, every item in a Pal Box, every dropped crate on the ground stays in memory whether the owner is online or not.

Realistic memory behaviour

World state	Typical resident memory	What drives it
Fresh world, 4 players	~6–8 GB	Engine baseline + loaded level
Mature world, 8–10 players	~10–14 GB	Multiple guild bases, several hundred Pals
Long-running world, 16–32 players	16–24 GB and rising	Max base camps, breeding farms, ground clutter

A practical rule that holds up in the field: budget around 1 GB per active player slot on top of a 8 GB engine baseline, then add headroom for the world itself. A 16-slot world with heavy builders is comfortable around 16 GB, tight at 12 GB, and will start swapping or getting killed by the OOM reaper at 8 GB.

The memory growth pattern

Palworld's server build is known for memory that climbs steadily during uptime and never fully returns after players disconnect. It is not a leak in the catastrophic sense, but it is real. The pragmatic mitigation is a scheduled restart — every 6 to 12 hours for a busy world, once every 24 hours for a quiet one. In a Pterodactyl panel you set this up as a scheduled task, with a graceful in-game warning first:

# RCON / console sequence for a clean cycle
Save
Broadcast Server_restarting_in_60_seconds
Shutdown 60 Scheduled_maintenance

Note that Broadcast does not accept spaces — use underscores. Always issue Save before Shutdown; the shutdown routine does save, but an explicit write gives you a known-good state if the process hangs.

Checking real memory use

On a Linux machine you manage yourself, read the actual resident set rather than trusting a dashboard average:

ps -o pid,rss,etime,cmd -C PalServer-Linux-Shipping
# rss is in kilobytes: divide by 1024 for MB

# continuous view
top -b -n 1 | grep PalServer

Inside a panel, watch the memory graph across a full evening peak, not a five-minute snapshot. The number that matters is the plateau just before your scheduled restart.

CPU: single-core clock beats core count

This is the part of Palworld server requirements that gets misunderstood most often. Adding cores past four or six gives you very little. The main simulation loop — Pal AI, base work orders, physics, replication decisions — runs largely on one thread. Additional cores handle networking, asset streaming and the save serialisation, but they cannot rescue a saturated game thread.

What a saturated game thread looks like

• Pals at base stop pathing correctly, stand idle or teleport around work stations.
• Rubber-banding when several players are in different regions of the map at once.
• Damage registration lag on boss fights and raids.
• Ping stays low while the game still feels laggy — the classic sign that the issue is tick quality, not network latency.

Ping and tick are two separate problems. A 15 ms connection to a machine whose game thread is pegged at 100% will still feel terrible. This is why high-frequency Ryzen cores matter more than a large count of slower shared cores, and why a fully shared vCPU with noisy neighbours produces inconsistent frame pacing even at low player counts.

Practical CPU guidance

Player count	Cores worth allocating	What to prioritise
2–8	2–4 modern cores	Clock speed, stable allocation
8–16	4 cores	Clock speed, NVMe for save writes
16–32	4–6 cores	Clock speed first, memory headroom second

If you are already on fast cores and still seeing stutter, the bottleneck is almost always world content, not silicon. That brings us to the third factor.

Bases, Pals and save file growth

Everything a guild builds becomes permanent CPU and memory load. A base camp with fifteen working Pals runs a continuous stream of AI decisions, work-suitability checks and pathfinding queries. Multiply that by four camps per guild, by five guilds, and you have the single biggest source of server load in a mature world.

The settings that control world density

These live in Pal/Saved/Config/LinuxServer/PalWorldSettings.ini (or WindowsServer) and are the levers that actually change your load profile:

ServerPlayerMaxNum=16
GuildPlayerMaxNum=10
BaseCampMaxNumInGuild=3
BaseCampWorkerMaxNum=15
DropItemMaxNum=3000
DropItemMaxNum_UNKO=100
DropItemAliveMaxHours=1.000000
AutoSaveSpan=600.000000
bIsUseBackupSaveData=True
ServerReplicatePawnCullDistance=15000.000000
RESTAPIEnabled=True
RESTAPIPort=8212

Three of these deserve attention:

• BaseCampMaxNumInGuild — dropping this from 4 to 3 removes a full simulated camp per guild. On a crowded world that is the single most effective tuning change available.
• DropItemAliveMaxHours — ground items are simulated objects. Long lifetimes on a farming-heavy world leave thousands of entities lying around. One hour is a sane default.
• ServerReplicatePawnCullDistance — lowering it reduces how many distant Pals get replicated to each client. It shaves bandwidth and thread time, at the price of Pals popping in later.

How the save file grows

Palworld stores the world in a small number of large files:

• Level.sav — the whole world: bases, Pals, containers, guild data. This is the file that grows.
• LevelMeta.sav and WorldOption.sav — small metadata.
• Players/<steamid>.sav — one small file per player.

A fresh Level.sav sits in the low single-digit megabytes. A world with a dozen active players and full base camps commonly reaches 40–150 MB, and heavily populated long-running worlds have been observed well beyond that. Inspect it directly:

cd ~/Pal/Saved/SaveGames/0/
du -h --max-depth=2 .
ls -lh */Level.sav

Why it matters: every autosave serialises that file. The larger it is, the longer the hitch every player feels. On slow storage a 150 MB save can produce a visible one-to-two second freeze on the interval defined by AutoSaveSpan. NVMe storage compresses that pause dramatically — this is one of the few cases where disk type has an immediate, felt gameplay effect rather than just a boot-time effect.

Save hygiene

Set AutoSaveSpan to 600 seconds rather than the default 30 on a large world: fewer, slightly longer writes beat constant micro-freezes. Keep bIsUseBackupSaveData=True, and layer external snapshots on top — automatic backups on the infrastructure side protect you from a corrupted Level.sav, which is the one failure mode that can end a world instantly. Before any version update, pull a manual copy:

tar -czf palworld-save-$(date +%F).tar.gz ~/Pal/Saved/SaveGames/0/

Reading the numbers before you size a machine

Sizing from a table alone is guesswork. Sizing from your own telemetry is not. Here is the checklist that works:

1. Measure at peak, not average. Note memory and CPU during your busiest hour, then add 30% headroom.
2. Track save size weekly. If Level.sav is growing faster than 10 MB per week, your world density is climbing faster than your community realises.
3. Separate ping from tick. Ask players whether the lag is uniform or only occurs near large bases. Base-local lag is a CPU and density problem, never a network one.
4. Watch restart-to-restart drift. If memory at hour 6 is materially higher than at hour 6 of the previous cycle, your world state is growing, not leaking.
5. Test one variable at a time. Change BaseCampMaxNumInGuild or the cull distance, then measure for a full evening before touching anything else.

Mods, and what they add

Palworld's modding scene relies on UE4SS-style injection and community loaders. Anything that adds entities — more Pals per base, larger stacks, extra structures — feeds directly into the same three metrics above. Add roughly 10–15% memory headroom per meaningful content mod, and always keep an unmodded save copy before installing anything. A panel with live console output and file management makes this loop fast: edit the config, restart, watch the console for load errors.

The same reading method applies to any persistent survival world. If you also run Valheim server or ARK Survival Ascended server worlds, you will recognise the pattern: memory scales with built content, tick quality scales with clock speed, and disk latency shows up as save-time stutter. More technical breakdowns for other titles are collected on the Fly-Serv blog, and the full catalogue sits under All our game servers.

Sizing summary

Profile	Memory	Cores	Storage	Restart cadence
Private world, 2–6 players	8 GB	2–4 high-clock	NVMe	Every 24 h
Community world, 8–16 players	16 GB	4 high-clock	NVMe	Every 12 h
Large world, 16–32 players	24–32 GB	4–6 high-clock	NVMe	Every 6–8 h
Modded world	+10–15%	Same	NVMe	Every 6–8 h

Palworld rewards administrators who watch their own metrics. Memory follows world content, tick quality follows single-core clock speed, and save writes follow disk latency. Measure at peak, keep Level.sav under control, restart on a schedule, and snapshot before every update. Do that, and a mature world stays as smooth as it was on day one.

FAQ

How much RAM does a 10-player Palworld world really need?

Plan for 16 GB. An 8 GB allocation works for the first weeks, but once each guild has multiple base camps and several hundred Pals, resident memory typically settles between 10 and 14 GB. Add a scheduled restart every 12 hours to reset the drift, and watch the plateau just before that restart to confirm your headroom.

Why is my Palworld world lagging even though ping is low?

Low ping with in-game stutter means the game thread is saturated, not the network. Check CPU use on the single busiest core, then reduce world density: lower BaseCampMaxNumInGuild, cap BaseCampWorkerMaxNum, shorten DropItemAliveMaxHours, and reduce ServerReplicatePawnCullDistance. Change one value at a time and measure for a full evening.

My Level.sav is over 100 MB — is that a problem?

It is normal for a mature world, but it lengthens every autosave freeze. Raise AutoSaveSpan to 600 seconds so writes happen less often, make sure the world sits on NVMe storage, keep bIsUseBackupSaveData=True, and archive a copy before every update. If the file grows very fast, audit abandoned bases and ground clutter.