Réserver un serveur Palworld à sa communauté : réglages et mot de passe

The Palworld server password is the simplest gate between a quiet, closed community and a lobby full of strangers dismantling your base camps. Everything is decided inside one file, PalWorldSettings.ini, plus a couple of launch parameters. This guide covers the exact keys to edit, the restart order to respect, and the moderation tools that back them up.

Where the Palworld server password is stored

Palworld reads its runtime configuration from a single INI file located inside the save structure, not from the template shipped with the binaries. The file you must edit is:

Pal/Saved/Config/LinuxServer/PalWorldSettings.ini     # Linux builds
Pal/Saved/Config/WindowsServer/PalWorldSettings.ini   # Windows builds

The template found at Pal/Saved/Config/DefaultPalWorldSettings.ini is a reference only: editing it changes nothing on a running instance. Inside a Pterodactyl panel, the same file is reachable through the File Manager, generally under /home/container/Pal/Saved/Config/LinuxServer/. Always stop the process before editing, because Palworld rewrites the INI when it shuts down and will silently overwrite anything you typed while it was running.

If your community runs on Fly-Serv infrastructure, that file is exposed directly in the panel alongside the console and the automatic backups, which makes password rotation a two-minute job — see Palworld server hosting for the Palworld-specific setup.

Understanding the OptionSettings line

The whole configuration lives on one single line under a section header. It looks like this (truncated):

[/Script/Pal.PalGameWorldSettings]
OptionSettings=(Difficulty=None,DayTimeSpeedRate=1.000000,ExpRate=1.000000,...,ServerName="My Guild",ServerDescription="",AdminPassword="",ServerPassword="",PublicPort=8211,PublicIP="",RCONEnabled=False,RCONPort=25575,Region="",bUseAuth=True,BanListURL="https://api.palworldgame.com/api/banlist.txt")

Three rules save a lot of debugging time:

• Never insert a line break inside OptionSettings=(...). A wrapped line is a broken line, and the game falls back to defaults — including an empty password.
• String values stay between double quotes, numeric and boolean values do not.
• Keep the parentheses balanced. A missing closing bracket produces a lobby that boots with default rules and no access control at all.

Setting ServerPassword, AdminPassword and lobby visibility

ServerPassword: the front door

This is the key that actually restricts access. Fill it in, and every client is prompted for a passphrase before joining, whether they come from the community list or from a direct IP connection.

ServerPassword="Guild-Anubis-2025"

Practical constraints learned the hard way: avoid commas, double quotes, parentheses and equal signs. Because the entire configuration is a comma-separated tuple, a comma inside the passphrase truncates parsing and the value is lost. Hyphens, underscores and alphanumeric characters are safe. Aim for 12 characters or more; a four-digit passphrase is scraped by automated crawlers in hours on a publicly listed lobby.

Once saved, restart the instance from the panel console. On reboot, check the startup log: the lobby name must appear with the password flag active. Players then connect with the IP, the port (8211 by default), and the passphrase.

AdminPassword: elevation, RCON and REST

AdminPassword is a completely different credential. It does not restrict who joins — it defines who can issue administrative commands. Keep it distinct from the Palworld server password shared with your members, and never post it in a Discord channel that guests can read.

AdminPassword="7f2C-adm-Q9xLr"
RCONEnabled=True
RCONPort=25575
RESTAPIEnabled=True
RESTAPIPort=8212

In game, a member types /AdminPassword 7f2C-adm-Q9xLr in the chat window to elevate their session, then gains access to kick, ban, teleport and shutdown commands. The same credential authenticates RCON sessions and the REST API (HTTP basic auth with the user admin).

Visibility: listed lobby or invitation only

Restricting access is a two-layer job. The passphrase blocks the join; visibility decides whether outsiders even see that your world exists. The community list registration is driven by a launch argument, exposed in most panels as a startup variable named bIsPublic, PUBLIC or similar:

# Listed in the in-game community tab
./PalServer.sh -publiclobby -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

# Unlisted: reachable only by direct IP and port
./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

For a closed guild, drop the -publiclobby flag (or toggle bIsPublic to false in the panel variables) and distribute the address manually. Combined with a strong passphrase, that removes you from the scanning surface of the community browser entirely. If you keep the lobby listed, set a ServerDescription that explains the world is passphrase-gated, so you stop receiving join attempts from random players.

Key	Type	Role
ServerPassword	String	Passphrase requested at connection
AdminPassword	String	Command elevation, RCON, REST API
bIsPublic / -publiclobby	Bool / flag	Community list registration
ServerPlayerMaxNum	Int	Hard slot ceiling
CoopPlayerMaxNum	Int	Guild size limit
bUseAuth	Bool	Platform authentication, keep True
BanListURL	String	Remote denylist consumed at boot
PublicIP / PublicPort	String / Int	Advertised endpoint

Slots, ban lists and whitelist-style access control

Capping the number of players

A slot ceiling is access control too. If your guild counts nine members, there is no reason to leave thirty-two seats open:

ServerPlayerMaxNum=10
CoopPlayerMaxNum=4

ServerPlayerMaxNum is the global ceiling for the world, while CoopPlayerMaxNum limits how many players can share a single guild. Lowering the ceiling also has a direct performance effect: fewer simultaneous base camps, fewer Pal AI routines, fewer physics objects to simulate. Palworld is heavily single-thread bound, which is why high-frequency Ryzen cores and NVMe storage matter more than raw core count when your world save grows past a few hundred megabytes.

There is no native whitelist file — here is what works instead

