Monter un serveur dédié Palworld chez soi : ce qu'il faut vraiment savoir

Running a Palworld dedicated server on a machine sitting in your living room is entirely doable: SteamCMD pulls the binaries, PalServer launches with a handful of arguments, and PalWorldSettings.ini controls everything from capture rates to RCON. What follows is the full technical path, plus the hard limits a domestic line and a desktop CPU will hit once your guild grows.

Installing a Palworld dedicated server with SteamCMD

The server binaries are distributed as a separate Steam application (App ID 2394010) and are available anonymously — no Steam account credentials required. The same App ID serves both the Windows and Linux builds, and both are considered official by Pocketpair.

Windows installation

Download SteamCMD, extract it to something short like C:\steamcmd, then run:

cd C:\steamcmd
steamcmd.exe +force_install_dir C:\palserver +login anonymous +app_update 2394010 validate +quit

Once finished, the executable lives at C:\palserver\PalServer.exe. Launch it once and shut it down immediately — this generates the save folder and the config tree you will edit later.

Linux installation

On Debian or Ubuntu, enable multiarch (the binary is 32-bit-dependent through the Steam runtime) and create a dedicated system user rather than running everything as root:

sudo dpkg --add-architecture i386
sudo apt update && sudo apt install -y steamcmd lib32gcc-s1 xdg-user-dirs
sudo useradd -m -s /bin/bash palworld
sudo su - palworld
steamcmd +force_install_dir /home/palworld/palserver +login anonymous +app_update 2394010 validate +quit

The Linux build needs the Steamworks client library in a very specific place, otherwise the process starts and exits without a clear error:

mkdir -p ~/.steam/sdk64
ln -s ~/.steam/steam/steamapps/common/Steamworks\ SDK\ Redist/linux64/steamclient.so ~/.steam/sdk64/steamclient.so

Then start it with ./PalServer.sh. If you prefer a managed environment with a live console, file manager, scheduled restarts and automatic backups instead of maintaining SteamCMD scripts yourself, Palworld server hosting handles the update loop and the network layer for you. For everything else covered here, the local approach works fine — just keep reading, because the limits are real.

Keeping the build up to date

Palworld patches break client/server compatibility instantly: an outdated build refuses connections with a version mismatch. Re-run the same SteamCMD line after every game patch. On Linux, a small wrapper script that updates then launches is the pragmatic answer:

#!/bin/bash
/usr/games/steamcmd +force_install_dir /home/palworld/palserver \
  +login anonymous +app_update 2394010 validate +quit
cd /home/palworld/palserver
./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

Launch parameters and PalWorldSettings.ini tuning

The command line arguments that actually matter

PalServer accepts a short list of Unreal Engine flags. These three are the ones with a measurable effect on a busy world:

Argument	Effect
-useperfthreads	Enables the performance-oriented thread pool of the engine.
-NoAsyncLoadingThread	Disables the asynchronous loading thread, reducing stalls on world streaming.
-UseMultithreadForDS	Spreads dedicated-server work across more than one core.
-port=8211	Overrides the UDP game port.
-players=32	Overrides the maximum slot count (32 is the documented ceiling).
-publiclobby	Lists the instance in the community browser (also requires EpicApp=Palworld for Epic clients).

Combine them in one line, for example on Windows:

PalServer.exe -port=8211 -players=16 -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

Editing the configuration file correctly

This is where most people break their world. Do not edit DefaultPalWorldSettings.ini at the root of the install — it is a template and gets overwritten. Copy its contents into the active file:

• Windows: C:\palserver\Pal\Saved\Config\WindowsServer\PalWorldSettings.ini
• Linux: ~/palserver/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

The whole OptionSettings=(...) block must stay on a single line. One stray line break and the file is ignored silently, the world resets to default rates, and players notice before you do.

[/Script/Pal.PalGameWorldSettings]
OptionSettings=(Difficulty=None,DayTimeSpeedRate=1.000000,NightTimeSpeedRate=1.000000,ExpRate=1.500000,PalCaptureRate=1.200000,PalSpawnNumRate=1.000000,PalDamageRateAttack=1.000000,PalDamageRateDefense=1.000000,PlayerDamageRateAttack=1.000000,PlayerStomachDecreaceRate=0.700000,CollectionDropRate=1.500000,EnablePlayerToPlayerDamage=False,DeathPenalty=Item,bEnableDefenseOtherGuildPlayer=False,GuildPlayerMaxNum=16,BaseCampMaxNumInGuild=4,PalEggDefaultHatchingTime=24.000000,bIsUseBackupSaveData=True,AutoSaveSpan=180.000000,ServerPlayerMaxNum=16,ServerName="My Palworld world",ServerDescription="Private guild server",AdminPassword="ChangeThisNow",ServerPassword="",PublicPort=8211,PublicIP="",RCONEnabled=True,RCONPort=25575,Region="",bUseAuth=True,BanListURL="https://api.palworldgame.com/api/banlist.txt")

