Palworld server memory: how much RAM you actually need

Most game servers scale with players. Palworld scales with pals. Every creature on every base, working or idle, captured or stored, is simulated whether or not anybody is standing near it - which is why a four-player Palworld server can use more memory than a twenty-player Minecraft one, and why sizing it by player count gives the wrong answer every time.

The short version: 8 GB is the honest floor for a small group past its first few hours, 10-12 GB covers a developed server for four to eight people, and a full lobby with mature bases wants 14 GB or more. Below 8 GB a Palworld server does not run badly. It runs fine for an evening and then stops, which is worse, because it looks like something else broke.

Why Palworld scales with pals, not players#

Palworld's dedicated server is an Unreal Engine 5 build that keeps the whole inhabited world resident. There is no meaningful equivalent of Minecraft's chunk unloading for the things that matter: a base camp with fifteen pals working continuously is fifteen active AI agents with inventories, stamina, sanity, work assignments and pathfinding, and they keep being all of that while their owner is asleep, offline, or has not logged in for a fortnight.

Ranked by what they actually cost:

• Base pals. The largest term. Each guild can hold several base camps, each camp holds a worker roster, and every one of those pals is simulated for production, hunger and condition around the clock.
• The pal box. Stored pals are not free. The box holds everything a player has ever caught rather than the working subset, and players do not delete anything.
• Structures. Every wall, conveyor, chest and production building is an object with state. Large bases cost more than their footprint suggests, because production chains tick.
• Dropped items. A surprisingly large term on a busy server. Items on the ground persist until they expire, and the cap is in the thousands by default.
• Players. The smallest term in the equation, by a wide margin.

If your server slows down over weeks rather than minutes, look at how many pals exist, not at how many people are online.

This also explains the shape of the problem over time. A fresh world is cheap. The same world after a month of four people playing seriously - three guilds, a dozen base camps, several hundred stored pals - is a different server with the same name, and it needs more memory than it did on day one without a single extra player having joined.

How much memory a Palworld server actually needs#

Two calibration points for that table. Pocketpair's own dedicated server guidance asks for considerably more than most hosts sell - in the region of 16 GB - which tells you the direction of travel even though 8-12 GB runs a real server perfectly well in practice. And the 32-player figure in ServerPlayerMaxNum is a hard cap, not a recommendation: a genuinely full 32-player world with thirty-two players' worth of bases is a dedicated machine's job, not a shared plan's. If you are heading there, our dedicated servers are the honest answer rather than the top game tier.

RE:NODE's Palworld plans start at 8 GB and run to 14 GB, from $19 a month, because anything below 8 GB is a server that works until it does not. Moving up a tier changes the limit on the server you already have, so the world stays where it is - when to upgrade your plan covers reading the graphs that tell you it is time.

The settings that set your memory ceiling#

Palworld's configuration is one file: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini on Linux, WindowsServer in place of LinuxServer on Windows. It is created empty on first start, and the working method is to copy the contents of DefaultPalWorldSettings.ini from the install root into it and edit from there.

[/Script/Pal.PalGameWorldSettings]OptionSettings=(Difficulty=None,ServerPlayerMaxNum=16,GuildPlayerMaxNum=8,BaseCampMaxNumInGuild=3,BaseCampWorkerMaxNum=12,DropItemMaxNum=1500,DropItemAliveMaxHours=1.000000,AutoSaveSpan=180.000000,AutoResetGuildNoOnlinePlayers=True,AutoResetGuildTimeNoOnlinePlayers=168.000000,ServerName="Longship",AdminPassword="...",RCONEnabled=True,RCONPort=25575)

The settings that actually change memory use, as opposed to the dozens that change game feel:

The arithmetic is worth doing once. At defaults, a guild of twenty players may hold four base camps of fifteen workers, which is sixty permanently simulated pals per guild before anybody opens their pal box. Three guilds like that is 180 pals, and that is the server, not the players. Dropping BaseCampMaxNumInGuild to three and BaseCampWorkerMaxNum to twelve takes the same three guilds to 108 - a third less work, and a change most players will not notice, because the fourth base camp is usually an abandoned one.

AutoResetGuildNoOnlinePlayers is the setting nobody turns on and everybody should consider. A public server accumulates guilds that played for one evening in March and left behind a base camp that has been simulating ever since. Set the timer to something generous - a week rather than the default three days - and the server cleans up after people who are not coming back. On a private server for friends, leave it off and accept the cost.

Note that key names and defaults have moved between builds, and later patches added server-wide caps that earlier ones did not have. DefaultPalWorldSettings.ini in your own install is the authoritative list for your version; a guide is not. The Palworld settings guide goes through the rest of the file - rates, difficulty, death penalty, breeding - which are about how the game plays rather than what it costs.

Launch options and what they do#

$ ./PalServer.sh -port=8211 -queryport=27015 -players=16 \    -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

Those last three arguments are the standard trio and they are worth understanding rather than copying. -useperfthreads and -UseMultithreadForDS push more of the dedicated server's work onto additional threads, and -NoAsyncLoadingThread moves asset loading onto the main thread instead of a background one. Together they generally improve frame pacing on a server with several cores available, which is most of them. They do not reduce memory use, and nothing on a launch line will: memory is a function of how much world exists.

On a Linux install you will also meet the steamclient.so problem, where the server starts and immediately exits with a Steam initialisation failure:

$ mkdir -p ~/.steam/sdk64$ cp ./linux64/steamclient.so ~/.steam/sdk64/

The dedicated server is app id 2394010 on SteamCMD and downloads anonymously. On a panel host both of those steps are already done and the launch arguments are fields on the Startup tab.

RCON and the REST API are both worth enabling on a server you care about, because they are how you save, announce and kick without a client - see Palworld admin commands and RCON.

