Palworld Dedicated Server Setup on a Linux VPS

Palworld is more fun when the world doesn't vanish the moment somebody closes their laptop. That's the whole point of running your own server: a persistent map that stays up around the clock, survives reboots, and lets friends log in whenever they have an hour free instead of coordinating everyone's schedule around one host's game client. Palworld server hosting on a Linux VPS is the most reliable way to get there, and it costs a fraction of what most people expect once you know which steps actually matter.

This guide covers the full path from an empty VPS to a running, auto-restarting Palworld dedicated server: picking the right specs, installing the server binaries with SteamCMD, editing the configuration file that actually takes effect, opening the correct ports, wrapping the process in systemd, setting up remote administration, and backing up the saves you'll eventually be glad you kept. Everything here is written for Ubuntu 22.04/24.04 LTS, though the commands translate cleanly to Debian and other Debian-derived distributions.

What Is a Palworld Dedicated Server?

Palworld actually gives you three distinct ways to play with other people, and it's worth knowing the difference before you commit an evening to setup. The simplest is invite-based co-op: one player hosts directly from their game client, up to three friends join, and the world only exists while that host stays logged in. Close the game, and everyone gets disconnected.

A dedicated server is a different animal entirely. It's a standalone process — PalServer.sh on Linux — that runs independently of any player's game client, typically on a rented Linux VPS. Nobody needs to "be the host" because the host is a machine, not a person. The third option is managed game panel hosting, where a provider runs that same process for you behind a control panel, trading some flexibility for convenience.

A few terms come up constantly in this guide, so a quick glossary helps. A VPS (virtual private server) is a slice of a physical machine with its own operating system, root access, and public IP address. SteamCMD is Valve's command-line tool for downloading Steam-distributed game server files without needing a graphical Steam client. PalWorldSettings.ini is the file that controls almost everything about how your world behaves. systemd is the Linux service manager that keeps your server running and restarts it automatically if it crashes. And RCON and the REST API are two different ways to send admin commands to a running server without being logged into the game yourself.

Before You Start: Requirements and Preparation

Have these ready before opening a terminal:

• A Linux VPS running Ubuntu 22.04/24.04 LTS or a Debian-based distribution, with root or sudo SSH access
• A public IP address, which most VPS plans include by default
• Basic comfort with the command line — copy-paste is enough
• A firewall you can configure; this guide uses ufw throughout
• The Palworld client installed on at least one machine, for testing the connection once the server is live

Sizing the VPS correctly upfront saves a painful mid-project resize. Palworld leans harder on RAM and single-thread CPU performance than on raw core count, and that appetite grew with the July 2026 1.0 release, which added the World Tree region and roughly doubled the explorable map. Pocketpair now recommends at least 16GB of RAM even for a lightly populated server, because memory use climbs steadily as bases, captured Pals, and world objects accumulate over weeks of play.

A cloud VPS from a provider such as Serverspace is a practical fit here: you pick the CPU and RAM tier that matches your player count, get a dedicated public IP without extra configuration, and can resize the instance later if the community outgrows the original plan.

Cloud Servers from €4 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channeltry

How to Set Up a Palworld Dedicated Server on Linux: Step by Step

The steps below build the server from a bare VPS to a fully managed, auto-restarting process. None of them are individually difficult; the trick is doing them in order and not skipping the ones that feel optional.

Step 1: Provision and Prepare the VPS

Connect over SSH as root or your sudo user, then update the system before installing anything else.

Running a game server as root is a bad habit that costs nothing to avoid. Create a dedicated, unprivileged user and do everything else under that account.

Step 2: Install SteamCMD Dependencies

SteamCMD and the Palworld server binaries need the 32-bit runtime libraries, even on a 64-bit system. Enable the i386 architecture first.

Step 3: Download SteamCMD

Do this as the palworld user, not root, so file ownership stays sane from the start.

Step 4: Install the Palworld Dedicated Server Files

The dedicated server is a separate SteamCMD app with its own ID, 2394010, and it downloads through an anonymous login. Nobody needs to own Palworld to host it — only the players connecting to it need the game itself.

This pulls a few gigabytes of data, so expect the download to take anywhere from a few minutes to twenty or more depending on your connection. Let it finish; interrupting a validate pass partway through tends to leave corrupted files behind.

