Palworld server settings explained for a friends-only world

Palworld server settings control your world’s progression, rules, and access through the active configuration file or your host’s controls. Most friend groups can start with a few deliberate edits and leave the rest alone. The hard part is knowing which value changes the experience you actually care about. This guide groups the important options, explains the easy-to-misread ones, and ends with a small change you can verify and reverse. It follows the current official documentation; the suggestions are starting points for your group, not a benchmarked preset.

Find your active Palworld server settings#

Edit the saved configuration for the server process that runs your world. The file shipped beside the server is a template, and a hosting panel may be the tool that writes the active file for you.

If you do not have a dedicated world yet, start with how to host a Palworld server. These paths belong to the dedicated server installation, not your game client’s installation or an ordinary co-op world’s menu.

1. Locate the installation that runs the world

   Launch a fresh server once to create its saved-data directories, then stop it normally. Relative to that installation, use the path matching the server’s operating system:

   Pal/Saved/Config/WindowsServer/PalWorldSettings.ini
   Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

   A Windows player joining a Linux host needs the Linux server path. The player’s operating system does not choose it.

2. Identify who writes the configuration

   Pocketpair’s configuration instructions say editing only DefaultPalWorldSettings.ini has no effect. For a new installation, use that installed template to initialize the active file. For an existing world, preserve the working configuration before editing it.

   With Docker, locate the persistent mount holding the server’s saved files. Inspect the image author’s configuration instructions: startup scripts or environment variables may regenerate the INI. With a rented server, check whether the panel form or direct file editing controls the next launch. Changing a generated file while leaving its source unchanged can make an edit disappear after restart.

Keep a copy of the original file somewhere your next save or panel action will not overwrite. You should now know both where the active configuration lives and which tool owns it.

Preserve the full configuration when editing#

Change individual fields inside the existing settings line instead of replacing the whole file with a short internet preset. A snippet that shows three options does not preserve your other customized values by itself.

The familiar structure uses this section header, followed by the existing OptionSettings=(...) entry:

[/Script/Pal.PalGameWorldSettings]

Keep the option entry on one physical line, with comma-separated fields and balanced parentheses. Booleans use values such as True and False; numeric multipliers use numbers; text fields use quoted strings. Enumeration values, such as DeathPenalty=None, are specific named choices rather than arbitrary descriptions.

When replacing a value, retain the spelling of the key. Some names contain unusual capitalization or spelling. Do not “correct” them in the file. Avoid adding a second copy of the same field elsewhere in the line: it makes the effective configuration harder to reason about.

Defaults also have a version attached to them. Pocketpair’s 1.0 release notes changed dedicated-server world defaults toward single-player Normal. A copied Early Access list is therefore not a reliable current default sheet.

Use the template supplied with your installed build to check its starting values. In this guide, a neutral multiplier or an editorial suggestion is labeled as such. Neither means every current server ships with that value, and an existing world may retain older custom settings.

Choose progression and day-night rates#

Adjust the activity that feels slow before increasing every multiplier. More EXP, more gathered resources, and faster days solve different complaints; changing all of them together makes it difficult to tell which change helped.

For a multiplier, 1.0 is the neutral example, 2.0 doubles the multiplier, and 0.5 halves it. That arithmetic is not a promise that every outcome becomes twice as easy. A capture multiplier, for example, should not be advertised as guaranteeing any particular catch.

Time-speed names are especially easy to reverse. If you want a longer daytime period, increasing its progression speed is the wrong direction. Compare the result over a cycle before making another edit. Keep the original value in your notes so you have a clear comparison.

Two other names deserve a second look. Pocketpair describes CollectionObjectRespawnSpeedRate as a resource respawn interval, so do not assume every key containing “Speed” follows the day-speed interpretation. Likewise, PlayerDamageRateDefense and PalDamageRateDefense multiply damage taken. Increasing them is not a straightforward armor upgrade.

Leave those less obvious controls alone unless they address a specific need. A small, understandable configuration is easier to maintain than a list of changes nobody remembers requesting.

Agree on death and permanent-loss rules#

Choose recoverable death drops separately from permanent-loss rules. Friends who agree to retrieve their equipment have not necessarily agreed to lose their character’s ability to respawn.

The official configuration table defines four DeathPenalty choices:

These describe the drop rule. bHardcore is a separate control that prevents respawning after death, and bPalLost enables permanent Pal loss on death. Inspect both before calling a server forgiving. Setting the drop penalty to None is not evidence that every permanent-loss option is disabled.

For a casual friends-only world, leaving permanent-loss features off is a reasonable editorial starting point. Ask the people who will bear the consequences before changing the rules on an established world. A more punishing setting can be appropriate for a group that explicitly wants it; it should not arrive as an unnoticed field in a downloaded preset.

