Palworld Dedicated Server: The Complete Setup Guide

If you want to keep playing Palworld with the same group over weeks rather than one evening, you need a dedicated server: nobody has to keep the game open, the world stays up around the clock, and your bases and Pals keep working while you're offline. This guide walks the whole thing — sizing the machine, installing the server, opening the right ports, the settings worth changing first, and how to keep your saves — then does the math on running it yourself versus having it hosted.

Pick the right multiplayer mode first

Palworld has three multiplayer routes, and they are different entries in the game with very different capabilities. Most people who get stuck picked the invite-code route and then discovered the world stops when the host quits.

The dedicated route is the Join Multiplayer Game (Dedicated Server) option on the title screen — the part in parentheses matters, because the invite-code path can't reach a dedicated server at all. The client gives you a single address field, so you type the address and port together, like 203.0.113.10:8211.

How much machine you need

The Palworld server wants memory far more than it wants cores. What makes a world stutter is not the player count — it's how many bases and Pals have piled up in the world. A group that only starts lagging in week three is almost always hitting this.

A few rules of thumb:

• Size memory for the world, not the headcount. The same four players on a month-old world will use several GB more than on a fresh one.
• Leave disk for saves and their history. A save is small; the backups you'll want to keep are not.
• Single-core speed beats core count. The server's main loop doesn't spread across cores, so a higher-clocked machine feels better than a wider one.
• Ubuntu 22.04 or Debian 12 are both fine. The steps below are Linux; on Windows they're equivalent, with WindowsServer in place of LinuxServer in the config path.

Running it yourself, from SteamCMD to your first login

Install SteamCMD and dependencies

The server needs 32-bit libraries, so enable the i386 architecture on Debian-family systems:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd lib32gcc-s1 xdg-user-dirs

Run it as its own unprivileged user rather than root:

sudo useradd -m -s /bin/bash palserver
sudo -iu palserver

Download the server

The dedicated server's App ID is 2394010 — note that it is not the game's own ID (1623730):

steamcmd +force_install_dir ~/palworld \
         +login anonymous \
         +app_update 2394010 validate \
         +quit

Anonymous login is all you need. The server doesn't use your Steam account and doesn't consume your copy of the game — but everyone connecting still needs to own Palworld on Steam.

Start it once to generate the config

cd ~/palworld
./PalServer.sh

Wait a few seconds after Setting breakpad minidump AppID appears in the log, then Ctrl+C. The only point of this first run is to let the server lay down its default files.

Edit the world settings

The file that actually takes effect is here:

~/palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

The one generated on first run is an empty shell — copy the defaults over it before editing:

cp ~/palworld/DefaultPalWorldSettings.ini \
   ~/palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

The format catches people out: every option lives on one single line inside OptionSettings=(...), comma-separated, no line breaks, and string values need double quotes. Keep a copy before you start editing.

The ones you have to set:

The gameplay options worth tuning on day one:

Save, start the server again, and the settings are live.

Open the ports

Skipping this looks like "the server log is perfectly happy and nobody can connect." It's the single most common sticking point.

Two mistakes account for most of it:

• 8211 is UDP, not TCP. Open only TCP and a port scanner will cheerfully report it open while the game still can't connect.
• On a cloud machine you must open both the provider's security group and the host firewall (ufw / firewalld). Traffic only flows when both allow it.

One hard warning about the management API: the Palworld developers explicitly say the REST API should not be exposed directly to the internet. Bind it to a private address or restrict the source with a firewall. Also note that Palworld's RCON is deprecated and the developers have announced it will stop working — if a guide is still walking you through RCON, it's out of date.

Start it on boot

A server launched by hand dies with the terminal. Give it a systemd unit:

[Unit]
Description=Palworld Dedicated Server
After=network-online.target

[Service]
Type=simple
User=palserver
WorkingDirectory=/home/palserver/palworld
ExecStart=/home/palserver/palworld/PalServer.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Save it as /etc/systemd/system/palworld.service, then:

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

Where your saves are, and how to back them up

Save path:

~/palworld/Pal/Saved/SaveGames/0/<WorldID>/

<WorldID> is a hexadecimal directory name, one per world. Backing up means copying that whole directory.

Don't copy a save while the server is writing to it. You can walk away with a half-written file, and you'll only find out on the day you try to restore it. The right order is to make the server flush first — stop it, or trigger a forced save through the management API — and copy afterwards.

A backup routine that actually holds up:

• One a day, keep seven
• One extra by hand before every game update
• Not on the same disk as the server

Losing a save is the one failure on this kind of server you can't undo. Dated directories and a history you can roll back to are worth more than any tuning.

Nobody can get in after a game update

The Palworld client updates itself; your server does not. The moment a patch ships, everyone stalls on the connect screen — a server left on the old build is the number-one cause of "suddenly nobody can join."

The order that works:

sudo systemctl stop palworld
# back up the save first, then update
sudo -iu palserver steamcmd +force_install_dir ~/palworld \
     +login anonymous +app_update 2394010 validate +quit
sudo systemctl start palworld

Back up first, update second. Not the other way round.

Common questions

It never shows up in the server list, but direct connect works. That's normal. The community list is unreliable; send your group the address and have them connect directly.

It gets choppy once a few people are on. Check whether memory is maxed out first, then look at how many bases are in the world. Clearing out the bases left behind by players who quit usually brings the frame rate back.

My config changes did nothing. Almost always the wrong file (DefaultPalWorldSettings.ini instead of the one under Pal/Saved/Config/), or an editor wrapped that long OptionSettings=(...) line.

I want to kick or ban someone. You need the management API on and AdminPassword set, and you act on the player's userId rather than their display name — names can be changed.

Running it yourself versus having it hosted

The cost of the DIY route isn't day one. It's every week after that:

The test is simple: are you willing to spend two hours a week on it? If you are, the DIY route is entirely workable and the steps above are enough to get there. If you aren't, those two hours are exactly what a hosting service is selling.

That second column is what KeepWorlds does. Pick a game and a plan and the server launches on a machine of its own — not shared with anyone else — with backups, game updates and expiry reminders handled for you. Once it's up, Console → My servers shows the server address, who's online and the current status; copy the address in one click and follow the walkthrough on the page to connect.

• See the Palworld plans and regions
• Connection guide and FAQ

If it turns out not to fit once it's running, there's a refund policy for that. For anything else, the support links on every page reach us.