Settings worth changing first

• AutoSaveSpan: default is 30 seconds. Raising it to 120–180 reduces disk churn on slow storage, but increases what you lose on a crash. On NVMe, keeping it low is painless.
• BaseCampMaxNumInGuild and PalSpawnNumRate: these two drive entity count more than anything else. Every extra base camp is permanently simulated memory and CPU.
• bIsUseBackupSaveData: leave it on. It writes rolling copies under Pal/Saved/SaveGames/.
• AdminPassword: mandatory, long, random. It is the key to RCON and to in-game admin commands.
• ServerPlayerMaxNum: keep it aligned with -players, otherwise the lower value wins and you get confusing "server full" reports.

RCON and remote administration

With RCONEnabled=True, you can drive the world without being in-game: broadcast messages, kick, ban, save, shutdown with countdown. Any standard RCON client works:

Broadcast Restart_in_5_minutes
ShowPlayers
KickPlayer <SteamID>
Save
Shutdown 300 Scheduled_maintenance

Never expose port 25575 to the open internet. Bind it to localhost or reach it through an SSH tunnel:

ssh -L 25575:127.0.0.1:25575 palworld@your-machine-address

Network layer: UDP 8211, NAT and the home line reality

Ports to open

Palworld is UDP-only for gameplay traffic. Three entries cover a complete setup:

Port	Protocol	Role
8211	UDP	Game traffic (mandatory)
27015	UDP	Steam query / community browser listing
25575	TCP	RCON — keep it internal only

On a Linux box with ufw:

sudo ufw allow 8211/udp
sudo ufw allow 27015/udp
sudo ufw deny 25575/tcp
sudo ufw enable
sudo ufw status numbered

On Windows, create an inbound rule rather than disabling the firewall:

netsh advfirewall firewall add rule name="Palworld UDP 8211" dir=in action=allow protocol=UDP localport=8211
netsh advfirewall firewall add rule name="Palworld Query 27015" dir=in action=allow protocol=UDP localport=27015

Port forwarding on the router

Forward external UDP 8211 to the internal IPv4 of the machine, on the same port. Two details that cause 90% of "friends can't join" tickets:

• Give the machine a static DHCP lease. If its LAN address changes after a reboot, the forwarding rule points at nothing.
• Most domestic routers do not support NAT hairpinning. Players on your own LAN must connect using the local address (192.168.x.x:8211), not the public one.

CGNAT, dynamic IP and the things you cannot fix

If your connection sits behind Carrier-Grade NAT — common on 4G/5G boxes and some fiber offers — inbound UDP simply never reaches you, and no router setting changes that. Check whether the WAN address shown by the router matches the one reported by an external IP lookup. If they differ, port forwarding is dead on arrival.

Dynamic public IP is a milder problem: the address changes after a reconnection and everyone's saved entry breaks. A DDNS record updated by the router or a small cron job keeps a stable name pointing at you.

Upstream bandwidth is the real ceiling

Downstream is irrelevant here — the machine sends state to every connected client. Palworld replicates player positions, Pal AI, base structures and creature behaviour continuously, so upstream usage scales roughly with the number of connected clients multiplied by the density of loaded entities. An ADSL or VDSL line with a modest upload will hold two or three players in a sparse world and fall apart the moment four people load their base camps simultaneously. Symptoms are unmistakable: rubber-banding Pals, delayed damage, chests that reopen empty.

Latency is the second half of the equation. A domestic line shares its uplink with streaming, cloud sync and every other device in the house. Any saturation translates into jitter for the players, and Palworld's replication tolerates jitter poorly.

CPU, RAM and the technical limits of running a Palworld dedicated server at home

Memory consumption and the leak everyone hits

A freshly generated world starts modestly, but a Palworld dedicated server does not keep a flat memory profile. Consumption grows with playtime, guild count, base camp count and the number of Pals assigned to work. Long uptime sessions show steadily increasing RSS that never comes back down — a well-documented behaviour of the current builds. Practical baseline:

