Palworld dedicated server: every way to run one, compared

A Palworld dedicated server runs your world separately from your game client, so friends can play while your character is offline. The machine running that server still needs to stay on. Your next decision is where it should run and who will look after it: your gaming PC, a Linux machine, a container, a VPS, your homelab, or a managed rental. This guide compares those routes, checks the official requirements, and gives you the shared setup and maintenance checks before you commit your group’s world to one.

Decide whether a Palworld dedicated server solves your problem#

Choose a dedicated server when your group needs a world independent of one player’s game session. If 2–4 friends always play together and nobody minds hosting, ordinary co-op can still be enough. The fifth friend or the builder who logs in after everyone leaves changes that decision.

Pocketpair’s server introduction distinguishes the separate server program from co-op. Closing your game client does not close that separate program. Shutting down the machine that runs it does. That distinction matters most when you plan to run both on your everyday PC.

A 32-player configuration is a familiar baseline, but a player-limit setting does not establish performance. The world, simultaneous activity, available memory, and other processes on the machine all matter. Start with the people who will actually connect rather than planning around a maximum nobody needs.

Write down two requirements before shopping or installing: who must be able to join, and when the world must be available. Include storefronts, not just “PC,” because the Microsoft Store version follows the Xbox-family connection route. A server that works for your Steam account but excludes your friend’s version has not passed the first test.

Check the machine before choosing a route#

Use Pocketpair’s published requirements as your starting point, then leave room for your real workload. A successful launch on a small machine proves that the process can start; it does not prove a busy evening will finish without a crash.

These figures come from the official requirements page. It also warns that poor storage performance can cause save corruption. A spare drive that is already struggling under other services is a poor foundation for a persistent world.

For workload sizing, use the Palworld server RAM guide alongside the current official requirements. Treat any smaller suggested allocation as a workload-specific compromise that needs testing, not a replacement for Pocketpair’s guidance.

For a hands-on check of CPU, memory, storage and upload, use the Palworld PC requirements checklist before choosing a route.

There is no verified universal upload-speed figure in the requirements used here. Test with friends outside your network during normal household use. A local join does not test your internet connection, router, or provider’s inbound-access restrictions.

Compare six ways to run the same world#

Pick the route by the work you want to own. Steam, SteamCMD, and Docker describe how you install or package the server. VPS, homelab, and managed rental describe where it lives or who operates it. They overlap: a Linux VPS can run the official Docker image, and a homelab can run SteamCMD.

The Steam tool is a reasonable first attempt if you know Windows and have enough capacity. Use the Steam Dedicated Server tool walkthrough to find its library entry, locate the active installation, and plan updates. SteamCMD makes sense when you already administer Linux or want an installation without the graphical Steam client. Neither route costs a game-server software license.

Docker is useful for a repeatable deployment, but it does not supply a public address, RAM, or backups by itself. Start by reviewing Pocketpair’s official Docker repository. The official guidance discourages Docker Desktop on Windows and macOS because of storage performance concerns; a Linux container host avoids that particular route.

A VPS moves the machine out of your house while usually leaving administration with you. A homelab is appealing when you already maintain one, but adding another VM also adds competition for its resources. Neither is automatically cheaper once adequate memory and your time enter the comparison.

For the managed row, check Palworld hosting availability and the provider’s exact responsibilities. Game Hosting currently presents a waitlist; it is not a promise of immediate provisioning. Choose the row that meets your availability needs, then prove it with the group’s actual clients.

Plan the setup every route shares#

Every route must install the server, save a valid configuration, expose the game connection, and accept a real player. Use this as the acceptance checklist; the full Palworld installation guide covers the hands-on setup in more detail.

1. Install the server and launch it once

   In the Steam library, enable the Tools filter and find Palworld Dedicated Server. The alternative SteamCMD installation uses app ID 2394010, as documented in Pocketpair’s deployment instructions:

   steamcmd +login anonymous +app_update 2394010 validate +quit

   Run the installed server once so its saved-data directories are created, then stop it before configuring it. The executable is PalServer.exe on Windows; the Linux launcher is ./PalServer.sh. The installation directory depends on how you installed it.

2. Edit the active settings file

   Copy the shipped default configuration into the real configuration file, preserving its structure. Relative to the server installation, use the path for your operating system:

   Pal/Saved/Config/WindowsServer/PalWorldSettings.ini
   Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

   Set a recognizable server name and separate server and administrator passwords. Editing only DefaultPalWorldSettings.ini does not change the running world’s settings. Restart and check that the name and password behavior match your changes; see the official configuration reference.

   Before changing gameplay rates or base limits, use the plain-English server settings guide to separate your group’s preferences from defaults supplied by the installed version.

