Self-Hosting a Public Palworld Dedicated Server

A real, always-on Palworld dedicated server. Installed via SteamCMD on plain Linux, exposed to the internet without forwarding a port on your home router or leaking your home IP. Plus two config settings that look like they should work and silently do not.

Installing via SteamCMD

Palworld's dedicated server is Steam App ID 2394010, installable anonymously. No Steam account needed for the server itself. On a fresh Ubuntu box, pull in SteamCMD's 32-bit dependencies first:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y lib32gcc-s1 libsdl2-2.0-0:i386 wget curl

mkdir -p ~/steamcmd && cd ~/steamcmd
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
tar -xvzf steamcmd_linux.tar.gz
./steamcmd.sh +quit

~/steamcmd/steamcmd.sh \
  +force_install_dir /home/<user>/palworld-server \
  +login anonymous \
  +app_update 2394010 validate \
  +quit

Configuration without fighting a single-line INI file

Palworld's settings live in one enormous single-line INI, miserable to hand-edit in a terminal editor. sed is faster and less error-prone than opening it at all:

mkdir -p ~/palworld-server/Pal/Saved/Config/LinuxServer
cp DefaultPalWorldSettings.ini Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

sed -i 's/ServerPassword="[^"]*"/ServerPassword="<password>"/' PalWorldSettings.ini
sed -i 's/AdminPassword="[^"]*"/AdminPassword="<admin_password>"/' PalWorldSettings.ini
sed -i 's/ServerName="[^"]*"/ServerName="My Server"/' PalWorldSettings.ini

If you do have to open it by hand, nano -w disables line-wrapping, and Ctrl+W searches within the file. Without those the single giant line is nearly unnavigable.

Firewall and systemd service

sudo ufw allow ssh          # do this FIRST or you'll lock yourself out
sudo ufw allow 8211/udp
sudo ufw allow 8211/tcp
sudo ufw enable

# /etc/systemd/system/palworld.service
[Unit]
Description=Palworld Dedicated Server
After=network.target

[Service]
Type=simple
User=<user>
WorkingDirectory=/home/<user>/palworld-server
ExecStart=/home/<user>/palworld-server/PalServer.sh -log -nosteam -port=8211 -players=32
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now palworld

Exposing it publicly without a port-forward or a leaked home IP

Instead of forwarding 8211/UDP on the home router, the server dials out to a small relay on a cheap VPS running frp, which republishes the port under a real domain. Nobody connecting to the game learns the home IP, and no inbound port opens on the router at all.

The guild-building setting that isn't where you'd look for it

If a guild member reports "no permission to build" on a base someone else in the same guild founded, it is not a permissions or whitelist issue. It is one setting in PalWorldSettings.ini:

bIsMultiplay=True

Left at the default False, only whoever personally founded a base camp can build on or interact with it. Every other guild member, family included, is silently blocked. It has nothing to do with guild roles or in-game permissions. It is one global server setting, easy to miss because the name does not describe what it does.

PvP damage needs three settings, not one

Flipping bIsPvP=True alone enables no player-versus-player combat at all. It is a visibility and matchmaking flag, not a damage switch. Real PvP damage needs a separate master switch, and same-guild friendly fire needs a third:

bIsPvP=True
bEnablePlayerToPlayerDamage=True
bEnableFriendlyFire=True   # only needed if you want damage between guildmates too

All three live in the same INI file. If players report zero damage after you enable PvP, check this first. Not a bug. Three settings doing three separate things that a single "PvP" toggle implies is one.