• 8 GB of RAM available to the process for a small guild on a young world.
• 16 GB and above once several guilds run multiple developed base camps.
• Watch it live with htop, or on Linux:

ps -o pid,rss,etime,cmd -C PalServer-Linux-Shipping
watch -n 5 'free -m'

The pragmatic mitigation is a scheduled restart. A daily or twice-daily automated restart with an RCON warning releases the accumulated memory before the machine starts swapping:

# crontab -e  (user palworld)
0 6 * * * /home/palworld/scripts/rcon.sh "Shutdown 120 Daily_maintenance"

Pair it with a systemd unit so the process comes back automatically:

[Unit]
Description=Palworld dedicated server
After=network-online.target

[Service]
Type=simple
User=palworld
WorkingDirectory=/home/palworld/palserver
ExecStart=/home/palworld/palserver/PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
Restart=always
RestartSec=15

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now palworld
sudo journalctl -u palworld -f

CPU: single-thread frequency wins

Despite -UseMultithreadForDS, the simulation loop remains heavily dependent on single-thread performance. A modern high-frequency Ryzen core handles a populated world far more comfortably than an older many-core chip running at a lower clock. Tick degradation shows up as delayed Pal work animations, sluggish breeding timers and inconsistent damage registration long before the CPU graph looks saturated.

Storage matters too: autosaves write the full world state periodically. On a mechanical drive, each save produces a visible hitch for every connected player. NVMe removes that entirely.

The limits you cannot engineer away at home

• Availability: your world is offline whenever the machine reboots, Windows updates, or the power flickers.
• Attack surface: a public UDP port on a residential line has no volumetric filtering in front of it. A single angry player with a booter takes down your entire household connection, not just the game.
• Backups: copying Pal/Saved/SaveGames/ to another disk on the same machine is not a backup. Push it off-site.
• Machine sharing: playing on the same PC that runs the world means the client and the simulation compete for the same cores and the same uplink.

A remote machine on a datacenter link with anti-DDoS filtering, NVMe storage and a Pterodactyl panel removes the network variables entirely and leaves you with only the game configuration to manage. The same logic applies to most survival titles — the constraints described here are nearly identical on Valheim server or Enshrouded server setups, and you can see the full catalogue on All our game servers. More configuration walkthroughs are collected on the Fly-Serv blog, and the official parameter reference is maintained at Source.

Backup routine that actually protects the world

#!/bin/bash
STAMP=$(date +%Y%m%d-%H%M)
tar -czf /backups/palworld-$STAMP.tar.gz \
  /home/palworld/palserver/Pal/Saved/SaveGames \
  /home/palworld/palserver/Pal/Saved/Config
find /backups -name "palworld-*.tar.gz" -mtime +7 -delete

Run it right after the scheduled restart, when the world has just been written to disk and no session is active. Restoring is then a matter of stopping the process, replacing the SaveGames folder and starting again — provided the save UUID directory name is preserved exactly.

Conclusion

Getting Palworld running locally is a short technical path: SteamCMD, three launch flags, one long line in the configuration file and a UDP forwarding rule. Keeping it stable for a group is the hard part — memory drift, upstream saturation and a changing public address are structural constraints of a domestic line. Scheduled restarts, off-site save copies and honest slot limits keep the experience playable.

FAQ

Why do my friends see "connection timed out" while the console shows the world is running?

In nine cases out of ten the UDP 8211 rule is missing or points at the wrong LAN address. Verify the machine has a static DHCP lease, that the firewall rule is UDP (not TCP), and that your connection is not behind CGNAT — compare the WAN address shown by the router with your real public address. If they differ, inbound traffic never reaches you.

My PalWorldSettings.ini changes are ignored after every restart. What am I doing wrong?

You are probably editing DefaultPalWorldSettings.ini at the install root, which is only a template. Edit the file under Pal/Saved/Config/WindowsServer or LinuxServer instead, and keep the entire OptionSettings=(...) block on one single line. A line break inside that block invalidates the whole file silently.

How do I limit the memory drift without restarting in the middle of a session?

Schedule an automated restart during off-hours through RCON, using Shutdown with a countdown so connected players get a warning and a clean save. Reducing BaseCampMaxNumInGuild and PalSpawnNumRate also slows the growth, since entity count is the main driver of memory usage.