Set Up a Palworld Dedicated Server on a VPS (2026): SteamCMD, Ports, Configuration, Backups and Updates

Pocketpair's current official baseline is 4+ CPU cores, 16GB of memory and a fast SSD; 8GB may start, but insufficient memory raises the chance of crashes, and the official guidance recommends 32GB or more for larger servers. Palworld does not need a dedicated GPU, so when buying you should prioritize stable CPU performance, genuinely available memory, NVMe disks and UDP network quality.

Below are practical starting recommendations for buying a VPS, not official concurrency guarantees:

The data center should be close to your main players, and you should confirm the provider allows game servers, supports UDP, provides enough traffic and offers reasonable DDoS protection. For public servers, also ask clearly about the ban policy after an attack and the cost of changing IPs. If you need to compare routes and configurations, start with the game server VPS recommendations and configuration guide.

Pocketpair provides an official Docker image, but explicitly does not recommend running it on Docker Desktop for Windows/macOS, because disk I/O may cause save corruption and failure risks. This article chooses native Linux SteamCMD, whose paths are more transparent and which is better suited to a first self-hosted setup. If you want to manage multiple instances such as Minecraft, Rust and Palworld on the same machine, you can switch to setting up a Pterodactyl game server panel on a VPS; to compare another game server management approach, see the Rust dedicated server LinuxGSM tutorial.

A minimal working deployment only needs to expose one game port:

The official documentation has marked RCON as deprecated and states that support will end in a future update. Do not build new server management workflows around RCON; if you really need remote management, prefer the REST API and restrict it to 127.0.0.1, a LAN or a WireGuard/Tailscale management network. The REST API is a management interface, and exposing it directly to the internet may allow unauthorized operations.

Server type also affects how players join:

• Regular dedicated server: players join via public IP and port, suitable for Steam players and small groups.
• Community server: add -publiclobby at startup, and the server appears in the in-game list. Xbox or PS5 players need the community server entry point to join a self-hosted server.
• The current official default cross-platform list is Steam, Xbox, PS5 and Mac; do not use the obsolete AllowConnectPlatform anymore, use CrossplayPlatforms instead.

First update the system and install dependencies with an administrator account that has sudo privileges:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar lib32gcc-s1 ufw

Create a service account not used for daily login, and prepare the SteamCMD and Palworld directories:

sudo adduser --disabled-password --gecos "" palworld
sudo install -d -o palworld -g palworld /opt/steamcmd
sudo install -d -o palworld -g palworld /opt/palworld
sudo -iu palworld

Do not run the game server as root long term. A dedicated user limits file permissions and prevents the server process from directly holding administrative rights over the whole VPS.

The following commands run as the palworld user. First download the Linux SteamCMD from Valve's Steam CDN:

cd /opt/steamcmd
curl -fsSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz -o steamcmd_linux.tar.gz
tar -xzf steamcmd_linux.tar.gz
./steamcmd.sh +quit

Then log in anonymously and install the Palworld Dedicated Server. The official server App ID is 2394010:

/opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/palworld \
  +login anonymous \
  +app_update 2394010 validate \
  +quit

After Success! App '2394010' fully installed. appears, check the core files:

test -x /opt/palworld/PalServer.sh
ls -lah /opt/palworld

validate suits a first install or repairing corrupted files. Daily updates can omit it to avoid a full validation and extra disk reads and writes every time.

The configuration directory is only generated after the server has started at least once. Run it in the foreground first:

cd /opt/palworld
./PalServer.sh -port=8211 -players=16 -logformat=text

Wait for the logs to reach a normal running state, then press Ctrl+C to stop. Confirm the Linux configuration directory now exists:

test -d /opt/palworld/Pal/Saved/Config/LinuxServer

Copy a real configuration from the official default template:

cp /opt/palworld/DefaultPalWorldSettings.ini \
  /opt/palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
chmod 600 /opt/palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

The file that actually takes effect is Pal/Saved/Config/LinuxServer/PalWorldSettings.ini. Editing the DefaultPalWorldSettings.ini in the root directory directly will not change server settings — this is the most common reason for "I changed the config but nothing happened".

First generate two different random passwords and save them in a password manager:

openssl rand -base64 32
openssl rand -base64 32

The first can serve as the player join password, the second as the admin password. Edit the real configuration file:

nano /opt/palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

The main settings in this file are concentrated in one line, OptionSettings=(...). Do not delete the other keys in the template, and do not split the example across multiple lines; find and modify these fields in the existing line:

ServerName="My Palworld Server"
ServerDescription="Private server for friends"
ServerPassword="替换为玩家密码"
AdminPassword="替换为不同的管理员密码"
ServerPlayerMaxNum=16
CrossplayPlatforms=(Steam,Xbox,PS5,Mac)
bIsUseBackupSaveData=True
RESTAPIEnabled=True
RESTAPIPort=8212
RCONEnabled=False