Step 5: Edit PalWorldSettings.ini

This is where nearly everyone trips up on their first attempt. The active configuration file lives at Pal/Saved/Config/LinuxServer/PalWorldSettings.ini inside your install directory, and it starts out completely empty. Sitting next to it is DefaultPalWorldSettings.ini, a template file — editing that one does nothing at runtime. Copy its structure into the real PalWorldSettings.ini and edit the values there. Always stop the server first; it overwrites the file with whatever is currently loaded in memory on shutdown, which will erase changes you made while it was running.

At minimum, set these lines:

The last line matters more than it looks: 1.0 supports full crossplay across Steam, Xbox, PlayStation 5, and Mac on dedicated servers, but only if that parameter is active. Beyond these essentials, the file has dozens of tunable parameters. Start small, test with a couple of players, and adjust from there rather than rebalancing everything at once.

Step 6: Open the Required Ports

Get this wrong and players simply won't be able to connect, even though the server logs will look perfectly healthy. The single most common cause of an "invisible" Palworld server is forwarding TCP where UDP was needed.

Step 7: Add Performance Launch Flags

Palworld's core simulation still leans heavily on a single thread, so a handful of launch flags help the engine spread work across the CPU more effectively.

Step 8: Wrap the Server in a systemd Service

A screen or tmux session is fine for a quick test, but a real server deserves a proper service: automatic start on boot, clean recovery after a crash or an out-of-memory kill, and a single command to check status. Create /etc/systemd/system/palworld.service and fill in the following sections.

Under [Unit], set:

Under [Service], set:

Under [Install], set:

Then load and start it:

Step 9: Test the Connection

From the Palworld client, choose Join Multiplayer Game and enter your VPS's public IP address with port 8211. A first connection typically takes a little longer than usual while the client downloads the world's mod and settings metadata — give it a minute before assuming something is wrong.

Step 10: Set Up Remote Administration and Learn Key Palworld Server Commands

Running commands from inside the game chat works, but it means someone has to be logged in to moderate. RCON solves that by exposing a remote console over TCP, authenticated with the same AdminPassword already set in the config file.

Pocketpair has flagged RCON as deprecated in favor of a newer HTTP REST API, though it still works today. Worth treating it as a bridge rather than a permanent solution — new admin tooling should target the REST API on port 8212 instead, authenticated with HTTP Basic auth using the username admin and the same AdminPassword.

Every dedicated server admin ends up leaning on the same handful of Palworld server commands. ShowPlayers lists everyone currently connected along with their Steam ID, which nearly every other moderation command needs as an argument. Save writes the world state immediately, which is worth running before anything risky. Broadcast sends a message to every player on screen. Shutdown takes a delay in seconds plus a message, giving people warning before the process stops. KickPlayer and BanPlayer, each followed by a Steam ID pulled from ShowPlayers, handle the disciplinary side.

Step 11: Automate Backups

Save corruption is a documented, recurring issue in Palworld, and it isn't optional to protect against. World data lives under Pal/Saved/SaveGames. A simple daily cron job covers the basics.

Copy those archives somewhere other than the same disk — an object storage bucket, a second VPS, anywhere that survives if the primary machine doesn't. And actually test a restore occasionally; a backup nobody has ever restored is really just an assumption.

Step 12: Keep the Server Updated

Palworld ships patches often, and a version mismatch between server and client blocks every connection until they match again. Stop the service, rerun the same install command with the validate flag, then restart.

One more thing worth flagging: the July 2026 1.0 release brought reports of native server clustering, letting multiple linked server instances share one connected community and, by some accounts, work around the historical 32-player ceiling. At the time of writing, the detailed configuration steps for clustering were still being finalized and documented, so treat specific port or setup instructions you find elsewhere with some caution, and check Pocketpair's own patch notes before planning a community around it.

Pros and Cons of Self-Hosting a Palworld Server on a VPS

There's no single best Palworld server host for every situation — it depends on how hands-on you want to be, and how much you value full control over convenience.

