Prepay & save up to 40% · 3 months −20% · 6 months −30% · 12 months −40% Client Area
Guide

Palworld Server Settings: PalWorldSettings.ini Explained

Palworld··8 min read
A stylised survival island with cliffside villages and balloons at golden hour — Palworld server settings

Palworld gives you around a hundred server settings and almost no guidance about which ones matter. Most of them you will never touch. A handful change how the game feels, a smaller handful quietly decide whether your server holds twenty players or falls over at eight, and two file-level rules decide whether any of your edits take effect at all. This guide covers those, in that order.

Where the file lives, and which one to edit

Your server's live configuration is PalWorldSettings.ini:

  • Linux: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
  • Windows: Pal/Saved/Config/WindowsServer/PalWorldSettings.ini

Next to it you will find DefaultPalWorldSettings.ini. That one is a reference copy, and the official documentation is blunt about it: editing DefaultPalWorldSettings.ini will not affect anything. You copy from it, you do not edit it. Half of all "my settings do nothing" reports are exactly this mistake.

The format will bite you

The file is two meaningful lines. A section header, then one enormous OptionSettings=(...) line holding every setting as a comma-separated list. Three rules follow from that:

  • Never break the line. Adding newlines to make it readable is the most common way to destroy a config. Everything after the break is ignored.
  • One bad character kills the whole file. A missing comma, an unbalanced bracket or a stray quote can make the server fall back to defaults silently — no error, just a server that ignores you.
  • Restart to apply. Nothing takes effect while the server is running, and a server that is mid-shutdown will happily overwrite your file on the way out. Stop it first, edit, then start.

Editing through a host's panel avoids most of this, because the panel writes the line for you.

Why your settings get ignored anyway: WorldOption.sav

This is the one that costs people entire evenings, and most guides bury it at the bottom.

If a file called WorldOption.sav is present in your world's save folder, it takes priority over PalWorldSettings.ini for gameplay values. Your INI can say ExpRate=3.000000 all it likes; the save file wins and you get 1×. It typically arrives when a world is created in single-player or co-op and then moved to a dedicated server — the options travel with the save.

Server-level settings are not affected: name, passwords, player cap, ports and the API toggles still come from the INI. It is the gameplay multipliers that get overridden.

How to tell: change something obvious and instantly visible — ExpRate to 5 — restart, and check. If nothing changes, look for WorldOption.sav in the world folder. How to fix: stop the server, back up the whole save folder, remove that file, start again. Back up first, every time; this is your world, not a config file.

The settings worth changing

Grouped by what you are actually trying to do, rather than by the order the file happens to list them.

Identity and access

ServerName and ServerDescription are what people see in the browser. ServerPassword makes the server private; AdminPassword is a different thing entirely — it is the credential for admin commands and API access, so it should be long and not shared with your players. ServerPlayerMaxNum is your slot count, and PublicPort is the port players connect on (UDP 8211 on a stock install).

Pace: how fast the game moves

These are the multipliers people actually came for, all sitting at 1.0 by default:

  • ExpRate — levelling speed. 1.5–2× is the usual choice for a group that plays a few evenings a week; past 3× the early game evaporates.
  • PalCaptureRate — how readily Pals get caught. Small bumps go a long way; this is the one people over-tune and then find nothing is exciting any more.
  • WorkSpeedRate — base productivity. Raising this is much kinder to your server than adding more workers (see the performance section).
  • CollectionDropRate, EnemyDropItemRate, CollectionObjectRespawnSpeedRate — gathering yield and how fast nodes come back. The gentlest way to respect adult schedules.
  • PalEggDefaultHatchingTime — hours to hatch, 72 on a stock install. Almost every private server lowers this; a lot of them set it to 0.
  • DayTimeSpeedRate / NightTimeSpeedRate — these are speed multipliers, so a higher value makes that phase pass faster. If you want longer days, raise the night rate. This trips people up constantly.

Survival pressure

PlayerStomachDecreaceRate and PalStomachDecreaceRate control how fast hunger drains — lower them if your group logs in for short sessions and resents spending them cooking. DeathPenalty decides what you drop when you die; the stock value drops everything, and most friend groups soften it.

Guilds, bases and PvP

GuildPlayerMaxNum caps guild size. BaseCampMaxNum is the server-wide base count, BaseCampMaxNumInGuild the per-guild allowance, and BaseCampWorkerMaxNum the Pals per base — that last one is a performance setting in disguise, covered below. For PvP, bEnablePlayerToPlayerDamage is off by default, and bEnableFriendlyFire is a separate switch; turning on the first does not turn on the second.

The settings that decide whether your server survives