3. Make the listening port reachable

   The default game connection uses UDP 8211. A home server needs the appropriate firewall and router path; a VPS may have both an OS firewall and a provider firewall. A container also needs the intended UDP port exposed through its host.

   If you change ports, distinguish the listening port from the advertised external port. The launch-arguments reference uses -port=8211 for listening. PublicPort advertises the community server’s external port and does not change the listening socket. This checklist does not require opening UDP 27015: the official setup evidence used here establishes UDP 8211.

4. Verify an outside connection and a restart

   Have a friend outside your home network join the expected world. Then close your game client while they remain connected. Finally, restart the server normally and confirm that their progress remains. These checks distinguish a reachable, persistent server from a process that merely opened a console window.

If the local connection works and the outside one fails, inspect the network path before repeatedly reinstalling the game server. Reinstallation does not correct a router rule pointing at the wrong machine. Use the multiplayer symptom checklist to choose the next check when the failure could involve an account, a platform service, or the joining route.

Prove your console friends can join#

Xbox-family and PS5 players need the community-server route. That includes the Microsoft Store PC version within the Xbox family; “everyone on PC can just enter the IP” is too broad. Steam and Mac players can use the IP-and-port route described by the official server guide.

For a self-managed server, Pocketpair’s community-server instructions use these launch commands, run from the installation directory:

.\PalServer.exe -publiclobby

./PalServer.sh -publiclobby

The Steam tool also provides Open and start as a community server. A managed host should explain how to enable equivalent listing behavior through its controls.

The default platform list in the configuration reference allows these families:

CrossplayPlatforms=(Steam,Xbox,PS5,Mac)

Preserve it when configuring a mixed group. Community listing makes the server discoverable; your server password controls access to the world. Do not confuse listing it publicly with deciding to let strangers join without a password.

Have one friend from each storefront test the connection and check that their game version matches the server. If your own community server is unreachable from inside your house, Pocketpair notes that router hairpin NAT limitations can interfere with the public route. An outside player is a useful independent check.

The crossplay platform guide covers the broader pairings. Keep this test focused: the right server appears, each required platform connects, and all players reach the same world.

Keep the world recoverable after the first night#

A persistent world needs a recovery routine, not just a process that restarts. Decide who maintains it before the group invests weeks in the save. The work is similar whether the server lives in a tower under your desk or on rented Linux compute.

1. Protect the save before updates. Arrange a quiet maintenance window, use the save and shutdown admin commands to save and stop the server cleanly, then make a dated copy before changing binaries or configuration. Do not use a forced power cut as the normal shutdown procedure.
2. Keep configuration with the world. As an operational precaution, copy the complete directory below to separate storage. Use the save file location guide to identify the active world folder and distinguish its GUID from the public server name. For Docker, identify the persistent Saved mount; Pocketpair’s example uses ./Saved on the host. Confirm the files are really there before replacing a container.

Pal/Saved

3. Update to a compatible version. Coordinate client and server versions. For the official Docker image, follow its documented image-tag update process. Keep the pre-update copy until the group has joined and verified its progress.
4. Test startup after a host reboot. A Windows app you launch manually or a Linux process started in a terminal is not proof of automatic recovery. Configure startup for your chosen route, then test a planned reboot while nobody is playing.
5. Test a restore away from the live world. Confirm that the recovered copy contains the expected characters and bases. A backup filename alone does not prove recovery works.

Watch memory and player reports during normal sessions. Schedule restarts if your workload needs them, but do not present a daily restart as a cure for every crash. It cannot repair undersized memory, slow storage, or a save that was never backed up.

Recognize when self-hosting has become the wrong job#

Move away from self-hosting when maintaining availability takes more effort than you want to give it. A spare machine is a good solution if it already runs reliably and you enjoy the upkeep. It is less useful when every operating-system update, router change, or evening away becomes your group’s interruption.

Before changing routes, name the task you want someone else to own. “Keep the machine available when I travel” points toward remote infrastructure. “Handle updates and recovery assistance” points toward a managed service with those responsibilities explicitly included. Renting a bare VPS only solves the first part unless management is included.

Use the rent versus self-host comparison to weigh that change against home operating costs, platform access, and the work you would still keep.

Use the guide to renting a Palworld server to compare those responsibilities and the available plans. If you choose Game Hosting, the current Palworld product page leads to a waitlist. Check capacity and the final service terms when ordering becomes available.

Plan migration before cancelling the old setup. Preserve the complete source backup, follow the destination’s instructions, and verify characters, inventory, and bases with your friends. Moving an existing dedicated world and converting a co-op host’s save are different jobs; neither should be reduced to renaming a random file.

Your final check is simple: everyone can join, the world survives a restart, and someone knows how to restore it. Once those are true, the best route is the one your group can keep operating without making hosting another unpaid evening shift.