Saves, save bloat and the slow decline#

The world lives in Pal/Saved/SaveGames/0/<WorldID>/. Level.sav is the whole world in one file and it is the one that matters: every base, every pal, every chest. Players/ holds one small file per player, and LevelMeta.sav and WorldOption.sav hold metadata.

Level.sav grows, and it grows faster than the world feels like it is growing, because it keeps things the world no longer shows you. A long-running server can reach hundreds of megabytes, and both startup time and resident memory scale with it. When a server that was fine in month one takes four minutes to start in month three, the save file is the reason.

• `AutoSaveSpan` defaults to 30 seconds. On a big world, writing Level.sav that often produces a visible hitch every half minute. Raising it to 180 or 300 smooths play at the cost of losing up to that many seconds in a crash. On a server with frequent restarts, keep it low; on a stable one, raise it.
• `bIsUseBackupSaveData` keeps rolling copies beside the save. They are protection against a corrupt write, not against a deleted server - they are on the same disk as the thing they protect.
• `WorldOption.sav` is the trap when migrating a world from a co-op session. If it is present, it can override your PalWorldSettings.ini, which is why a migrated world ignores every setting you carefully typed. Delete it and configure the server from the ini alone.

The other half of the decline is uptime. Palworld's server has grown its memory usage over long uptimes through most of its life, patch by patch getting better without ever getting fixed. A restart every twelve to twenty-four hours is normal practice and costs nothing on a game where nobody plays for twenty-four hours straight. Restart schedules that help covers doing that without annoying the people who are on at the time.

CPU, disk and the rest of the sizing picture#

Memory gets the attention, but it is not the only thing to get right.

• CPU. The server has one heavy thread plus workers. Clock speed matters more than core count, but two cores is a genuine minimum and three is comfortable at sixteen players, because the threads the launch flags enable need somewhere to run. A server pinned at its CPU limit is slow, not broken - CPU vs RAM for game servers walks through telling which of the two is the actual constraint before paying for either.
• Disk. The install is modest and the save is small next to it. What matters is that saves are frequent and large, so slow storage shows up as a stutter every AutoSaveSpan seconds rather than as a disk-space problem.
• Network. Not the constraint at these player counts. Palworld's traffic per player is unremarkable; if the server feels bad, memory or CPU is why.
• Player count as a proxy. It is a bad one. How many players fit on a server makes the general argument; Palworld is the clearest example of it in the catalogue.

Restarts, backups and running out of memory#

Running out of memory in a container does not behave the way running out of memory on a PC does. On RE:NODE, a server that reaches its limit is stopped by the kernel and restarted clean rather than being allowed to swap, which keeps the node healthy and keeps one server from dragging the others down. For Palworld that has a specific consequence: the stop is not a clean shutdown, so you lose whatever happened since the last autosave. It is one more argument for not running a mature world on the smallest plan that technically boots.

The watcher that notices this is worth knowing about too. A server that goes down and comes back repeatedly raises a warning and an automatic ticket rather than quietly looping - why your game server keeps restarting covers reading that pattern, and reading a server load graph covers seeing it coming.

Back the world up before every game update, and before any change to the ini that you are not sure about. Backup slots are included on every plan, backups are stored off the machine they protect, and restoring is one button. A Palworld world is one large file and one folder of small ones, which makes restoring fast and makes corruption total - there is no partial recovery of a Level.sav. Backups that actually restore is the argument for testing one before you need it.

Troubleshooting#

The server stops after a few hours with nothing in the log. Memory. A container at its limit is killed rather than warned, so the log ends mid-line. Check the memory graph for a climb that ends in a vertical drop.

Memory is at 90% and nothing is wrong. That can be normal. What matters is the trend across days and whether it ever comes back down after a restart. A flat 90% is a plan that fits; a 90% that was 60% last week is a plan that is about to not fit.

Settings in the ini do nothing. Either OptionSettings has a line break in it, or a WorldOption.sav is overriding it, or you edited the file in the install root instead of the one under Pal/Saved/Config/. In that order of likelihood.

The server takes minutes to start. Level.sav has grown. Expected on a mature world; alarming on a new one, where it usually means the save is being read from slow storage.

Players can see the server but cannot join. The query port is open and the game port is not. Both 8211 and 27015 are UDP and both are needed.

Everything stutters every thirty seconds. AutoSaveSpan at its default on a world that has outgrown it. Raise it.

FAQ#

How much RAM does a Palworld server need?

Eight gigabytes is the working floor for a small group, 10-12 GB for a developed server of four to eight players, and 14 GB or more once you have several guilds with mature bases. Below 8 GB it will start and then stop later, which is the worst failure mode.

Why does my server need more memory than a Minecraft server with five times the players?

Because Palworld simulates pals continuously whether anyone is near them or not. Sixty working pals across a guild's base camps exist all day; sixty Minecraft mobs in unloaded chunks do not.

Does lowering the player limit reduce memory use?

Indirectly. Fewer players eventually means fewer guilds, fewer base camps and fewer stored pals, which is where the memory goes. Lowering ServerPlayerMaxNum on its own changes nothing until the world is smaller as a result.

Will more CPU fix a Palworld server that feels laggy?

Sometimes. Check which limit is being hit first. If memory is near the ceiling, more CPU changes nothing; if memory is comfortable and the CPU graph is flat at its limit, more CPU is exactly the fix.

Should I restart the server on a schedule?

Yes. Every twelve to twenty-four hours, at an hour nobody plays. Palworld's memory use grows with uptime, and a scheduled restart keeps it flat for free.

Does the number of pals in the pal box matter, or only working pals?

Both, though working pals cost more. Stored pals still occupy memory and are written into Level.sav on every save, which is part of why the save file grows and startup slows on a long-running server.