A self-managed VPS sits in a comfortable middle ground: it costs less than a managed panel over time, gives root access to tune everything from launch flags to firewall rules, and doesn't ask anyone to keep a personal gaming PC running around the clock. The trade-off is that updates, security, and backups become your responsibility rather than someone else's. For a group that already has one person comfortable with a terminal, that trade is usually an easy one to make.

Limitations and Risks to Keep in Mind

Palworld's server process still leans on single-thread CPU performance more than raw core count, so a budget VPS with many weak cores can bottleneck well before RAM runs out — checking clock speed matters as much as checking the core count on a spec sheet.

Save corruption is a known, recurring problem across the community, not a rare edge case. Sudden power loss, a disk running out of space, or killing the process instead of stopping it cleanly can all damage the SaveGames folder. Backups reduce the damage; they don't prevent it outright, so stopping the server gracefully before any risky change is worth the extra ten seconds.

Because RCON is officially deprecated, building new automation against it is a bit like building on borrowed time — Pocketpair could tighten or remove it in a future patch. The REST API is the safer long-term bet for anything you plan to maintain. Either way, never expose port 8212 or port 25575 to the open internet; both hand full administrative control to anyone who reaches them with your admin password.

A dedicated server on a public IP is also a visible target on the network, simply by existing. Firewalling every port except 8211 and SSH, keeping the OS patched, and disabling password-based SSH login in favor of keys all cost little and close off a lot of exposure.

Practical Scenarios: How Different Communities Run Palworld Servers

A Weekend Server for a Small Friend Group

Four friends who play a few evenings a week don't need much: the smallest VPS tier from the sizing table above, default drop rates, and a systemd service so nobody has to remember to start anything. Backups matter just as much here as on a busy server — a small world still represents real hours invested.

Growing a Public Community Server

Public listing brings unpredictable player counts, and a server that felt roomy at ten people can strain at twenty-five. Plan to resize the VPS upward before it becomes a problem rather than after, and lean on RCON or the REST API for moderation once you can't watch chat constantly.

A Semi-Hardcore PvP World

Tighter loot, a harsher death penalty, and active moderation go together here. Disputes between players happen fast in PvP, and having ShowPlayers, KickPlayer, and BanPlayer available through RCON — without needing to be logged into the game — makes the difference between a quick resolution and a chat argument that spirals.

A Content Creator's Always-On Server

Streamers hosting for a community need uptime above almost everything else, since a crash mid-stream is visible to an audience in real time. Automated restarts through systemd, frequent backups, and headroom above the minimum RAM tier all pay for themselves here.

Migrating a Solo or Co-op Save to a Dedicated Server

Moving an existing world onto a new dedicated server is possible, but it's worth knowing the limits going in: you can transfer world data, but not player-specific save data tied to an individual's local profile. Plan on players re-entering the world as if joining fresh, even though the map, bases, and structures already exist.

Common Mistakes When Setting Up a Palworld Dedicated Server

• Opening TCP instead of UDP on port 8211, so the server starts cleanly and looks healthy in the logs while remaining completely unjoinable
• Editing DefaultPalWorldSettings.ini instead of the real PalWorldSettings.ini, so none of the intended changes actually apply
• Running the server process as root, turning any future exploit into full system compromise
• Exposing the RCON or REST API port to the entire internet instead of restricting it to trusted IPs
• Putting off backups until after the first corrupted save, rather than before
• Under-provisioning RAM for the intended player count, then blaming "lag" for what's really a memory bottleneck
• Forgetting to update the server binaries right after a client patch ships, which locks out every player with a version mismatch error

Conclusion

There's rarely a single answer to what counts as the best Palworld server hosting for every group, but a Linux VPS sized correctly for your player count covers most cases well. None of the individual steps in a Palworld dedicated server setup are hard — installing SteamCMD, editing one config file, opening a couple of ports, and wrapping the process in systemd is maybe thirty minutes of actual work once you've done it once. What trips people up is skipping a step because it seemed optional, and the port protocol and the Default-versus-real config file are the two that cause the most support requests. Get those right, add a backup cron job, and you have a world that outlasts any single player's schedule. If you're still deciding on infrastructure, a Linux VPS sized to your expected player count — Serverspace's VPS lineup among the reasonable options — gives you the root access this whole guide assumes, without needing to leave a personal machine running.

Часто задаваемые вопросы (FAQ)