This is the part the parameter dumps leave out. Pocketpair's own documentation files a specific group of settings under Performances, and they are not the ones people instinctively reach for.

  • BaseCampWorkerMaxNum — the biggest single lever. Every worker Pal is continuous pathfinding, work-assignment and hunger simulation. Doubling it does not double the load, it more than doubles it, because they interact. If your bases stutter while the rest of the world is fine, this is your culprit. Raise WorkSpeedRate instead — you get the same "my base is productive" feeling for none of the CPU.
  • PalSpawnNumRate — how many wild Pals populate the world. More Pals means more AI running everywhere at once, including in places nobody is standing.
  • ServerPlayerMaxNum — set this to what you actually expect, not to the maximum because it is free. It is not free.
  • DropItemMaxNum and PhysicsActiveDropItemMaxNum — loose items on the ground, some of them running physics. A long-lived server accumulates these; a busy one accumulates them fast.
  • bEnableInvaderEnemy — raids. On by default, and a genuine load spike every time one fires. If your server is fine until suddenly it is not, this is a good first thing to switch off while you diagnose.
  • ServerReplicatePawnCullDistance — how far from a player Pals stay synced. Lowering it cuts network and simulation work at the cost of things popping in at distance.

The general principle: settings that multiply numbers of simulated things cost you performance, settings that multiply rates are close to free. ExpRate=3 costs nothing. BaseCampWorkerMaxNum=40 costs a great deal. Tune the rates first and you will rarely need to touch the rest.

None of this substitutes for headroom — we suggest 8–16 GB for a Palworld server, scaling with players and mods — but a badly tuned 16 GB server will still lose to a sensibly tuned 8 GB one.

Three presets to start from

Pick whichever is closest, run it for a week, then adjust one thing at a time.

Four friends, a couple of evenings a week

Slots to 4–8. ExpRate 1.5–2, PalEggDefaultHatchingTime down sharply, hunger rates lowered, DeathPenalty softened. Leave every performance setting alone — at this size nothing you do to them will be noticeable.

A dozen or so, semi-regular

Slots to roughly your real group plus a couple. ExpRate 1.5–2, gathering rates slightly up, WorkSpeedRate up rather than worker counts. Keep BaseCampWorkerMaxNum at or near stock and watch what happens when several people build at once — that is the moment this setting announces itself.

Public, twenty or more

ServerPassword empty, a strong AdminPassword, and conservative everything else. Rates near stock so progression means something, worker counts at stock, and a real look at DropItemMaxNum after the first busy weekend. Public servers fail on accumulated state, not on launch day.

Admin access: RCON is on the way out

If you are following an older guide, it will tell you to set RCONEnabled=True and a RCONPort. That still works today, but it is worth knowing where it is going: Pocketpair's documentation now states plainly that RCON is deprecated and recommends the REST API instead, adding that RCON is scheduled to stop functioning in a future update.

So if you are setting this up fresh, set RESTAPIEnabled=True and choose your RESTAPIPort rather than building tooling on RCON you will have to replace. The REST API authenticates with HTTP Basic Auth against your admin credential — which is the other reason AdminPassword deserves to be a real password. Expose neither port to the open internet; restrict them to addresses you control.

Frequently asked

Why are my Palworld server settings not applying?

In order of likelihood: you edited DefaultPalWorldSettings.ini instead of PalWorldSettings.ini; a WorldOption.sav in the world folder is overriding the gameplay values; the OptionSettings line has a syntax error or a line break; or the server was not fully stopped when you saved.

Do I have to restart the server after changing settings?

Yes. Changes are read at startup. Editing a file while the server runs can also be undone when it shuts down and writes its own state.

Which settings should I change first?

ExpRate, PalCaptureRate, PalEggDefaultHatchingTime and the hunger rates. They change how the game feels immediately and cost your server nothing.

Which settings hurt performance the most?

BaseCampWorkerMaxNum first, then PalSpawnNumRate and an oversized ServerPlayerMaxNum. Raids (bEnableInvaderEnemy) cause periodic spikes rather than constant load.

Can I change settings on a world that already exists?

Mostly yes — multipliers apply going forward. Anything already generated or already built stays as it is, and if a WorldOption.sav is present it will keep overriding you until you deal with it.

What port does a Palworld server use?

UDP 8211 for players on a stock install, set by PublicPort. Admin interfaces use their own ports and should not be publicly reachable.

Setting one up from scratch? Our Palworld server setup guide covers the install, and the Palworld hosting page covers what to run it on — with the config file editable from the panel, so the single-line format stops being your problem.

Deploy a Palworld server →

Related guides

Share:Twitter / XFacebookRedditWhatsApp

Ready to play?

Deploy your server in under 60 seconds — 7-day money-back guarantee.

Browse games