There are two multiplayer Palworlds and they have almost nothing in common. In-game online co-op supports up to four players and runs on the host’s machine, which means the world exists only while that person is playing and the world’s performance is that person’s performance. A dedicated server supports up to 32 and runs independently, which is what you want the moment more than three friends care about the base.
Palworld hit version 1.0 on 10 July 2026 after its long early access run, and the server side did not change shape with it. Same SteamCMD app ID, same configuration file, same set of mistakes people make on the way in. Here is the whole thing.
Standing the server up
The server is a separate Steam application from the game. App ID 2394010, free, and the initial download is roughly 12 to 15 GB. You install it with SteamCMD rather than the Steam client, which is a five-minute detour if you have never used it and is the same on Windows and Linux.
steamcmd +login anonymous +app_update 2394010 validate +quitRun the server binary once and let it fully start before you touch anything. It generates its save and config directories on that first boot, and editing files that do not exist yet is the number one reason a new server ignores every setting you carefully typed.
Then the file that catches everybody. Palworld ships two configuration files. DefaultPalWorldSettings.ini is a reference copy that the server does not read. PalWorldSettings.ini, at PalServer/Pal/Saved/Config/WindowsServer on Windows or LinuxServer on Linux, is the one it actually reads, and it starts effectively empty. You must open the default file, copy its OptionSettings line wholesale into the real one, and then edit your values there. Editing DefaultPalWorldSettings.ini directly does nothing at all, and you will spend an evening wondering why the XP rate never changed.
Everything lives on one enormous single line inside OptionSettings=(...). It is ugly. Do not add line breaks trying to make it readable, because the parser will reject the whole block and silently fall back to defaults.
Ports and connecting
The default game port is UDP 8211. Pocketpair’s server documentation lists UDP only, so forward UDP 8211 from your router to the server machine’s local address and open it in that machine’s firewall as well. Two firewalls is the standard reason “the port is forwarded but nobody can join”.
Some setups also expose 27015 and 27016 for Steam queries, which is what makes the server appear in the in-game community list, and 25575 for RCON if you want remote admin commands. Neither is required. Players connect through Join Multiplayer Game, then Direct Connect, with your.ip.address:8211.
The RAM question, honestly
This is where hosting companies get vague. Pocketpair’s own requirements list a 4-core CPU and 16 GB of RAM, with more recommended for larger or busier servers.
What actually happens in practice:
- 8 GB boots and runs a small group of four to six people. It also sits close enough to the ceiling that an out-of-memory crash during a busy session is a real risk, which the official documentation itself warns about. If a host is selling you a Palworld plan at 8 GB, they are selling you the minimum viable thing.
- 16 GB is the number to build to for a normal friend group with a few established bases.
- 32 GB is what you want if you are actually approaching the 32-player ceiling, or running long uptime with a heavily built world.
The other half of this is memory creep. Palworld servers grow their memory footprint over hours of uptime and do not fully release it. This is not your hardware failing and it is not a leak you can configure away. The fix everybody eventually lands on is a scheduled daily restart during a quiet hour, which drops usage back to baseline and takes about a minute of downtime. Set it up on day one via Task Scheduler or a systemd timer and you will never think about it again.
Memory usage climbing over a week is normal server behaviour, not a symptom. Restart it on a schedule and stop diagnosing it.
CPU matters less than people expect, but single-thread performance matters more than core count, because the world simulation does not spread itself evenly. Storage should be an SSD, and the save directory should be backed up, because base and Pal data is exactly the sort of thing that is unrecoverable and irreplaceable at the same time.
Self-host or rent
The costed version of the decision:
Self-hosting on a spare machine costs you electricity and nothing else. An old desktop with 16 GB of RAM and an SSD sitting in a cupboard is a perfectly good Palworld server. The real costs are your home upload bandwidth, your router configuration, and the fact that everybody’s session ends when your power flickers. It is the right answer if you already own the hardware.
Renting a VPS puts you in control of the configuration with none of the router work. You are looking at general-purpose cloud instances with 16 GB of memory, which sit in the same monthly bracket as a mid-tier streaming subscription stack. You install SteamCMD yourself, exactly as above.
Renting a managed game host is the same server with a web panel bolted on, priced per slot. It is worth it if nobody in the group wants to own the operations, and it is not worth it if one of you enjoys this. The thing to check before you pay is the memory allocation, not the slot count. A 32-slot plan with 8 GB behind it is a marketing number.
Settings actually worth changing
The config file is enormous and most of it should stay alone. The ones that change how the group plays:
ExpRateand the gather and hatch multipliers. Modest increases, in the region of a small multiple, keep a weeknight group progressing at a pace that feels like a game rather than a job.DeathPenalty. The default drops items on death, which in a shared world with a long walk back is the single biggest source of people quietly not logging in again.bIsPvP. Off unless everybody said yes.ServerName,ServerDescriptionandAdminPassword. Set the admin password before the server is ever reachable from the internet, not after.bEnableInvaderEnemyif base raids are ruining unattended bases while everyone is offline.
None of this is difficult. The whole setup is one SteamCMD command, one copy-paste between two config files, one forwarded UDP port, and a scheduled restart. The parts that trip people are the config file that is not the config file, the second firewall, and a memory figure the hosting market would rather you did not check.
Sources: Steam store: Palworld, Steam Community guide: Palworld dedicated server with SteamCMD, Host Havoc: Palworld dedicated server setup, Renzom: Palworld dedicated server setup and RAM
