Palworld server settings: every PalWorldSettings.ini option

A Palworld dedicated server is configured by one line in one file: PalWorldSettings.ini, in Pal/Saved/Config/LinuxServer/, and everything the server knows about difficulty, rates, passwords, ports and limits is inside a single OptionSettings=(...) tuple on that line. Get a bracket wrong and the whole line is discarded silently, so the server comes up with factory defaults and nothing tells you. Two other things trip people up before they get that far: the file in the server's root folder is a template that the server never reads, and a world uploaded from co-op carries its own settings that beat the file entirely. This post goes through all of it, key by key.

Where the settings live#

There are two files with almost the same name, and only one of them does anything.

<server root>/DefaultPalWorldSettings.ini      <- template, read-only reference<server root>/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini    <- the live file

On a Windows server the live path is Pal/Saved/Config/WindowsServer/PalWorldSettings.ini instead. The live file does not exist until the server has started once, which is why the usual first move is: start the server, stop it, then edit. Copying DefaultPalWorldSettings.ini over the live file is the standard way to get a complete key list for the version you are actually running, and that matters more in Palworld than in most games, because Pocketpair adds options with nearly every content patch. Whatever list you read online, including this one, the file shipped with your build is the authority.

On a panel-based host you will find the same path under the file manager, or over SFTP with the per-server credentials on the server page. SFTP and the file manager covers getting an editor onto that path. Edit it with the server stopped. Palworld writes the config back out on shutdown, so an edit made while the server is running is usually overwritten the moment you stop it, and people lose an hour to that before they notice.

Some settings can also be passed on the command line, which overrides the file for that start. That is useful on a panel where the Startup tab exposes a few variables, and it is how you change the port or the player count without touching the config:

$ ./PalServer.sh -port=8211 -queryport=27015 -players=16 -publiclobby \    -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

The three performance flags at the end are not documented by Pocketpair but are recommended by essentially everyone who runs the server at scale, and they are the default on most hosts.

One line, every option#

The live file has exactly two lines that matter: a section header and the option tuple.

[/Script/Pal.PalGameWorldSettings]OptionSettings=(Difficulty=None,DayTimeSpeedRate=1.000000,ExpRate=1.000000,PalCaptureRate=1.000000,ServerName="Longship Crew",AdminPassword="...")

That is shown wrapped to fit the page. In the real file it is one unbroken line. Introduce a newline inside the brackets and the parser gives up on everything after it. The rules that follow from that format:

• No spaces after the commas, and no spaces around the = signs.
• Strings are double quoted, numbers are not, booleans are True or False with a capital letter.
• Floats are written with six decimal places by convention. 1.5 works, but match the style so diffs stay readable.
• Keys can be omitted. Anything missing falls back to the built-in default, so a short tuple with only the ten things you changed is legal and is far easier to maintain than a 90-key monster.
• A key the build does not recognise is ignored. This is how a guide written for an older patch quietly does nothing.

The failure mode is worth repeating because it is the single most common Palworld support ticket: a syntax error does not produce an error. The server starts, the world loads, and every rate is back to 1.0 with the password gone. If your settings "reset themselves", look for a stray space, a smart quote pasted from a web page, or a missing closing bracket before you look anywhere else.

Server name, passwords and ports#

These are the keys you set before anyone connects.

ServerName is also how anyone finds you, so make it searchable: the in-game list filter is a plain substring match and there are tens of thousands of servers on it. If you do not want to be listed at all, leave -publiclobby off the command line.

The ports:

Palworld's game traffic is UDP, so a firewall rule that only opens TCP produces a server that runs perfectly and cannot be joined. Game server ports explained goes through the query-port half of that pair, which is what decides whether you appear in the list at all. RCON and the REST API should never be open to the internet with a weak password on them; both are covered properly in Palworld admin commands, RCON and the REST API.

Difficulty and the rate multipliers#

Difficulty accepts None, Casual, Normal and Hard. Leave it at None and set the individual rates yourself. A named difficulty and a hand-set rate table are two sources of truth for the same number, and you will spend longer working out which one won than you would have spent typing the values.

Everything below is a multiplier around 1.000000.

Two of these need a warning. CollectionObjectRespawnSpeedRate is widely reported to work the opposite way round to its name, with lower numbers respawning nodes sooner, so change it in one step and go and look at a rock rather than trusting the label. And PalEggDefaultHatchingTime is in real hours of wall-clock time whether or not anybody is online, which is why almost every private server sets it to 1 or 0.

The survival rates work the same way but the naming is a minefield. Pocketpair shipped Decreace instead of Decrease and never fixed it, and mixes HP with Hp between keys. Copy them exactly:

PalStomachDecreaceRate at something like 0.3 is the setting that stops your base collapsing while nobody is logged in, and BuildObjectDeteriorationDamageRate=0.000000 is the one that stops the base rotting away between sessions. On a server that a group of friends visits at weekends, those two do more for morale than any XP multiplier.

Death penalty, PvP, guilds and raids#

DeathPenalty=All means you drop your whole inventory including equipment, which on a public server with bCanPickupOtherGuildDeathPenaltyDrop=True is a full-loot PvP game. For a private group, Item (drop the bag, keep what you are wearing) is the usual compromise, and None is what most six-player servers land on after the first time somebody dies in the volcano.

bExistPlayerAfterLogout=True sounds harmless and is not: it keeps a body in the world for every player who logs out, which is another set of entities to simulate and another thing that can be killed while its owner is asleep. Leave it off unless you are deliberately running a hardcore server.

