Why Rent a Palworld Server Instead of Hosting It Yourself?

Par Benjamin D. · PDG

August 24, 2026 · Mis à jour le August 24, 2026 · Lecture 10 min

Contents

Palworld server hosting comes down to a simple trade-off: run the dedicated server on your own machine, or rent one built for the job. Both work. Only one of them keeps running when you close your laptop, and only one survives a 32-player raid on a base with 400 structures. Here's the technical breakdown.

What a Palworld dedicated server actually demands

Before comparing rental and self-hosting, you need an honest picture of the workload. Palworld's dedicated server binary (PalServer.exe on Windows, PalServer.sh on Linux via SteamCMD) is not a lightweight process. It runs an Unreal Engine 5 simulation, and it is heavily single-thread bound.

CPU: frequency over core count

The main game loop — Pal AI, base worker pathfinding, structure ticks, breeding cycles — largely lands on one thread. Adding 16 cores does nothing if each core runs at 2.4 GHz. This is why high-frequency Ryzen chips matter far more than raw core count for this title. A server that stutters at 20 players usually isn't out of RAM; it's saturating one core.

The classic killer is base sprawl. Every player guild can place multiple bases, each with Pals working conveyor-style production loops. Twenty guilds × three bases × 15 working Pals means several hundred AI agents ticking simultaneously. That's the real load profile, not player count.

RAM: the number everyone underestimates

Palworld's memory footprint grows with world size and save age. Rough field figures:

Scenario	Realistic RAM	Notes
4–8 players, fresh world	8 GB	Comfortable for a private group
10–16 players, a few weeks old	12–16 GB	Base count starts to bite
20–32 players, mature save	16–32 GB	Expect leak-driven growth over uptime

Palworld has a known tendency to creep in memory usage over long uptimes. A scheduled restart every 6 to 12 hours is standard practice, not a workaround for bad hosting.

Storage and I/O

Saves are written periodically to Pal/Saved/SaveGames/. On a mature world the save directory can reach several hundred megabytes, and each autosave is a burst of write activity. On a mechanical drive or an oversubscribed shared disk, that burst translates directly into a visible hitch for every connected player. NVMe storage removes that class of problem entirely.

Network

Palworld uses UDP on port 8211 by default, plus 27015 for Steam query if you want the server listed. Traffic per player is modest, but latency consistency matters more than bandwidth: Pal combat and capture throws feel awful above ~90 ms of jitter-heavy ping.

Self-hosting Palworld: what it really costs you

Self-hosting is legitimate. Plenty of admins run solid servers from a spare desktop or a home rack. But you should go in knowing the full bill — and it's rarely just electricity.

The home machine route

On Windows, installation via SteamCMD is straightforward:

steamcmd +login anonymous +app_update 2394010 validate +quit

On Linux (Debian/Ubuntu), you need the 32-bit libraries and a non-root user:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd lib32gcc-s1 xdg-user-dirs
sudo adduser --disabled-password --gecos "" palworld
sudo -u palworld /usr/games/steamcmd +force_install_dir /home/palworld/server \
  +login anonymous +app_update 2394010 validate +quit

Then a systemd unit so it survives reboots:

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

[Service]
Type=simple
User=palworld
WorkingDirectory=/home/palworld/server
ExecStart=/home/palworld/server/PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now palworld
sudo journalctl -u palworld -f

That part is the easy 20%. The other 80% is everything below.

Port forwarding, CGNAT and your public IP

You need to forward UDP 8211 (and 27015 if you want Steam listing) from your router to the host machine. If your ISP puts you behind CGNAT — increasingly common on fibre and 4G/5G connections — you simply cannot open an inbound port. No amount of router configuration fixes that. Your only options become a tunnel service, an IPv6-only setup that half your players can't reach, or renting a machine.

Even with a clean public IP, most residential connections use dynamic addressing. Your IP changes, your players' saved server entry breaks, and you're posting a new address in Discord at 2 a.m.

Upload bandwidth is the hidden ceiling

Residential connections are asymmetric. A 500/50 Mbps line sounds generous until you realise the server pushes state to every client on that 50 Mbps upstream — while someone in the house is uploading a video. Palworld isn't bandwidth hungry, but contention creates jitter, and jitter is what players actually feel.

Exposure and attack surface