After saving, check that the key fields really exist, but do not copy the whole line containing passwords into tickets, chats or public repositories:

grep -oE 'ServerName="[^"]*"|ServerPlayerMaxNum=[0-9]+|CrossplayPlatforms=\([^)]*\)|bIsUseBackupSaveData=(True|False)|RESTAPIEnabled=(True|False)|RCONEnabled=(True|False)' \
  /opt/palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

bIsUseBackupSaveData=True makes the server create an backup subdirectory in the save directory and keep multiple short-term backups according to the official policy. It increases disk load, so you should still use NVMe and keep an additional off-machine backup.

Exit the palworld user back to the administrator account:

exit
sudo nano /etc/systemd/system/palworld.service

Write the following single-instance service:

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

[Service]
Type=simple
User=palworld
Group=palworld
WorkingDirectory=/opt/palworld
ExecStart=/opt/palworld/PalServer.sh -port=8211 -players=16 -logformat=text
Restart=on-failure
RestartSec=10
KillSignal=SIGINT
TimeoutStopSec=120
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target

The official parameter page notes that starting with Palworld 1.0, not setting the old -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS combination may actually yield better performance, so do not copy old tutorials. Only adjust thread parameters when stress testing proves a benefit.

Load, start and check:

sudo systemctl daemon-reload
sudo systemctl enable --now palworld
sudo systemctl status palworld --no-pager
sudo journalctl -u palworld -n 100 --no-pager

Confirm that 8211/UDP and the local management port are listening:

sudo ss -lunp | grep ':8211'
sudo ss -lntp | grep ':8212'

If you are not using the REST API for now, change RESTAPIEnabled back to False and restart the service to reduce one management surface.

First keep the current SSH session open, and allow SSH and the game UDP port:

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

The cloud provider security group must also allow 8211/UDP. Opening only TCP 8211 is useless; if either the cloud security group or UFW is missed, external players cannot connect.

Even if the REST API is enabled, do not allow 8212 in the cloud security group. When you need to manage from your personal computer, first establish a WireGuard, Tailscale or SSH tunnel, then access it via a private or local address. A regular Cloudflare orange-cloud proxy also cannot directly proxy Palworld's UDP game traffic; the domain A record should stay DNS only, or just use the public IP directly.

For small-scale use by Steam players, keep the current systemd start command, and players join via public IP and port:

203.0.113.20:8211

Replace the example IP with the VPS's real public IPv4. If you want Xbox or PS5 players to find the server in the in-game list, change ExecStart to community server mode:

ExecStart=/opt/palworld/PalServer.sh -port=8211 -players=16 -publiclobby -publicip=203.0.113.20 -publicport=8211 -logformat=text

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart palworld
sudo journalctl -u palworld -n 100 --no-pager

-publicport only declares the external port shown in the community listing and does not change the server's real listen port; the actual listen port is still determined by -port. Registering in the server list takes time; if the list cannot find it for now, first check the logs, UDP firewall and public IP, and do not blindly open a string of ports from unknown sources at the same time.

The official REST API supports querying server info, players, settings and metrics, and can also save the world, broadcast, kick, ban and shut down the server. It uses HTTP Basic Auth, but the official documentation does not fix a username in the general description page, so rely on the current server version and actual client configuration, and do not treat default usernames from third-party tutorials as permanently valid facts.

First test whether the interface responds only on the VPS itself:

curl -i http://127.0.0.1:8212/v1/api/info

Returning 401 Unauthorized actually shows the interface exists and authentication is in effect. When configuring management scripts, have them read from a restricted environment file or password manager, and do not write the admin password directly into shell history. Operations programs should first call the official /save to save the world, then call /shutdown to shut down gracefully; do not default to /stop forced termination.

If your needs are only periodic updates and backups, you can skip the REST API entirely and do it all via SSH, systemd and stop-the-server backups, without adding public attack surface just to "have a panel".

Palworld's built-in backups suit quick rollbacks but cannot replace off-machine backups for VPS failures, accidental deletion and disk damage. It is recommended to use both:

1. bIsUseBackupSaveData=True generates short-interval internal backups.
2. After stopping the server, archive the entire Pal/Saved and sync it to another machine or object storage.

Create a local backup directory:

sudo install -d -m 750 -o root -g palworld /var/backups/palworld

In a maintenance window, stop the server and archive the saves, configuration and internal backups:

sudo systemctl stop palworld
sudo tar -C /opt/palworld/Pal -czf \
  "/var/backups/palworld/palworld-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  Saved
sudo systemctl start palworld
sudo systemctl is-active palworld

List the archive and spot-check its contents:

sudo ls -lh /var/backups/palworld
sudo tar -tzf /var/backups/palworld/palworld-YYYYMMDDTHHMMSSZ.tar.gz | head -n 30