The guild auto-reset pair is aimed at public servers. bAutoResetGuildNoOnlinePlayers=True with the default 72 hours will delete the guild and its bases of anybody who takes a long weekend off, so if you turn it on, raise the timer to something like 336 (two weeks) and tell people.

Bases, pals and the settings that cost memory#

Palworld's memory use tracks the number of simulated things, not the number of players, which is the argument in why your Palworld server needs more memory than you think. Four of these keys decide how many things there are.

The ordering of that list is roughly the order to reach for them. BaseCampWorkerMaxNum above 20 is where people report trouble; the game will accept a higher number and the base will behave strangely. BaseCampMaxNum at 128 is generous for a private server and can come down to 20 or 30 without anyone noticing, which stops one player building twelve outposts across the map. PalSpawnNumRate at 0.7 thins the wilderness noticeably on a server that is struggling, and costs less fun than you would expect because the density is tuned for single-player.

DropItemMaxNum=3000 is a lot of tracked objects. Halving it, and dropping DropItemAliveMaxHours to 0.5, is free performance on a busy server. The honest picture of what those knobs can and cannot do is in CPU vs RAM for game servers: if the container is at its memory ceiling, no rate setting saves it, and a bigger plan is the answer.

Leave bIsUseBackupSaveData=True. It writes rolling copies of the save beside the live one, which will not survive the disk going away but will save you from a corrupt Level.sav, and corrupt saves are the way Palworld worlds usually die. Real backups, off the machine, are still required - see backups that actually restore.

Saves, WorldOption.sav and moving a co-op world in#

The world lives under the save games folder, one directory per world, named with a 32-character hex ID:

Pal/Saved/SaveGames/0/<WorldID>/    Level.sav          the world: bases, pals, structures    LevelMeta.sav      name and metadata shown in the list    WorldOption.sav    settings baked into the world (co-op saves only)    Players/<id>.sav   one file per character

The server picks the world by -worldname or, with nothing set, the only folder it finds. Uploading a co-op world is four steps: stop the server, copy the whole <WorldID> folder in, delete WorldOption.sav from it, start the server. That third step is the one nobody mentions. WorldOption.sav is written when a world is created in co-op, it holds the settings that world was created with, and while it exists the dedicated server reads it instead of your carefully edited ini. Delete it and PalWorldSettings.ini takes over.

Player saves are per character and per world. A player's Players/<id>.sav is tied to their platform ID, so copying a world between servers brings characters with it, and deleting one player file resets that person to level one while leaving their guild's base standing.

Unlike Valheim, Palworld writes the world out frequently rather than on a long timer, so a crash costs seconds of progress rather than half an hour. The risk is a different one: the write is large and happens while the world keeps running, so a stop in the middle of one can leave a truncated Level.sav. Always use a clean stop, keep bIsUseBackupSaveData on, and take a real backup before every game update. On RE:NODE the panel's Stop is a clean shutdown, backup slots are included on every Palworld plan, and the Schedules tab will run a nightly backup and a restart on a cron expression for you.

Troubleshooting#

Every setting reverted to default. Syntax. Check for a line break inside OptionSettings=(...), a missing ), a curly quote from a browser, or a space after a comma. Also check you edited the file under Pal/Saved/Config/LinuxServer/ and not the template in the root.

Changes are ignored but the rest of the file works. Either the key does not exist in your build, or the world has a WorldOption.sav. Compare your key names against DefaultPalWorldSettings.ini from the same build, character for character, including Decreace.

The server is not in the community list. -publiclobby must be on the command line, both UDP ports must be reachable, and the list takes a few minutes. Test by joining directly on IP:8211 first; if that works, the server is fine.

Players connect and are immediately disconnected. Usually a password mismatch, or bUseAuth=True with a platform outage. Check the console output before assuming it is your config - reading the console is the shortest path to the actual line.

Memory climbs all week and then the server restarts on its own. That is the container hitting its limit. Palworld grows with the number of pals and structures, not the number of players, so it is expected on a long-lived world. A nightly restart keeps it flat; a permanently full memory graph means the plan is too small.

The world is gone and a new one appeared. The server could not read the save folder and generated a fresh world beside it. Your old <WorldID> folder is still there. Stop the server, check -worldname matches the folder name exactly, and delete the new empty world.

FAQ#

How many players can a Palworld dedicated server take?

ServerPlayerMaxNum goes to 32 and that is the supported ceiling. Whether 32 is sensible is a different question: every player builds bases and every base runs pals, so a full server needs far more memory than the player count suggests. Sixteen is a comfortable target on a well-sized plan.

Do I have to restart the server for a settings change?

Yes. PalWorldSettings.ini is read once at startup, and the running server rewrites it on shutdown, so edits made while it is up are lost. Stop, edit, start.

Which settings cannot be changed on an existing world?

Almost all of them can. The rates, damage multipliers, penalties and limits apply from the next start. What you cannot change retroactively is anything already built or captured, so lowering BaseCampWorkerMaxNum below the number of pals already assigned to a base leaves that base over its limit until someone fixes it by hand.

What is the difference between AdminPassword and ServerPassword?

ServerPassword is what players type to get in. AdminPassword is what an admin types to unlock the command set, and it is also the credential for RCON and the REST API. They should not be the same string.

Can Xbox and Steam players share a server?

Recent builds expose crossplay through a platform list in the settings, and the exact key name has changed between updates, so check DefaultPalWorldSettings.ini in your build rather than copying one from a guide. What has not changed is that crossplay servers are joined through the in-game list rather than by typing an IP.

Should I turn on RCON?

Only if you will use it. It is the practical way to run scheduled announcements and saves, but it is an unencrypted protocol with one shared password, so it belongs behind a firewall rule rather than open to the internet. RCON safely sets out the minimum.