Verify the intended configuration before players take risks. Do not use an important character or valuable Pal as the first experiment with irreversible rules.

Keep base, guild, and Pal limits separate#

Raise the limit that is actually stopping your group. Player slots, guild membership, base counts, and workers per base describe different things, even when a hosting panel places them next to one another.

Pocketpair also warns that increasing base-worker counts raises processing load. Expanding bases, workers, and spawning together adds several moving parts to the same experiment. Increase one constraint only when your group’s plans require it, then observe a busy session before raising another.

Use the Palworld server memory guide when planning capacity. Keep workload suggestions separate from the official requirements and your own observed behavior. There is no universal RAM or frame-rate saving attached to the configuration changes in this article.

If a busy base already slows down, use the server lag diagnosis to compare client rendering, network behavior, and simulation before changing several limits together.

Egg timing belongs in the same discussion because it affects how quickly the group’s collection grows. PalEggDefaultHatchingTime is documented as the time to hatch a Huge Egg, in hours. Other eggs still incubate; the value is not an identical timer for every egg. Check your installed value before changing it, and compare an actual incubator afterward rather than copying an old “72 hours by default” claim.

Keep your earlier configuration until the world has survived a normal play session with the new limits.

Separate raids, PvP, and building decay#

Decide independently whether you want base invaders, player conflict, and structure decay. Turning off one does not establish the state of the others.

For a cooperative group, keep PvP disabled unless everyone has chosen a competitive world. Pocketpair’s PvP instructions call it a trial feature outside their support coverage. They require enabling bIsPvP, bEnablePlayerToPlayerDamage, and bEnableDefenseOtherGuildPlayer together. A single copied flag is not a complete supported-PvP setup.

That is enough to recognize the controls here; designing competitive rules needs a separate discussion with the group. Do not promise that a raid switch makes every possible source of damage harmless, or that a building setting will restore something already destroyed.

After an edit, check the specific behavior you intended to change. If the complaint was unwanted base invasions, changing building damage instead has not addressed the same problem.

Protect server access and management#

Treat the server’s join password and administrator password as different permissions. Your friends need access to the world; they do not all need the ability to remove players or stop the server.

Mixed-platform access requires more than a setting in this table. The community-server instructions use -publiclobby for community listing, which Xbox-family and PS5 players need. Preserve your group’s permitted platforms when changing unrelated rules.

The launch-argument reference distinguishes the listening -port from the advertised PublicPort. Adjusting the latter alone is not a substitute for configuring the actual listening port and network path.

Management access is another separate path. Keep REST disabled unless you need it and have private access or appropriate firewall protection. Opening the game’s connection does not automatically secure an API. RCON also appears in older configurations, but Pocketpair now marks it deprecated; do not build new maintenance assumptions around indefinite support.

Verify an authorized join and the expected password behavior after restart. Never publish a complete configuration for troubleshooting without removing its secrets first.

Trial a small friends-world change and verify it#

Try a few agreed changes while preserving everything else. For a group that wants gentler recovery and slightly faster progress, the following is an editorial example, not a tested optimal preset or a complete settings file:

ExpRate=1.5,DeathPenalty=None,bEnableInvaderEnemy=False

Replace those three fields inside your existing full OptionSettings=(...) line. Do not paste the fragment as another INI line or replace the complete configuration with it. Check the separate permanent-loss controls discussed above before interpreting this example as forgiving.

1. Record the change and stop cleanly

   Write down the previous three values and tell players about the interruption. Use the dedicated-server administration commands for the save and shutdown routine, then preserve an independent copy of the stopped world and configuration.

2. Save through the controlling tool and restart

   Edit the active file or the host controls that generate it. Reopen the saved configuration and inspect the changed fields before starting the server through its normal launcher or host controls. A co-op settings menu is not proof that a separate dedicated server received the same changes.

3. Check the world before keeping the changes

   Rejoin and confirm the expected character and base. Compare EXP from a repeatable activity with your recorded baseline and inspect the configured death and raid rules. Keep the backup while your group checks the resulting experience. If the changes are wrong, stop normally, restore the previous configuration, restart, and verify again.

If edits appear to be ignored, first inspect the path, formatting, restart, and any panel or container regeneration. For an imported world, the pal-conf author’s documentation describes WorldOption.sav taking precedence over INI settings. Treat that as a tool-specific diagnostic lead, not proof that every current setting is overridden. Preserve the save and check the host or migration tool’s handling; do not delete the file as a routine fix.

Self-hosting is a reasonable choice if you are comfortable with this maintenance. If you want a provider to handle more of it, confirm its actual settings and backup controls before moving the world. The Game Hosting Palworld page currently offers a waitlist, so check availability rather than assuming an immediately usable panel.

Keep a short record of the values you changed and why. The useful result is a world whose rules your friends understand, with a recoverable configuration for the next restart.