Replace the example filename with the actual file. Keep at least one copy of the backup off-machine, and do restore drills regularly. If you need to include restic, rclone, databases and Docker in disaster recovery, see the VPS backup and restore drill guide.

Before restoring, stop the service and check the archive; never directly overwrite the only existing world:

sudo systemctl stop palworld
sudo tar -tzf /var/backups/palworld/palworld-YYYYMMDDTHHMMSSZ.tar.gz | head -n 30
sudo mv /opt/palworld/Pal/Saved \
  "/opt/palworld/Pal/Saved.before-restore-$(date -u +%Y%m%dT%H%M%SZ)"
sudo tar -C /opt/palworld/Pal -xzf \
  /var/backups/palworld/palworld-YYYYMMDDTHHMMSSZ.tar.gz
sudo chown -R palworld:palworld /opt/palworld/Pal/Saved
sudo systemctl start palworld

Then check that the service, logs and world are correct:

sudo systemctl status palworld --no-pager
sudo journalctl -u palworld -n 150 --no-pager
sudo find /opt/palworld/Pal/Saved/SaveGames -maxdepth 3 -type f | head

Only after entering the game and confirming characters, guilds, bases and the world date is the restore successful. "The archive can be extracted" alone does not prove the business is recoverable. Keep Saved.before-restore-* until you have confirmed everything, and do not rush to delete it.

When client and server versions do not match, players usually cannot join normally. Before updating, notify players, save the world and back up, then run SteamCMD:

sudo systemctl stop palworld
sudo tar -C /opt/palworld/Pal -czf \
  "/var/backups/palworld/palworld-before-update-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  Saved
sudo -u palworld /opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/palworld \
  +login anonymous \
  +app_update 2394010 \
  +quit
sudo systemctl start palworld

Check immediately after updating:

sudo systemctl is-active palworld
sudo journalctl -u palworld -n 150 --no-pager
sudo ss -lunp | grep ':8211'

Do not overwrite binaries while the process is running, and do not set up "unattended restart the moment Steam publishes an update". A safer approach is to run in a fixed maintenance window: broadcast in advance, confirm nobody is online, back up, stop, update, start, verify, then allow players in.

Look at real resources first, rather than guessing from "vCPU count":

free -h
df -h /opt/palworld /var/backups/palworld
uptime
ps -C PalServer-Linux-Test -o pid,%cpu,%mem,rss,etime,cmd
sudo journalctl -u palworld --since "30 minutes ago" --no-pager

Watch these signals over time:

• Memory keeps approaching the limit, logs show OOM or the process is killed by the system: upgrade memory, do not rely on swap to tough it out.
• A single core stays fully loaded but overall CPU is not high: prefer a node with stronger single-core performance rather than just adding more slow cores.
• Latency rises when players gather at large bases: reduce excessive structures, base worker Pals and high-load rates, and restart during off-peak hours.
• Saves and internal backups grow quickly: expand the disk, set an external backup retention policy, and monitor inodes and free space.
• Network jitter or packet loss: migrate to a data center closer to players with more stable UDP quality and protection.

For a public server, do not set the player cap to 32 from the start. Run with 8-16 players for a week first, record peak memory, CPU, save growth and latency, then scale up gradually.

• The server runs as a dedicated palworld user, not root.
• systemctl is-active palworld returns active.
• ss shows 8211/UDP listening.
• Both the cloud security group and UFW expose only the needed 8211/UDP.
• REST API 8212 and legacy RCON 25575 are not exposed to the public internet.
• You edited the real PalWorldSettings.ini under LinuxServer.
• The player password and admin password are different and do not appear in shell history or public files.
• Steam players can join via public IP; Xbox/PS5 needs have switched to community server mode.
• Built-in backups are enabled, and there is an off-machine backup.
• You have actually done a restore and entered the game to verify world data.
• The update process includes notification, backup, stop, update, start and log verification.

• Palworld Server Guide: running requirements
• Palworld Server Guide: deploying a dedicated server
• Palworld Server Guide: launch parameters
• Palworld Server Guide: configuration parameters
• Palworld Server Guide: REST API
• Pocketpair official Palworld Docker image and Compose example

Setting up a Palworld dedicated server on a VPS is not mainly about starting it successfully once, but about getting 16GB+ memory, 8211/UDP, the real configuration path, the cross-platform entry point, systemd supervision, two-layer backups and controllable updates right together. For a small private server, Ubuntu 24.04, SteamCMD and systemd are already enough; consider Pterodactyl for multiple instances or multi-person management, and teams with mature container standards can choose Pocketpair's official Docker image.

After going live, observe for a week at 8-16 players first, then scale up based on peak memory, single-core load, save growth and network quality. As long as the REST API is not exposed to the public internet, you back up before updating, and the restore process has actually been drilled, this server has the foundation for long-term operation.