Opening a port on your home router exposes your home IP address to everyone who joins. In game communities, that occasionally invites trouble: a disgruntled player, a booter service, and your entire household loses internet for the evening. Consumer ISPs offer no volumetric DDoS mitigation. This is the single strongest argument against home hosting for any public community server.

Uptime, power and noise

A dedicated server running 24/7 means a machine you can't shut down, can't reboot for Windows updates during peak hours, and that adds heat and fan noise to a room. Add a power cut with no UPS and you get a save file written mid-flush — the classic cause of "my base disappeared" reports.

Palworld server hosting as a rental: what changes technically

Renting isn't about convenience alone. It changes the hardware profile, the network path and the operational model. Here's the concrete comparison, on neutral criteria only.

Criterion	Home self-hosting	Rented game server
CPU profile	Whatever's in the box, shared with your OS and browser	High-frequency Ryzen, sized for single-thread game loops
Storage	Often SATA SSD or HDD	NVMe SSD, low write latency for autosaves
Network	Residential asymmetric line, shared with household	Datacentre uplink, symmetric, low jitter
DDoS protection	None	Anti-DDoS filtering at infrastructure level
IP address	Your home IP, often dynamic	Fixed public IP, unrelated to you personally
Backups	Manual scripts you must write and test	Automated snapshots of the save directory
Management	SSH / RDP / raw file edits	Web panel: console, files, restarts, sub-users
Uptime	Depends on your power and ISP	Redundant datacentre power and connectivity

The panel is the real productivity gain

With a Pterodactyl panel, the day-to-day admin work collapses into a browser tab. Live console with server output, direct editing of PalWorldSettings.ini, scheduled restarts, one-click reinstall after a broken update, and file manager access to the save folder. No SSH client, no SFTP juggling, no "which user owns this file" permission errors.

The sub-user system is what community managers care about. You can hand a co-admin console and restart rights without giving them billing access or the ability to delete the server. Try replicating that cleanly on a home box.

Anti-DDoS is not optional for a public server

The moment your server IP is public and your community grows past your friend group, someone will eventually test it. Volumetric attack mitigation has to happen upstream, at the network edge — it cannot be solved by a firewall on the server itself. On Serveur Palworld instances at Fly-Serv, that filtering is included by default rather than sold as an add-on.

Instant deployment and version churn

Palworld ships updates frequently, and each patch can break mods or require a server-side rebuild. Redeploying a clean install from a panel takes a minute. Doing it by hand means re-running SteamCMD, re-checking file ownership, restoring configs, and hoping you backed up the right folder.

Configuring and tuning your Palworld server properly

Whichever route you pick, the configuration file is where server feel is decided. The reference is Pal/Saved/Config/LinuxServer/PalWorldSettings.ini (or WindowsServer). Never edit DefaultPalWorldSettings.ini — it gets overwritten on update.

Settings that matter for performance

[/Script/Pal.PalGameWorldSettings]
OptionSettings=(
  ServerName="My Palworld Server",
  ServerPassword="",
  AdminPassword="use-a-long-random-string",
  ServerPlayerMaxNum=32,
  PublicPort=8211,
  RCONEnabled=True,
  RCONPort=25575,
  BaseCampMaxNumInGuild=3,
  BaseCampWorkerMaxNum=15,
  GuildPlayerMaxNum=20,
  DropItemMaxNum=3000,
  bIsUseBackupSaveData=True,
  AutoSaveSpan=180.000000,
  bEnableInvaderEnemy=True
)

Three of these are performance levers people ignore:

BaseCampMaxNumInGuild — dropping from 4 to 2 or 3 dramatically reduces AI tick load on a busy server. This is the single most effective knob.
BaseCampWorkerMaxNum — fewer working Pals per base means fewer pathfinding calculations per frame.
DropItemMaxNum — dropped loot persists in the world. On a PvP-heavy server this accumulates fast and every item is a tracked actor.

Set AutoSaveSpan sensibly: too frequent and you get regular I/O hitches, too rare and a crash costs players 15 minutes of progress. 180 seconds is a reasonable middle ground on NVMe storage. Full option documentation is maintained by the developer on the official Palworld tech site.

Launch flags

The commonly used flags are worth understanding rather than copy-pasting blindly:

./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS -port=8211 -players=32

These push Unreal to distribute more work across threads. They help on servers with headroom, but they don't create single-thread performance out of nothing. If your main thread is already saturated, the fix is fewer bases, not more flags.

RCON for automation

Enable RCON and you can script announcements, saves and clean shutdowns:

# Announce, save, then shut down with a 60s countdown
rcon -a 127.0.0.1:25575 -p "$ADMIN_PASSWORD" "Broadcast Restart_in_60_seconds"
rcon -a 127.0.0.1:25575 -p "$ADMIN_PASSWORD" "Save"
rcon -a 127.0.0.1:25575 -p "$ADMIN_PASSWORD" "Shutdown 60 Scheduled_restart"

Note that Palworld's broadcast command doesn't accept spaces — use underscores. On a panel, the same thing is achieved with a scheduled task calling console commands, no cron file required.

Backups: the non-negotiable

Palworld saves have historically been fragile. Corrupted guild data, vanished player characters after a mid-write crash — it happens. Automated, versioned backups of the save directory are what separate an annoying evening from a dead community.

Manual approach on a VPS:

#!/bin/bash
SRC="/home/palworld/server/Pal/Saved/SaveGames"
DST="/home/palworld/backups"
STAMP=$(date +%Y%m%d-%H%M)
mkdir -p "$DST"
tar -czf "$DST/pal-$STAMP.tar.gz" -C "$SRC" .
find "$DST" -name "pal-*.tar.gz" -mtime +7 -delete

chmod +x /home/palworld/backup.sh
crontab -u palworld -e
# 0 */6 * * * /home/palworld/backup.sh

On a managed game server, automatic backups cover this without you writing or testing a line of shell. The important discipline in both cases: test a restore before you need one.

Hardening, whichever route you take

Use a long random AdminPassword and a separate RCON password. Never reuse your Discord or Steam password.
Bind RCON to localhost where possible; if it must be remote, restrict it by IP.
On a VPS: SSH keys only, root login disabled, plus ufw and fail2ban.

ssh-keygen -t ed25519 -C "palworld-admin"
ssh-copy-id -i ~/.ssh/id_ed25519.pub palworld@YOUR_SERVER_IP

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 8211/udp
sudo ufw allow 27015/udp
sudo ufw enable
sudo apt install -y fail2ban && sudo systemctl enable --now fail2ban

Volumetric DDoS filtering sits upstream at the infrastructure level, so your job on the machine is limited to access control and keeping packages current.

The middle path: VPS

If you want root access, custom mod loaders, or several game servers side by side, a VPS Linux gives you the datacentre network and NVMe storage without the managed layer. Prefer a panel but on your own instance? A VPS Pterodactyl lets you run Palworld alongside other titles from a single interface — handy if your community also runs Serveur Rust or Serveur Minecraft. The full catalogue sits under Tous nos serveurs de jeu.

Quick decision guide

Self-host if: 2–6 players, all friends, LAN or close geography, you own a spare high-frequency machine, and you enjoy sysadmin work.
Rent a game server if: public or semi-public community, players spread across regions, you want a panel and automatic backups, or you're behind CGNAT.
Rent a VPS if: you need root, run multiple games, or want to build a custom stack and are comfortable maintaining it.

Conclusion

Self-hosting Palworld teaches you a lot and works fine for a small private group. Past that, the constraints are structural: residential upload, CGNAT, exposed home IP, no upstream filtering, and backups you have to build yourself. Rented Palworld server hosting removes those variables so you spend your evenings tuning base camps instead of debugging port forwarding. More guides on the Blog Fly-Serv.

FAQ

How much RAM does a 20-player Palworld server actually need?

Plan for 16 GB minimum, and 24–32 GB if the world is several weeks old with many guild bases. Memory usage grows with base count and uptime rather than raw player count. Schedule a restart every 6–12 hours via RCON or a panel task to reclaim leaked memory before it affects tick rate.

Can I move my existing local save to a rented Palworld server?

Yes. Stop both servers, copy the entire world folder from Pal/Saved/SaveGames/0/<WorldID>/ into the same path on the new server, then update DedicatedServerName in Pal/Saved/Config/.../GameUserSettings.ini to match that world ID. Upload via the panel file manager or SFTP, keep file ownership consistent, and back up before you start.

Why does my Palworld server lag even though CPU usage shows only 20%?

Because Palworld is single-thread bound. A 20% total figure across 8 cores can still mean one core pinned at 100%. Check per-thread usage, then reduce BaseCampMaxNumInGuild, BaseCampWorkerMaxNum and DropItemMaxNum. High-frequency CPUs help far more than adding cores for this workload.