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, and two config settings that look like they should work but silently don't.

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, SteamCMD needs its 32-bit dependencies pulled in 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, which is 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 need to open it by hand at some point, nano -w disables line-wrapping (or Ctrl+W to search within the file) — without it, 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

Rather than forwarding 8211/UDP on the home router directly, 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 ever learns the actual home IP, and no inbound port needs to be opened 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's not a permissions/whitelist issue in the way you'd expect — it's one specific setting in PalWorldSettings.ini:

bIsMultiplay=True

With it left at the default False, only whoever personally founded a given 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 permissions inside the game itself; it's a single global server setting that's easy to miss because the name doesn't obviously describe what it does.

PvP damage needs three settings, not one

Flipping bIsPvP=True alone does not enable any actual player-vs-player combat — it's a visibility/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 happening after enabling PvP, this is the first thing to check — not a bug, just three settings doing three genuinely separate things that a single "PvP" toggle would suggest is just one.