Most Palworld server guides tell you to buy more RAM when things get choppy. That fixes almost nothing. The engine has a documented partial memory leak that climbs over uptime regardless of how much headroom you give it — a 4-player box that idles happily at 5GB on day one can be pushing 8GB a week later, not because your group built more, but because the process itself grows [6]. The actual fix is a handful of settings in PalWorldSettings.ini that most setup guides never mention, because they’re written for 32-player public servers, not a 4-person co-op group.
This guide covers both halves: getting a dedicated server running from zero, and then tuning it specifically for a small group instead of copy-pasting settings meant for a full lobby. Verified against Palworld 1.0 (build 1.100.427, released July 10, 2026) — values may shift with future updates, so check your server’s changelog before assuming these numbers still match [8].
Quick Start Checklist
- Confirm your machine or VPS has at least 8GB free RAM, a quad-core CPU, and 20GB free storage [5]
- Install SteamCMD and pull the server files with
app_update 2394010[1] - Launch
PalServer.exe(Windows) orPalServer.sh(Linux) once to generate the config folders [1] - Open UDP 8211 on your firewall and router [4]
- Edit
PalWorldSettings.ini— set your server name, password, and player cap - Apply the 4 small-group performance settings below before your first session, not after it starts lagging
- Set a launch shortcut with
-port=8211 -publiclobby(drop-publiclobbyfor invite-only) - Schedule a daily restart to manage the memory leak [6]
Hardware Requirements for a 4-Player Server
Pocketpair’s own baseline recommendation is blunt: 32GB of RAM or more, with 8GB called out as the technical floor that “increases the possibility of server crashes” [5]. That’s aimed at full 32-player servers, and it’s the number most hosting articles repeat without qualifying it for smaller groups.
For an actual 4-player co-op group, community testing puts fresh-install usage closer to 5GB, climbing to around 8GB after a week of regular play as the leak accumulates [6]. Both figures are real — they’re describing different points in the server’s uptime, not disagreeing about the game. Budget 8GB as your working number for a small group, not because you need it on day one, but because you’ll be there within a week regardless.
CPU matters more than most buyers expect. Palworld’s simulation work concentrates on one or two threads rather than spreading across cores, so a 4-core CPU at a high clock speed will outperform an 8-core chip running slower per-core [5]. If you’re choosing between hosting hardware, prioritize clock speed over core count. Storage should be SSD or NVMe — slow disks risk save corruption during the server’s write cycles [5].
Self-Hosting vs. Renting a VPS: Which Fits a 4-Player Group
Before touching SteamCMD, decide where the server actually lives — the setup steps below differ slightly depending on the answer.
- If your group only plays at the same scheduled times and someone’s PC is free during those windows, self-hosting on that PC costs nothing beyond electricity and a bit of upload bandwidth. Skip renting anything and follow the install steps directly.
- If your group wants to log in independently at odd hours, a low-spec VPS (the 8GB/quad-core baseline covers a 4-player group comfortably [5]) removes the dependency on one person’s PC being on and connected. Most VPS providers give you a control panel that exposes
PalWorldSettings.inidirectly, so you can skip the SteamCMD install step entirely and jump to the settings section below. - If upload bandwidth at the host’s location is under roughly 10 Mbps, self-hosting will cause connection issues for the other 3 players regardless of how well-tuned the settings are — rent a VPS instead of troubleshooting a bandwidth problem with in-game settings.
Installing the Dedicated Server
Pocketpair ships the dedicated server as a free SteamCMD download, separate from the paid game client, under App ID 2394010 [1]. You don’t need to own Palworld on the machine running the server — SteamCMD’s anonymous login pulls the server files without a Steam account attached to the box.
steamcmd +login anonymous +app_update 2394010 validate +quit
Once that finishes, navigate into the install directory and run the server once to generate its config folders:
- Windows:
cd steamapps\common\PalServerthen runPalServer.exe[1] - Linux:
cd steamapps/common/PalServerthen run./PalServer.sh[1]
If you’d rather not manage SteamCMD directly, the community wiki documents two alternate paths: a Docker container for Linux boxes, and LinuxGSM for a scripted quick-start on either OS [9]. Both wrap the same SteamCMD process underneath — use them if you want automatic restart/update handling built in, skip them if you want to see exactly what’s happening on your machine.
Network Setup: Ports and Firewall
Only one port is actually required to play: UDP 8211, the game’s listen port [4]. Forward that through your router and allow it in your OS firewall and friends can connect directly with your IP and port, no further configuration needed.
Two additional ports exist for remote administration, and neither is needed for normal play: TCP 25575 for RCON (Pocketpair has deprecated this in favor of the newer REST API) and TCP 8212 for the REST API itself, which only needs to be open if you’ve set RESTAPIEnabled=True and plan to manage the server from outside the LAN [4]. If you’re hosting from your own PC for a 4-person group, leave both closed — they’re an unnecessary attack surface for a feature you won’t use.
Core Settings to Configure Before Anyone Connects
Every setting lives in one file: PalWorldSettings.ini, found at Pal\Saved\Config\WindowsServer\ on Windows or Pal/Saved/Config/LinuxServer/ on Linux [3]. Edit that file specifically — changes to DefaultPalWorldSettings.ini in the same folder are silently ignored [3]. The file is exactly two lines: a fixed header, then every setting packed into a single comma-separated OptionSettings=(...) block. One misplaced comma or bracket and the server ignores the whole file, so edit with a plain text editor and keep a backup of the working version before you touch it.
For a private 4-player group, set these immediately:
ServerName=andAdminPassword=— basic identification and admin accessServerPlayerMaxNum=8andCoopPlayerMaxNum=4— cap the server at your actual group size, not the 32-player default [6]bExistPlayerAfterLogout=False(default) if you want characters to disappear when offline, orTrueif your group prefers persistent bodies in the world while someone’s away [6]
There’s no reason to run a private co-op server at the default 32-player cap — every unused player slot the settings imply doesn’t cost anything on its own, but a lower, honest cap makes the next section’s tuning far more predictable.
Launch Arguments That Matter (and One That Doesn’t Anymore)
The startup options field in Steam (or your launch script) is where you set the port, player cap, and lobby visibility:
-port=8211 -players=4 -publiclobby
For years, the standard advice was to bolt on -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS as a fixed trio for better tick rate. Pocketpair’s own current documentation walks that back: in 1.0 and later, leaving these flags unset sometimes performs better, not worse [2]. The underlying simulation is still single-thread-bound regardless of these flags — they mainly affect I/O and asset loading, not raw tick rate — so the old blanket recommendation to always enable them is now stale advice. Test your server with and without them under real load before locking in a launch config, rather than copying a preset from a guide written before 1.0.
The 4 Settings That Actually Cause Lag on a Small Server
This is the part most setup guides skip, because they’re aimed at large public servers where the advice is different. On a 4-player box, the server isn’t struggling because of player count — it’s struggling because of how much the world is simulating around those 4 players. Four levers matter most, in priority order:
1. Turn off raid events — bEnableInvaderEnemy=False. The invader/raid spawning system is the single biggest contributor to climbing memory use over a session, leading to rubberbanding and eventual crashes on long-running servers [7]. For a private co-op group that isn’t relying on raids for progression content, this is the highest-impact change available and costs nothing to disable.
2. Cut the Pal sync distance — ServerReplicatePawnCullDistance. Default is 15,000cm; Pocketpair’s own documentation puts the valid range at 5,000–15,000cm [3][7]. Every Pal within this radius of a player gets tracked and network-synced continuously. Dropping it to 5,000–8,000cm on a small server means far fewer Pals being simulated and transmitted per player at any given moment, with minimal practical impact on a 4-player group’s field of view.
3. Lower the worker cap per base — BaseCampWorkerMaxNum. Default is 20, with an official hard ceiling of 50 [3][7]. More working Pals per base means more AI pathfinding and task-assignment calculations running continuously. Dropping this to 12–15 for a small group barely changes how a 4-person base functions day to day, since you won’t be running 20-Pal mega-bases anyway, but it meaningfully cuts the AI workload the server carries.
4. Trim world density — PalSpawnNumRate and DropItemMaxNum. Cutting spawn rate from the 1.0 default to 0.8 reduces the number of wild Pals the server has to spawn, track, and path continuously [7]. Capping dropped items (default 3,000) closer to 1,500–2,000 prevents abandoned loot and drops from combat/farming runs accumulating into clutter the server keeps rendering and syncing [7]. Neither change is noticeable during actual play on a small map footprint; both reduce background load.
None of these four require touching Engine.ini or messing with tick-rate settings — they’re plain entries in the same PalWorldSettings.ini block you already edited for player caps.
Which Settings Matter for Your Situation
| If you are… | Prioritize |
|---|---|
| Hosting for the first time on your own gaming PC | Get the 4 basic install steps right first, then apply raid/cull-distance changes before your first session — don’t wait for lag to appear |
| Migrating an existing laggy server | Apply the 4 performance settings immediately, then schedule a restart within 24 hours — the leak has likely already accumulated |
| Renting from a managed host (VPS/game panel) | Skip the SteamCMD/port steps entirely — your host handles those — and go straight to the PalWorldSettings.ini tuning section, since most panels expose that file directly |
| Running the server on the same PC you’ll play on | Cap ServerPlayerMaxNum tightly and keep the worker/spawn settings conservative — you’re competing with the game client for the same CPU cores |
Maintenance: Restarts and Backups
The memory leak isn’t a bug you can configuration your way out of — the standard fix across every source covering it is a scheduled restart, not more hardware [6][7]. Left unmanaged, community reports put the crash window at 5–7 days of continuous uptime for a small server [6]. A single daily restart, timed for whenever your group is least likely to be online, keeps usage from ever approaching that ceiling.
Back up your PalWorldSettings.ini and your save folder before making changes to either. The 1.0 update improved the save process specifically to reduce corruption risk during normal operation [8], but that’s a mitigation, not a guarantee — a bad edit to the settings file (a stray comma in that single-line block) will still cause the server to ignore your configuration on the next boot.
What Changed in Palworld 1.0 for Server Hosts
A few 1.0 changes are worth knowing before you assume your server behaves like it did in Early Access. Dedicated servers now default to the same difficulty as single-player Normal mode, rather than a separate harsher default [8]. Built-in voice chat is available as a toggle in world settings for dedicated servers, though not on the Microsoft Store PC version [8]. Guilds gained proper roles with configurable permissions, login/logout notifications, and the ability to lock specific structures to a role — useful even for a 4-person group if you want to keep one player’s crafting station off-limits to accidental disassembly [8]. None of these require action on your part, but they’ll change what your group sees on first login after an update.
FAQ
Do I really need 32GB of RAM to host for 4 players?
No — that’s Pocketpair’s baseline for a full 32-player server. A 4-player co-op group runs fine on 8GB budgeted realistically, which accounts for where the memory leak settles after a week, not just where it starts [5][6]. Buying 32GB for a 4-person group solves a problem you don’t have.
Should I still use the -UseMultithreadForDS launch flags everyone recommends?
Test both ways. Pocketpair’s current documentation specifically notes that leaving these unset can perform better in 1.0+, which contradicts older guides written for pre-1.0 builds [2]. There’s no universal right answer here — it depends on your specific hardware, which is exactly why you should benchmark instead of copying a preset.
Can I host the server on the same PC I’m playing on?
Yes, for a 4-player group, as long as you have the RAM headroom for both the client and server processes and you’ve applied the small-server tuning above. You’re sharing CPU cores between the game client and the server process, so the worker-cap and cull-distance settings matter more here than on a dedicated box, not less.
Is it worth opening the RCON or REST API ports for a small private group?
Generally no. Both exist for remote administration of servers you’re not physically sitting at — useful for a public server with a rotating player base, unnecessary attack surface for a 4-person group you can just alt-tab to manage directly [4].
For client-side FPS and graphics tuning rather than server configuration, see our Palworld PC settings guide. If your server crashes on startup rather than lagging mid-session, check our crashing fix guide first. Once your base is running, our best worker Pals and base building guide cover getting the most out of the lower worker caps recommended above, and our breeding guide is a natural next stop once your group is settled in. For everything else in Palworld, start with our Palworld beginner’s guide.
Sources
- Deploy dedicated server — Palworld Server Guide (official)
- Configure the server: Arguments — Palworld Server Guide (official)
- Configuration parameters — Palworld Server Guide (official)
- Palworld Server Ports: Which Ports to Open — XGamingServer
- Palworld Server Requirements: How Much RAM & CPU You Need (2026) — XGamingServer
- Palworld dedicated server setup: a 2026 guide that doesn’t lie about RAM — Renzom
- Best Palworld Server Settings for Performance and Less Lag — Nodecraft
- Palworld 1.0 is Out: Patch Notes Breakdown — MineStrator
- Dedicated server — The Palworld Wiki
I've been playing video games for over 20 years, spanning everything from early PC titles to modern open-world games. I started Switchblade Gaming to publish the kind of accurate, well-researched guides I always wanted to find — built on primary sources, tested in-game, and kept up to date after patches. I currently focus on Minecraft and Pokémon GO.
