Palworld hit its full 1.0 release on July 10, 2026, and the itch to run a private server for a small friend group hasn’t faded. The problem most players hit isn’t the game, it’s the network. Home routers block inbound traffic by default, ISPs hand out CGNAT addresses that make port forwarding impossible, and opening UDP 8211 to the entire internet invites scanners within hours. This tutorial skips all of that. You’ll deploy the Palworld dedicated server on a cloud VPS, lock the firewall down completely, and use Tailscale to give only your friends a private path in. No router configuration, no dynamic DNS, no exposed ports.
By the end you’ll have a server running 24/7 on a $48-a-month box (or less), reachable only through your own Tailscale network, with automated backups and a systemd service that restarts itself after a crash or reboot. The whole build takes about 90 minutes if you’ve never touched a Linux VPS before, closer to 30 if you have.
This approach differs from the community-server route most Palworld players default to. A public listing gets your world discovered by strangers and exposes a raw UDP port to anyone who scans for it; a Tailscale-backed private server does neither. It also differs from paying a third-party game-hosting panel by the month — you own the box outright, keep the save files under your own account, and can resize or migrate the VPS whenever you want instead of being locked into a hosting company’s pricing tier. The tradeoff is that you’re the one running updates and backups, which is exactly what Steps 11 and 12 below automate away.
What You Need Before You Start
Palworld’s official dedicated server documentation lists 4 or more CPU cores as the floor, with 8 GB of RAM technically enough to boot but prone to crashes under load. Pocketpair recommends 16 GB for a stable small-group server and suggests 32 GB or more if you’re running a busier world with 10+ concurrent players and heavy building. An SSD is not optional in practice: guides that have tested spinning disks report noticeable stutter during autosaves and world streaming. Here’s the full checklist before you touch a terminal.
- A cloud VPS account — this guide uses DigitalOcean, but AWS Lightsail and Vultr work identically for these steps
- A Linux image: Ubuntu 24.04 LTS (used throughout this guide) or Ubuntu 22.04 LTS
- SSH client — OpenSSH on macOS/Linux, or PuTTY/Windows Terminal on Windows
- A free Tailscale account (Google, GitHub, or Microsoft sign-in)
- Palworld installed on each friend’s PC via Steam (the dedicated server itself does not require anyone to own the game to host it)
- Basic comfort with a command line — every command in this guide is copy-pasteable, but you should know how to open a terminal
- About 10 GB of free disk space on the VPS for the server files and future world saves
One thing worth clarifying up front: this setup is built for PC/Steam friends. Xbox and PS5 players can only join Palworld servers through the game’s official public “community server” listing, which requires REST API registration and a different network path than the private Tailscale tunnel this guide builds. If your group is Steam-only, skip ahead — everything below applies to you directly.
| Component | Version Used in This Guide | Notes |
|---|---|---|
| Operating System | Ubuntu 24.04 LTS | 22.04 LTS also works; avoid non-LTS releases for a server you want stable |
| Palworld | 1.0 (post-early-access, July 2026) | Server build must match client build or connections are refused |
| SteamCMD | Latest (auto-updates on each run) | Installed via the Ubuntu steamcmd package with the i386 architecture enabled |
| Tailscale client | Latest stable | Installed via the official install script; auto-updates unless disabled |
Why a Cloud VPS Beats a Home PC for This
Running Palworld on a spare gaming PC at home works, but it means that PC stays on around the clock, your world goes offline the moment you reboot for a driver update, and your home internet upload speed becomes the bottleneck for every player. A dedicated server running continuously on a home PC pulling 50 to 100 watts costs roughly $6 to $8 a month in electricity at typical US residential rates, which sounds cheap until you factor in wear, noise, and the fact that a Windows update can silently reboot the machine mid-session.
A cloud VPS flips those tradeoffs. You pay a flat monthly fee, the server runs on real Linux infrastructure with generous bandwidth caps built in, and reboots happen on your schedule, not Microsoft’s. It’s also the only practical option if your ISP uses CGNAT (common with cable and 5G home internet in 2026), since there’s no public IP to forward a port to in the first place.
How Tailscale’s Mesh Network Actually Works
It helps to understand what Tailscale is doing before you install it, since the whole “no port forwarding” claim can sound like marketing until you see the mechanism. Tailscale builds what’s called a mesh VPN using WireGuard as the underlying encrypted tunnel protocol. Instead of routing every device’s traffic through a central VPN server the way a traditional corporate VPN does, each device in your tailnet negotiates a direct, encrypted connection to every other device it needs to talk to. The Tailscale control plane’s only job is handing out stable 100.x.y.z addresses and helping devices discover each other’s real network location — it never sees your game traffic.
Most of the time, two devices behind different home routers can still establish a direct peer-to-peer connection using a NAT traversal technique (STUN-style hole punching), which keeps latency close to what you’d get from a raw internet connection. When that’s not possible — a particularly strict corporate firewall, for example — Tailscale falls back to relaying traffic through one of its own DERP (Designated Encrypted Relay for Packets) servers, which adds a bit of latency but keeps the connection working. You can check which mode you’re getting with tailscale ping, and it’s the first thing to check in the troubleshooting table below if one friend reports noticeably higher ping than everyone else.
The practical upshot for this build: your cloud VPS never needs a public-facing game port, because the “connection” your friends make isn’t really to the VPS’s public IP at all — it’s to a private tailnet address that only exists inside the encrypted mesh. A port scanner sweeping the internet for open UDP 8211 servers will never find yours, because as far as the public internet is concerned, that port isn’t open anywhere.
Step 1: Pick a VPS Sized for Palworld
Match the VPS spec to Pocketpair’s own guidance rather than guessing. For a friends-only server of 2 to 8 players, an 8 GB / 4 vCPU box is the sweet spot — enough headroom to avoid the “boots but crashes” territory of the bare 8 GB minimum, without paying for capacity you won’t use. If your group regularly runs 10+ players or heavy base-building, step up to 16 GB.
| Provider | Plan | vCPU / RAM | Storage | Monthly Price |
|---|---|---|---|---|
| DigitalOcean | Basic Droplet | 4 vCPU / 8 GB | 160 GB SSD | $48/mo |
| DigitalOcean | Basic Droplet | 8 vCPU / 16 GB | 320 GB SSD | $96/mo |
| AWS Lightsail | Standard instance | 4 vCPU / 16 GB | 320 GB SSD | $84/mo |
| Vultr | High Frequency | 4 vCPU / 8 GB | 256 GB NVMe | ~$48/mo |
These figures come straight from DigitalOcean’s Droplet pricing page and AWS Lightsail’s pricing page as published in September 2026. DigitalOcean and Vultr price by the hour with a monthly cap, so you can spin the box up, test everything in this guide, and destroy it for a few dollars if you decide cloud hosting isn’t for you. AWS Lightsail bundles a fixed amount of outbound transfer into its flat rate, which matters less here since Tailscale traffic between a handful of friends is tiny compared to running a public server.
Step 2: Provision the VPS and Connect Over SSH
Create the droplet (or instance) with Ubuntu 24.04 LTS, add your SSH public key during creation rather than a password, and note the assigned public IP. Then connect:
ssh root@YOUR_SERVER_IP
# Update packages immediately
apt update && apt upgrade -y
# Create a non-root user for daily operations
adduser palworld
usermod -aG sudo palworld
Log out and reconnect as the new user for everything from here on. Running the server as root is unnecessary risk for zero benefit — if the server process is ever compromised through a game exploit, you don’t want it running with full system privileges. Every command for the rest of this guide assumes you’re logged in as this new palworld user, prefixing anything that touches system configuration with sudo rather than running as root directly.
Step 3: Harden the Box Before Installing Anything
This step matters more than most tutorials admit. A freshly created VPS gets port-scanned within minutes of going live. Disable password authentication, restrict SSH to key-only login, and get the ufw firewall in place before you install a single game file.
# Install and enable ufw (Uncomplicated Firewall)
sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'ssh'
sudo ufw enable
# Harden SSH — edit /etc/ssh/sshd_config and set:
# PasswordAuthentication no
# PermitRootLogin no
sudo systemctl restart ssh
Notice there’s no rule for UDP 8211 yet. That’s intentional — you’re going to skip opening the Palworld port to the public internet entirely and route all game traffic over Tailscale instead, which is covered in Step 6. If you’re used to guides that tell you to forward or open a game port immediately, resist that instinct here: every port this server needs beyond SSH gets added later, scoped specifically to the Tailscale interface, not the public one.
Step 4: Install SteamCMD and Download the Palworld Server
Valve’s SteamCMD is the official command-line tool for downloading dedicated server files without a full Steam client or a game purchase. The Palworld Dedicated Server tool has its own Steam App ID, 2394010, and installs anonymously — you don’t need a Steam account tied to Palworld to host it.
# Enable the 32-bit architecture SteamCMD needs
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install lib32gcc-s1 steamcmd -y
# Download the Palworld dedicated server (anonymous login, no game purchase needed)
mkdir -p ~/palworld-server
/usr/games/steamcmd +force_install_dir ~/palworld-server
+login anonymous
+app_update 2394010 validate
+quit
Expect this to take 3 to 8 minutes depending on your VPS provider’s network speed — the download is a few gigabytes. When it finishes, you’ll see output ending in something like this:
Success! App '2394010' fully installed.
Step 5: Configure PalWorldSettings.ini for Your Group
The server ships with a default config template you need to copy and edit before first launch, following the structure documented in Pocketpair’s official server guide. This is where you set the server name, admin password, max players, and difficulty multipliers your friend group actually wants.
cd ~/palworld-server/Pal/Saved/Config/LinuxServer
cp DefaultPalWorldSettings.ini PalWorldSettings.ini
nano PalWorldSettings.ini
# Inside the OptionSettings= line, adjust at minimum:
# ServerName="Our Private Islands"
# AdminPassword="choose-a-strong-one"
# ServerPassword="choose-a-second-one-for-players"
# PublicPort=8211
# RCONEnabled=True
# RCONPort=25575
Enabling RCON is worth the extra two lines — it gives you a remote console for issuing admin commands (kicking a player, broadcasting a message, saving the world on demand) without needing to attach to the server’s terminal session directly.
Step 6: Skip Port Forwarding — Install Tailscale Instead
Tailscale builds a private mesh network (a “tailnet”) between devices using WireGuard, assigning each device a stable 100.x.y.z address that only devices on your tailnet can reach. As of its current pricing page, the free Personal plan covers up to 6 users and unlimited devices — enough for a normal friend group without paying anything. Install it on the VPS first:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# You'll get a URL to open in a browser to authenticate.
# Once approved, check your assigned tailnet IP:
tailscale ip -4
That command returns a stable address in the 100.64.0.0/10 range, for example 100.87.42.19. Write it down — this is the address your friends will use to connect to the game, instead of a public IP that could change or that you’d otherwise have to expose.
Step 7: Lock the Firewall to Tailscale-Only Traffic
With Tailscale running, explicitly allow game traffic only on the tailscale0 interface and deny it everywhere else. This is the step that actually delivers on “no port forwarding” — the Palworld port never opens to the public internet at all.
# Allow Palworld and RCON traffic ONLY over the tailscale0 interface
sudo ufw allow in on tailscale0 to any port 8211 proto udp
sudo ufw allow in on tailscale0 to any port 25575 proto tcp
# Explicitly deny the same ports on the public interface
sudo ufw deny 8211/udp
sudo ufw deny 25575/tcp
sudo ufw reload
sudo ufw status verbose
Run sudo ufw status verbose afterward and confirm the output shows 8211/udp DENY IN Anywhere alongside a separate ALLOW rule scoped to tailscale0. If both rules show ALLOW, you’ve left the port open to everyone and defeated the entire point of this setup — go back and re-check the interface name with ip a (it should be tailscale0 on a standard install).
Step 8: Invite Friends to Your Tailnet
Every player who wants to join needs to be on the same tailnet as the server. There are two ways to grant that, and which one you use depends on how much of your other traffic you want them to see.
- Invite them as full tailnet members — from the Tailscale admin console, invite by email. They install Tailscale on their own PC and sign in, and can then see and reach the server’s 100.x address directly. Simplest option for a small, trusted group, and stays within the free plan’s 6-user cap.
- Share just the server as a single device — Tailscale’s device sharing feature lets you share only the server machine with someone outside your tailnet, without giving them visibility into your other devices. Better if you’re hosting for people you don’t fully trust with network-level access to everything else you run.
Either way, each friend installs the Tailscale client (Windows, macOS, and Linux are all supported) and authenticates once. After that, the connection is silent and automatic — Tailscale runs as a background service and the tailnet IP just works the way a LAN address would.
Locking Down Access Further With Tailscale ACLs
Inviting someone to your tailnet by default gives them visibility into every device on it, which is fine for a tight friend group but overkill if you’re sharing access with a wider Discord community. Tailscale’s access control list (ACL) policy, edited as JSON in the admin console, lets you tag the server and write a rule that restricts a given user or group to reaching only that tag — nothing else on your network.
{
"tagOwners": {
"tag:palworld-server": ["autogroup:admin"]
},
"acls": [
{
"action": "accept",
"src": ["group:players"],
"dst": ["tag:palworld-server:8211", "tag:palworld-server:25575"]
},
{
"action": "accept",
"src": ["autogroup:admin"],
"dst": ["*:*"]
}
],
"groups": {
"group:players": ["friend1@example.com", "friend2@example.com"]
}
}
Apply the palworld-server tag to the VPS from the admin console or with tailscale up --advertise-tags=tag:palworld-server, and anyone in the players group can reach only the game and RCON ports on that one tagged machine — they can’t see or scan any of your other devices on the same tailnet. This is the setup worth reaching for the moment you’re hosting for more than a handful of people you know personally.
Step 9: Connect From Palworld
With the server running and Tailscale active on both ends, launch the dedicated server binary and have a friend connect directly by IP:
cd ~/palworld-server
./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
In Palworld, choose Join Multiplayer Game, select Connect via IP, and enter the server’s Tailscale address followed by the game port, for example 100.87.42.19:8211. If you’d rather not memorize an IP, Tailscale’s MagicDNS feature lets you assign the machine a name like palworld-server and connect using that hostname instead, which resolves automatically for everyone on the tailnet.
Step 10: Run It as a systemd Service
Launching the server manually in a terminal means it dies the moment you close the SSH session. A systemd unit keeps it running in the background, restarts it automatically if it crashes, and starts it on boot after a VPS reboot for maintenance.
sudo nano /etc/systemd/system/palworld.service
[Unit]
Description=Palworld Dedicated Server
After=network.target
[Service]
Type=simple
User=palworld
WorkingDirectory=/home/palworld/palworld-server
ExecStart=/home/palworld/palworld-server/PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable palworld
sudo systemctl start palworld
sudo systemctl status palworld
A healthy status check looks like this:
● palworld.service - Palworld Dedicated Server
Loaded: loaded (/etc/systemd/system/palworld.service; enabled)
Active: active (running) since Sat 2026-09-05 14:02:11 UTC; 3min ago
Main PID: 8842 (PalServer-Linux)
Step 11: Automate Backups With a Cron Job
World corruption from a bad update or an abrupt VPS restart is the single most common reason self-hosted Palworld groups lose progress. A daily save backup takes one cron entry and a few lines of shell script.
mkdir -p ~/palworld-backups
nano ~/backup-palworld.sh
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
tar -czf ~/palworld-backups/save-$TIMESTAMP.tar.gz
~/palworld-server/Pal/Saved/SaveGames
# Keep only the 14 most recent backups
ls -1t ~/palworld-backups/*.tar.gz | tail -n +15 | xargs -r rm --
chmod +x ~/backup-palworld.sh
crontab -e
# Add this line to run the backup daily at 4am:
0 4 * * * /home/palworld/backup-palworld.sh
Step 12: Update the Server Without Losing Your World
Palworld patches ship regularly, and clients that update will refuse to connect to a server running an older build. Update the server the same way you installed it, then restart the service — your save files live in a separate directory from the game binaries, so a SteamCMD update never touches them.
sudo systemctl stop palworld
/usr/games/steamcmd +force_install_dir ~/palworld-server
+login anonymous
+app_update 2394010 validate
+quit
sudo systemctl start palworld
Run your backup script manually right before any update, just in case a patch changes the save format in a way that isn’t backward compatible.
What This Actually Costs Per Month
The honest math, combining the VPS pricing above with the fact that both SteamCMD and Tailscale’s Personal plan are free:
| Setup | Server Software | Networking | Hosting | Total / Month |
|---|---|---|---|---|
| Cloud VPS (8GB/4vCPU) | Free (SteamCMD) | Free (Tailscale Personal) | $48 | $48 |
| Cloud VPS (16GB, headroom) | Free (SteamCMD) | Free (Tailscale Personal) | $84–96 | $84–96 |
| Home PC, always-on | Free (SteamCMD) | Free (Tailscale Personal) | ~$6–8 electricity | ~$6–8 |
A home PC is cheaper in raw dollars if electricity is all you’re counting, but it assumes a machine that’s already sitting idle, tolerates being on 24/7, and survives Windows update reboots without anyone noticing the world went down for ten minutes. For a group that wants the server simply working whenever anyone logs on, the $48-a-month VPS tier is the more predictable choice.
There’s a middle path worth mentioning too: several VPS providers, including DigitalOcean and Vultr, bill by the hour rather than committing you to a full month upfront. If your group only plays on weekends, you can script the VPS to power on Friday evening and destroy or snapshot-and-stop it Sunday night, cutting the effective monthly cost by more than half compared to the always-on figures in the table above. The tradeoff is a few extra minutes of setup each session while SteamCMD or the boot process catches up, and you lose the “just log on whenever” convenience that makes an always-on server worth it for a lot of groups in the first place.
5 Common Pitfalls When Self-Hosting Palworld in the Cloud
- Undersizing the VPS. An 8 GB box technically boots the server per Pocketpair’s own minimum, but it’s the same spec flagged as crash-prone. Budget for 8 GB as a floor for a small group, not a target.
- Forgetting the explicit UFW deny rule. Allowing the port on
tailscale0without also denying it on the public interface leaves both rules active — ufw processes rules in order, and a stray earlier ALLOW can leave the port reachable from the internet regardless of the Tailscale-scoped rule. - Expecting console friends to just work. Xbox and PS5 players cannot install Tailscale and cannot join over this private tunnel. If your group is cross-platform, you need Palworld’s official community-server registration path instead, which is a different setup than this guide.
- Running the server in a raw terminal session. Without the systemd unit from Step 10, closing your SSH connection kills the server. This is the single most common “why did the server randomly go down” complaint in Palworld hosting communities.
- Skipping backups until after a bad patch. Save corruption after a Palworld update is common enough that Step 11 isn’t optional polish — it’s the difference between losing a day of progress and losing nothing.
- Inviting the whole friend group as full tailnet members by default. It works, but it also means every player can see and potentially reach any other device you have on that tailnet. For anything beyond a handful of people you trust completely, use the ACL and tagging approach covered further down instead of a blanket invite.
Troubleshooting: 8 Problems and Fixes
| Symptom | Likely Cause | Fix |
|---|---|---|
| Friend can’t connect via Tailscale IP | They aren’t authenticated on the tailnet yet | Re-send the invite; confirm tailscale status shows their device as active |
| Server crashes shortly after launch | RAM below the 8 GB floor | Resize the VPS to at least 8 GB, ideally 16 GB |
| “App update failed” during SteamCMD install | Disk space exhausted or i386 libs missing | Check df -h; reinstall lib32gcc-s1 |
| ufw shows the port ALLOW on all interfaces | Deny rule added before allow rule, or wrong interface name | Run ip a to confirm tailscale0, re-add rules in the order shown in Step 7 |
| Server doesn’t restart after VPS reboot | systemd service not enabled | Run sudo systemctl enable palworld |
| World save appears corrupted after an update | Patch changed the save format | Restore the most recent file from ~/palworld-backups |
| High latency for one player only | Tailscale fell back to DERP relay instead of a direct connection | Run tailscale ping on their device to confirm relay vs. direct; usually resolves once both ends have any UDP path open |
| RCON commands don’t respond | RCONEnabled left False in the ini, or RCON port not allowed on tailscale0 | Recheck PalWorldSettings.ini and the ufw rule for port 25575 |
When a symptom isn’t covered above, the server’s own logs are the next stop. Palworld writes runtime logs under ~/palworld-server/Pal/Saved/Logs, and journalctl -u palworld -n 100 --no-pager shows the last 100 lines of whatever systemd captured from the process, including the exact error that caused a crash rather than just the fact that one happened. Pair that with tailscale status to rule out a networking issue before assuming the problem is the game server itself — the two most common root causes (undersized RAM and a tailnet authentication that silently expired) show up clearly in one or the other.
Advanced Tips: Mods, Multiple Worlds, and Scaling Up
Once the base setup is stable, a few upgrades are worth considering. Running two independent worlds on the same VPS is possible by installing the server twice into separate directories, each with its own PublicPort and a matching pair of systemd units and ufw rules — useful if two friend groups want separate saves without paying for two boxes, as long as the underlying VPS has enough spare RAM and CPU headroom to run both without either one starving the other during peak play. Mod support on Linux dedicated servers is more limited than on Windows, so check a mod’s compatibility notes before assuming it will load on this setup; UE4SS-based mods in particular tend to be the most reliable on Linux, while mods that hook directly into the Windows-only Unreal Engine editor toolchain generally won’t work on a Linux dedicated server at all. When in doubt, test a mod on a throwaway VPS snapshot before rolling it out to the server your friend group actually plays on, so a bad mod update doesn’t take down the main world.
If your group grows past what the free Tailscale Personal plan covers, the Standard tier adds unlimited users at $8 per user per month — cheap insurance if you’re hosting for a Discord community rather than a fixed group of six.
Catching Crashes Before Your Friends Do
Systemd’s Restart=on-failure directive handles most crashes silently, but it’s worth knowing when that’s happening rather than discovering it because a friend messaged “server’s down again.” A small watchdog script checked every five minutes via cron covers this without needing any paid monitoring tool.
nano ~/check-palworld.sh
#!/bin/bash
if ! systemctl is-active --quiet palworld; then
curl -s -X POST -H 'Content-Type: application/json'
-d '{"content":"⚠ Palworld server is down on the VPS — check systemctl status palworld"}'
"$DISCORD_WEBHOOK_URL"
fi
chmod +x ~/check-palworld.sh
crontab -e
# Check every 5 minutes
*/5 * * * * DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..." /home/palworld/check-palworld.sh
Swap the Discord webhook URL for a Slack incoming webhook or a plain email via mail if that fits your group’s habits better — the logic is identical, only the notification transport changes. This closes the loop on the “is the server down?” question days before anyone has to ask it in chat.
The Complete Project: What You’ve Actually Built
Working through all 12 steps leaves you with a small but complete piece of infrastructure, not just a game running in a terminal window. It’s worth listing out everything that’s now in place, since each piece maps directly back to one of the pitfalls or troubleshooting items above.
- A cloud VPS sized to Pocketpair’s own recommended spec, not just the bare minimum
- A non-root
palworlduser with key-only SSH access - A ufw firewall that denies every game port on the public interface and allows it only over
tailscale0 - The Palworld dedicated server installed via SteamCMD under App ID 2394010, with RCON enabled
- A private Tailscale tailnet connecting the server to your friend group, optionally scoped with ACL tags
- A systemd unit (
palworld.service) that keeps the server running through crashes and reboots - A cron job producing rolling nightly backups of your save files
- A repeatable update procedure that never touches your saves
- An optional watchdog script that pings a Discord or Slack webhook the moment the service goes down
None of these pieces are Palworld-specific in isolation — the same VPS, the same Tailscale tailnet, and the same systemd-and-cron pattern work for hosting Valheim, a private Minecraft server, or any other self-hosted multiplayer game that listens on a UDP or TCP port. Palworld just happens to be the one drawing the most search traffic in 2026, thanks to its full 1.0 launch reviving interest from players who bounced off the early-access build.
Frequently Asked Questions
Do I need to buy Palworld to run the dedicated server?
No. The Palworld Dedicated Server tool (Steam App ID 2394010) installs anonymously through SteamCMD and doesn’t require a Palworld purchase or a Steam account tied to the game. You only need Palworld itself installed on the devices that will actually play.
Can Xbox or PlayStation 5 players join a Tailscale-based private server?
Not through this setup. Consoles can’t install the Tailscale client, so cross-play friends need to join through Palworld’s official public community-server listing instead, which uses a different connection path than the private tunnel this guide builds.
Is Tailscale actually free for a group of friends?
Yes, for small groups. Tailscale’s Personal plan is free indefinitely and covers up to 6 users with unlimited devices per user, which comfortably covers most private Palworld friend groups. Larger communities would need the paid Standard tier at $8 per user per month.
How much RAM does a Palworld dedicated server actually need?
8 GB will boot the server but is prone to crashes under any real load. 16 GB is the recommended baseline for a stable small-group server, and 32 GB or more is worth budgeting if you expect 10 or more concurrent players with heavy base-building.
Why not just forward port 8211 on my router instead of using Tailscale?
You can, if your ISP gives you a public IP and you’re comfortable exposing a UDP port to the entire internet. Many home ISPs in 2026 use CGNAT, which makes port forwarding impossible regardless of router settings. Tailscale sidesteps that limitation entirely and keeps the port closed to anyone outside your tailnet.
What happens to my world save when I update the server?
Nothing, as long as you follow Step 12. Save files live in a separate SaveGames directory from the server binaries, so a SteamCMD update overwrites only the game files. Still, back up manually right before any update in case a patch changes the save format.
Can I run this on the cheapest possible VPS to save money?
You can try, but anything below the 8 GB / 4 vCPU tier risks the same instability flagged in Pocketpair’s own minimum-spec warning. The $48-a-month tier from providers like DigitalOcean or Vultr is the realistic floor for a server that stays up reliably.
Does RCON let me kick players or change settings without restarting the server?
Yes. Once RCONEnabled is set to True in PalWorldSettings.ini and port 25575 is allowed on the tailscale0 interface, you can connect with any RCON client to issue admin commands like broadcasting messages, saving the world, or kicking a disruptive player, all without touching the server process itself.
Does the VPS need a static public IP for this to keep working?
Not really, and that’s one of the underrated benefits of this approach. Because friends connect over the Tailscale tailnet address rather than the VPS’s public IP, the server keeps working even if the provider’s public IP changes on reboot. What matters is that the VPS stays authenticated to the same tailnet, which it will as long as you don’t reinstall the operating system from scratch.
Can this same setup host a different game instead of Palworld?
Yes. Everything except Steps 4 and 5 — installing the Palworld binaries and editing PalWorldSettings.ini — is generic: the VPS sizing logic, the ufw-plus-Tailscale firewall pattern, the systemd unit, and the backup cron job all transfer directly to Valheim, a private Minecraft server, or any other self-hosted game server that listens on a fixed UDP or TCP port.