Unlike some survival titles, Palworld ships no whitelist.txt. A closed community is built by stacking four mechanisms:

1. The passphrase — mandatory, rotated whenever someone leaves the guild.
2. An unlisted lobby — no community browser exposure.
3. A denylist via BanListURL, pointing to a plain-text file you control.
4. RCON automation — polling connected UIDs and kicking anything outside your roster.

The BanListURL accepts any reachable HTTP endpoint returning one identifier per line. Host it on a static file or a raw repository link, and the list is re-read when the process boots:

BanListURL="https://files.myguild.tld/palworld/banlist.txt"

Building an allowlist with RCON

If you want true whitelist behaviour, poll the session with RCON and kick unknown UIDs. Using a lightweight RCON client on a Linux machine:

sudo apt update && sudo apt install -y mcrcon
mcrcon -H 127.0.0.1 -P 25575 -p 'YourAdminPassword' "ShowPlayers"

ShowPlayers returns a CSV with name,playeruid,steamid. A minimal enforcement loop looks like this:

#!/usr/bin/env bash
ALLOW="/opt/palworld/allow.txt"   # one steamid per line
RCON="mcrcon -H 127.0.0.1 -P 25575 -p YourAdminPassword"

$RCON "ShowPlayers" | tail -n +2 | while IFS=',' read -r name uid steamid; do
  [ -z "$steamid" ] && continue
  if ! grep -qx "$steamid" "$ALLOW"; then
    $RCON "KickPlayer $steamid"
    echo "$(date -Is) kicked $name ($steamid)" >> /var/log/palworld-allow.log
  fi
done

Schedule it every minute with cron or a systemd timer. It is blunt, but on a closed guild world it does the job without any third-party mod.

Useful RCON and in-game admin commands

Command	Effect
ShowPlayers	Lists connected players with UID and SteamID
KickPlayer <SteamID>	Disconnects a session immediately
BanPlayer <SteamID>	Adds the identifier to the local ban file
Broadcast <message>	Sends a message to everyone (no spaces on some builds)
Save	Forces a world save before maintenance
Shutdown <seconds> <message>	Graceful shutdown with countdown
Info	Returns build version and world name

Always run Save before Shutdown when you rotate credentials, and make sure automatic backups are enabled in the panel. Restoring a snapshot from twenty minutes ago is far cheaper than rebuilding a guild base camp by hand. The official parameter reference is maintained in the Palworld technical documentation.

Fixing a Palworld server password that refuses to work

Nine times out of ten, a rejected Palworld server password comes from one of these causes:

• The wrong file was edited. Changes in DefaultPalWorldSettings.ini are ignored. Only the copy under Saved/Config/<Platform>Server/ is read.
• The file was edited while the process was running. Palworld flushes its configuration on shutdown and overwrites manual edits. Stop first, edit, then boot again.
• A forbidden character broke the tuple. Remove commas, quotes and parentheses from the passphrase.
• Cached credentials on the client. Players who previously joined without a passphrase should remove the entry from their favourites and re-add the IP.
• Clients on an older build. After a patch, mismatched versions produce authentication errors that look like a rejected passphrase. Update the binaries, then reconnect.
• bUseAuth=False. Disabling platform authentication breaks identity checks and, on several builds, the passphrase prompt itself. Keep it at True.

Rotating credentials cleanly

A safe rotation sequence, from the console:

1. mcrcon ... "Broadcast Maintenance_in_5_minutes"
2. mcrcon ... "Save"
3. mcrcon ... "Shutdown 60 Credential_rotation"
4. Edit ServerPassword and AdminPassword in PalWorldSettings.ini
5. Trigger a manual backup from the panel
6. Boot the instance and verify with a test connection

Distribute the new passphrase through a members-only channel, never in a public announcement. If you also run other survival worlds — a Valheim server or an ARK Survival Ascended server, for example — use distinct credentials per world so a single leak never cascades. More configuration walkthroughs are collected on the Fly-Serv blog, and the full catalogue sits under All our game servers.

Hardening around the game itself

Volumetric DDoS filtering is handled at the infrastructure level, so your job stays at the application layer: keep RCON bound to localhost or behind a firewall rule, never expose port 25575 to the open internet, store the admin credential in a password manager, and verify backup retention monthly. If you administrate the machine yourself, add SSH key authentication, ufw rules limited to 8211/UDP and your management ports, and fail2ban on the SSH service.

Wrapping up

Access control in Palworld comes down to four values in a single INI line: the join passphrase, the admin credential, the lobby visibility flag and the slot ceiling. Add a denylist URL, a small RCON loop for roster enforcement, and regular backups, and your world stays exactly what a guild world should be — closed, stable and predictable.

FAQ

Why does my Palworld server password reset to empty after every restart?

You edited the INI while the process was still running. Palworld rewrites PalWorldSettings.ini during shutdown and overwrites manual changes. Stop the instance from the panel, wait for the console to confirm the process exited, edit the file, save, then boot again and check the startup log.

Can I hide my world from the in-game community list while keeping friends connected?

Yes. Remove the -publiclobby launch argument, or set the bIsPublic startup variable to false in your panel. The world stops appearing in the community browser but remains reachable through direct IP and port 8211, with the passphrase still required at connection.

Is there a real whitelist file in Palworld?

No native whitelist exists. The supported approach combines a passphrase, an unlisted lobby, a remote denylist through BanListURL, and an RCON script that polls ShowPlayers and kicks any SteamID absent from your roster file. Run that script every minute via cron or a systemd timer.