# Palworld Server Hosting - everything RE:NODE has published > A Palworld server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it. Generated from https://www.renode.space/game-servers/palworld, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/palworld. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is Palworld dedicated servers, sized so a full lobby does not spend the evening rubber-banding. - Genres: Action, Adventure, Indie, RPG - Developer: Pocketpair - Released: 9 Jul, 2026 - Steam: https://store.steampowered.com/app/1623730/ ### What comes with every Palworld server - Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other Palworld server on the internet. - The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off. - Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine. - 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose. - 2 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them. - People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams. ### Which Palworld plan do you need? Memory is what decides whether a server holds together, so start there. The Standard tier gives 8 GB and 2 vCPU, which suits a private group. The Pro tier at 12 GB is where most public servers sit, and Premium at 14 GB exists for the servers that stay full. Storage matters more than people expect once mods and backups are involved - plans here run from 40 GB to 90 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have. If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players. More game servers: https://www.renode.space/ai/game-servers.md ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Where are the servers?** Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-15 22:30 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/palworld or in the panel shop at https://panel.renode.space before quoting one. | Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports | |---|---|---|---|---|---|---|---| | Standard | $19 | 8 GB | 2 vCPU | 40 GB | 1 | 2 | 2 | | Advanced | $25 | 10 GB | 2.5 vCPU | 50 GB | 1 | 2 | 2 | | Pro | $31 | 12 GB | 3 vCPU | 70 GB | 1 | 2 | 2 | | Premium | $38 | 14 GB | 3.5 vCPU | 90 GB | 1 | 2 | 2 | ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 7 posts, newest first. Each one follows in full after the list. - [Palworld server mods: UE4SS and pak mods](https://www.renode.space/blog/palworld-mods-ue4ss-on-server) (2026-10-07): How Palworld server mods work: UE4SS Lua mods, pak and LogicMods folders, server-side versus client mods, Linux limits, and surviving game updates. - [Palworld server performance and base limits](https://www.renode.space/blog/palworld-performance-and-base-limits) (2026-10-07): Why a Palworld server slows down as bases grow: base camp and worker limits, wild spawns, dropped items, server FPS from the REST API, and when to restart. - [Palworld: move a co-op world to a server](https://www.renode.space/blog/palworld-save-transfer-co-op-to-dedicated) (2026-10-07): Move a Palworld co-op world onto a dedicated server: where the save lives, DedicatedServerName, WorldOption.sav, and the host save fix for the lost character. - [Palworld server backups and world resets](https://www.renode.space/blog/palworld-server-backups-and-world-reset) (2026-10-07): Back up a Palworld dedicated server properly, restore Level.sav from a backup, and reset the world fully or partly without losing your settings or ban list. - [Palworld admin commands, RCON and REST API](https://www.renode.space/blog/palworld-admin-commands-and-rcon) (2026-09-21): Set an admin password, run every Palworld admin command in game or over RCON, drive the REST API with curl, and make bans stick on a dedicated server. - [Palworld server settings: PalWorldSettings.ini](https://www.renode.space/blog/palworld-server-settings-guide) (2026-09-21): Where PalWorldSettings.ini really lives, what each option does, sensible values for a private group, and why an uploaded co-op world ignores the file. - [Palworld server memory: how much RAM](https://www.renode.space/blog/palworld-server-memory) (2026-06-30): Palworld holds every pal in memory whether anyone is near it or not. Real RAM figures by group size, the settings that set the ceiling, and what to do when it climbs. --- ### Palworld server mods: UE4SS and pak mods Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/palworld-mods-ue4ss-on-server Palworld has no official mod loader, so server mods run on community tools. There are two kinds. **Pak mods** are Unreal asset files dropped into `Pal/Content/Paks/~mods/`; they change data and assets and need no loader. **Script mods** are Lua (or C++) mods run by UE4SS, an Unreal Engine scripting system installed into `Pal/Binaries/Win64/`; they change behaviour at runtime. UE4SS is built for Windows, so script mods on a server realistically mean the Windows server build - natively, or under Wine on Linux. The question that decides everything else is where a mod has to be installed: on the server only, on clients only, or on both. Get that right and a modded Palworld server is manageable. Get it wrong and players are kicked on join or see a world that does not match the server's. Setting up the server itself is covered in [Palworld server settings](https://www.renode.space/blog/palworld-server-settings-guide), and a surprising number of things people install mods for are already settings there - rates, stack weight, base limits. Check that first. Every mod you do not install is one that cannot break on patch day. #### The two kinds of Palworld mod | Kind | Where it goes | Needs a loader | Typical use | | --- | --- | --- | --- | | Pak mod | `Pal/Content/Paks/~mods/` | No | Data tables, models, textures, sounds | | Blueprint (Logic) mod | `Pal/Content/Paks/LogicMods/` | UE4SS | New behaviour built in the Unreal editor | | Lua script mod | UE4SS `Mods/` folder | UE4SS | Rule changes, admin tools, commands | | Native (C++/DLL) mod | Varies, usually beside UE4SS | Often UE4SS | Server tools, anti-cheat, deep changes | **Pak mods** are the oldest and simplest form. Unreal loads every `.pak` it finds in the game's pak folders, and a pak in `~mods` is loaded after the game's own, so it overrides what it contains. A pak can replace a data table (pal stats, item recipes, drop rates) or an asset (a model, a texture). Pak mods do not run code. **UE4SS** - the community project RE-UE4SS - injects into the game process and gives mods a Lua scripting API, hooks into game functions, and a loader for blueprint mods. Most mods that change how the server behaves rather than what its data says are UE4SS mods. Palworld support has historically needed a UE4SS build that knows Palworld's version; the mod pages say which build they expect. #### Server-side, client-side or both Every mod falls into one of three groups, and you need to know which before you install it. - **Server-side only.** The server is authoritative for most of the game: spawning, drops, damage, pal behaviour at bases, player data. A mod that changes those things through script can run only on the server, and players need nothing. Admin tools, logging, Discord bridges, server-side protection tools and many rule tweaks belong here. - **Client-side only.** Interface changes, visual replacements, camera and quality-of-life mods that only affect what one player sees. The server is not involved; players install them on their own PC and the server does not care. - **Both.** Mods that add new content - new pals, new items, new structures - or that change data the client also reads. If the client does not have the mod, it does not know what the server is talking about. Depending on the mod, a player without it sees missing models, cannot interact with the new thing, or crashes. The mod page usually says. When it does not, treat any mod that adds content as "both" and any mod that only changes numbers the server calculates as worth trying server-side first. Data-table pak mods are the grey zone. If the server is authoritative for a value - a drop rate, a work speed - the server's copy of the table is the one that matters. If the client also displays or predicts the value, a client without the mod shows the old number while the server uses the new one. It works, but it confuses people. For anything players will notice, require the same pak on both sides. > [!WARNING] > Console players cannot install mods. A Palworld server that needs a client-side mod is a PC-only server, whatever the crossplay settings say. If your group includes Xbox or PlayStation players, stick to server-side mods. #### Installing UE4SS on a Windows server The Windows dedicated server's binary lives in `Pal/Binaries/Win64/`. UE4SS installs there, next to it. 1. Stop the server and take a backup of the world folder. 2. Download a UE4SS release that supports your Palworld version. Newer UE4SS releases ship as a `dwmapi.dll` proxy plus a `ue4ss` folder; older ones as `UE4SS.dll` with settings and a `Mods` folder alongside. Follow the layout of the release you download - do not mix files from two versions. 3. Extract it into `Pal/Binaries/Win64/`. 4. Start the server once. UE4SS writes a log file (`UE4SS.log`) in its folder. If the log shows UE4SS initialising and finding the game's functions, it is working. 5. Stop the server again before adding mods. A typical layout after installing a recent release: ```text Pal/Binaries/Win64/ PalServer-Win64-Shipping-Cmd.exe dwmapi.dll ue4ss/ UE4SS.dll UE4SS-settings.ini UE4SS.log Mods/ mods.txt BPModLoaderMod/ SomeLuaMod/ Scripts/main.lua enabled.txt ``` UE4SS settings live in `UE4SS-settings.ini`. On a headless server, turn off anything to do with the GUI console or debug windows; there is nobody to see them and they can cause trouble on a machine without a display. #### Installing mods **Lua mods** are folders. Each goes into UE4SS's `Mods/` folder with its `Scripts/main.lua` inside. A mod is enabled by an `enabled.txt` file in its folder, or by a line in `Mods/mods.txt`: Mods/mods.txt: ```text BPModLoaderMod : 1 SomeLuaMod : 1 AnotherMod : 0 ``` `1` loads the mod, `0` skips it. The built-in mods UE4SS ships with, such as `BPModLoaderMod`, should stay enabled if you use blueprint mods; it is what loads them. **Blueprint mods** are paks that go into `Pal/Content/Paks/LogicMods/` (create the folder if it is missing). They are loaded by UE4SS's blueprint loader, so they do nothing without UE4SS. **Pak mods** go into `Pal/Content/Paks/~mods/` (create it if missing). The tilde makes the folder sort after the game's own paks, which is what gives mods priority. When two pak mods change the same asset, the one that loads last wins; some mod authors name their files with a number or letter prefix to control order. [Mod load order explained](https://www.renode.space/blog/mod-load-order-explained) covers the general idea. Upload all of these through the file manager or SFTP - [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) has the details - and add one mod at a time. Start the server after each, check the log, play for a bit, then add the next. When something breaks, the cause is the last thing you added. Mods for Palworld are mostly published on Nexus Mods, with installation notes on each page. Read the requirements section: many mods depend on a specific UE4SS version or on another mod such as a shared library or a data-editing framework. #### Linux servers The official Linux dedicated server is the efficient way to run vanilla Palworld, and it is a poor fit for script mods. UE4SS is developed for Windows. It has had experimental Linux efforts, but in practice: - **Pak mods** may load on the Linux server, depending on how they were built. Test each one. - **UE4SS, Lua and blueprint mods** generally mean running the **Windows** server build instead. On a Linux machine that means running the Windows build under Wine or Proton, which works for many people and costs extra memory and some stability. [Wine and Proton for Windows-only servers](https://www.renode.space/blog/wine-and-proton-for-windows-only-servers) covers the trade-offs. - **Native DLL mods** are Windows only. If a server is going to be modded beyond a few pak files, decide on the Windows build at the start rather than migrating later. The world save is the same format either way, so moving is possible; it is just one more thing to do on a day you would rather be playing. #### What mods cost Most Palworld mods are cheap. A Lua script that adjusts a value when a pal is captured costs nothing measurable. The ones that cost are the ones that change how much the world holds: - **Raising base and pal limits** beyond what `PalWorldSettings.ini` allows. More working pals is more simulation and more memory; the [Palworld performance and base limits](https://www.renode.space/blog/palworld-performance-and-base-limits) post explains why pals, not players, are the cost. - **Mods that add many spawns** or new pals that roam the world. - **Mods that keep extra data per player** and write it on every save. - **UE4SS itself under Wine,** which adds overhead before any mod runs. Watch the memory graph for a few days after a new content mod. A mod that adds a slow climb shows up across days, not minutes. #### Game updates break mods This is the part of running a modded Palworld server that takes the most time. UE4SS finds the game's functions by looking for patterns in the executable. A game update moves those, and until UE4SS (and each mod) is updated, the server may fail to start, start without mods, or crash when a mod calls something that is no longer where it was. Pak mods that replace data tables break when the game changes the table's layout. A defensive routine: 1. **Turn off automatic updates on a modded server**, if your setup allows. Update deliberately. 2. **Before updating the game, check the UE4SS and mod pages** for versions that support the new build. 3. **Back up the world and the whole `Pal/Binaries/Win64/` folder** before updating, so you can put the old mod setup back. 4. **After updating, start once with mods disabled** (rename `Mods/mods.txt` entries to `0` or move `~mods` aside) to confirm the vanilla server and world load. Then enable mods one at a time. 5. **Players must update their client mods too,** for any mod that is installed on both sides. Tell them which version. The general procedure for the morning after a breaking update is in [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks). > [!TIP] > Keep a short text file next to the server listing every mod, its version, where it came from, and whether players need it. On patch day it is the checklist; when someone asks "which mods do I need?", it is the answer. #### Keeping a modded server safe Mods are code running in your server's process. A UE4SS or DLL mod can do anything the server can: read files, change saves, open network connections. Download from the mod's real page, prefer mods with source available or a long track record, and be suspicious of a "fixed" or "unlocked" version of a mod re-uploaded by someone else. [Keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) has the checklist. Server-side protection and admin tools are among the most useful server-only mods for a public server. PalDefender (previously known as PalGuard) is the best known; it runs on the Windows server and adds checks against common cheats plus admin features. Read its documentation for the version it supports. #### Mods on RE:NODE On RE:NODE, mods are uploaded by you through the in-browser file manager - which unpacks archives in place, so a UE4SS release zip can be dropped in and extracted - or over SFTP. There is no allow list and no one-click mod installer; you choose the mods and their versions. What a panel cannot change is which server build the install runs, and the Linux limits above apply to any Linux-based install - if your plans depend on UE4SS script mods, check which build your server runs before you build a mod list around it, and ask support if the files do not make it obvious. Palworld plans start from 8 GB, and backup slots on every plan cover the back-up-before-patch-day step. If a mod crashes the server repeatedly, the crash watcher raises a warning and opens a ticket after three restarts in an hour, which is usually the first sign that a mod did not survive an update. #### Troubleshooting **The server starts but no Lua mods run.** UE4SS did not load. Check that its files are in `Pal/Binaries/Win64/` next to the server executable and that `UE4SS.log` exists and shows initialisation. On a Linux build, UE4SS will not load at all. **UE4SS loads and then the server crashes.** A UE4SS build that does not support this game version. Update UE4SS, or remove it until a supported build exists. **Blueprint mods do nothing.** `BPModLoaderMod` is disabled, or the paks are in `~mods` instead of `LogicMods`. **Players crash or see missing models.** They lack a mod that must be installed on both sides, or have a different version. **A pak mod's changes do not apply.** Another pak loaded later overrides the same asset, or the game changed the data table and the mod is outdated. **Everything broke after a game update.** Expected. Start vanilla, then reintroduce mods one at a time as they are updated. #### FAQ ##### Does a Palworld dedicated server support mods officially? No. Mods run on community tools: pak files loaded by the engine and UE4SS for scripts and blueprint mods. Check the game's patch notes for changes, as official support has been discussed but is not what servers rely on today. ##### Do players need the same mods as the server? Only for mods that add content or that the client must know about. Server-side mods such as admin tools and many rule changes need nothing on the client. ##### Can I run UE4SS on a Linux Palworld server? Not reliably. UE4SS is built for Windows. Modded servers usually run the Windows server build, either on Windows or under Wine on Linux. ##### Can Xbox and PlayStation players join a modded server? Only if every mod is server-side. Console players cannot install mods, so any mod that requires a client install excludes them. ##### Why did my mods stop working after an update? UE4SS and many mods depend on the exact game version. After an update they need updating too. Keep backups of the working mod setup and update deliberately. Palworld servers on RE:NODE start from 8 GB. Upload mods through the file manager, which unpacks archives in place, or over SFTP - there is no allow list. Backup slots on every plan cover the copy you take before each game update. [See Palworld plans](https://www.renode.space/game-servers/palworld) --- ### Palworld server performance and base limits Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/palworld-performance-and-base-limits A Palworld server gets slower as its bases grow, not as its player count grows. Every working pal in every base camp is simulated all the time, whether anyone is nearby or not, and each one pathfinds, works, eats, sleeps and occasionally gets stuck. The levers that matter are in `PalWorldSettings.ini`: `BaseCampMaxNumInGuild` and `BaseCampWorkerMaxNum` (how many pals are working), `BaseCampMaxNum` (the server-wide camp total), `PalSpawnNumRate` (wild pals), and `DropItemMaxNum` (loose items). Measure before you change anything - the REST API reports the server's frame rate - and restart daily, because a long-running Palworld server degrades on its own. That is the summary. Below is the reasoning, the numbers, and the lag that settings will not fix. The memory side of the same story - how many gigabytes a given world needs - is in [Palworld server memory](https://www.renode.space/blog/palworld-server-memory). This post is about the server feeling slow: pals rubber-banding, actions arriving late, bases that stall. #### What lag on a Palworld server actually is Players say "lag" for three different problems, and only one of them is the server. | Symptom | Likely cause | Where to look | | --- | --- | --- | | Everything is delayed for everyone, pals teleport, doors open late | Server frame rate has dropped | REST API metrics, CPU graph | | One player rubber-bands, everyone else is fine | That player's connection | Their ping and packet loss | | A hitch every so often for everyone, then normal | Autosave writing `Level.sav` | `AutoSaveSpan`, save size | | Server stops with nothing in the log | Out of memory | Memory graph across days | The server runs a simulation loop. Each pass through the loop - a frame - it updates every active pal, every player, every projectile and every base task, then sends the results to clients. When there is more work than fits in a frame, frames take longer and the server's frame rate drops. Clients receive updates less often and have to guess in between, which is the teleporting and rubber-banding everyone notices. That is server lag in the proper sense, and it is almost always caused by the amount of world being simulated, not by the network. One player's bad connection looks similar from their side but is invisible to everyone else. [Latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) is the guide to telling them apart; if only one person complains, start there. #### Measuring the server's frame rate Do not tune by feel. The REST API has a metrics endpoint that returns the server's current frame rate and frame time alongside the player count and uptime: ```bash $ curl -s -u admin:YOUR_ADMIN_PASSWORD http://203.0.113.10:8212/v1/api/metrics ``` ```json { "serverfps": 58, "currentplayernum": 7, "serverframetime": 17.2, "maxplayernum": 16, "uptime": 41820 } ``` The fields you care about are `serverfps` and `serverframetime` (in milliseconds). Later builds have added more fields; the core ones have been stable. The REST API has to be enabled with `RESTAPIEnabled=True` and listens on `RESTAPIPort`, `8212` by default - [Palworld admin commands and RCON](https://www.renode.space/blog/palworld-admin-commands-and-rcon) covers turning it on and keeping it private. What matters is not the absolute number but how it moves. Note the frame rate on a quiet evening with a fresh world, then again when everyone is on, then a week later at the same time. A server that holds its usual rate with the full group on is healthy. One whose rate falls every week as bases grow is telling you exactly where the problem is. A frame rate that drops sharply when people gather at one base and recovers when they leave points at that base. Combine this with the CPU graph. A server at its CPU limit while the frame rate drops is CPU-bound; more CPU or less simulation will help. A server with spare CPU and a low frame rate is limited by its main thread, which is the more common case - most of the loop is single-threaded, so a faster core helps and more cores do not. [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) and [reading a server load graph](https://www.renode.space/blog/reading-a-server-load-graph) explain how to read that. #### Base camps and workers: the main cost A base camp is an area with a palbox. Pals assigned to it work - mining, logging, crafting, carrying, farming - and that work is simulated constantly. Three settings set how much of it exists. | Setting | Default | What it limits | | --- | --- | --- | | `BaseCampMaxNum` | `128` | Base camps on the whole server | | `BaseCampMaxNumInGuild` | `4` | Base camps per guild | | `BaseCampWorkerMaxNum` | `15` | Working pals per base camp | | `GuildPlayerMaxNum` | `20` | Players per guild | Defaults have changed between versions, and the maximum allowed for `BaseCampWorkerMaxNum` has risen over time. `DefaultPalWorldSettings.ini` in your own install is the authoritative list. The arithmetic is the whole argument. The number of working pals on a server is roughly guilds times camps per guild times workers per camp: | Guilds | Camps each | Workers each | Working pals | | --- | --- | --- | --- | | 1 (friends) | 3 | 15 | 45 | | 1 (friends) | 4 | 20 | 80 | | 4 (small public) | 4 | 15 | 240 | | 4 (small public) | 3 | 12 | 144 | | 10 (public, solo guilds) | 4 | 15 | 600 | A server with 600 working pals is doing an enormous amount of work every frame regardless of how many people are online. The quickest improvement for a public server is usually `BaseCampMaxNumInGuild=3` and `BaseCampWorkerMaxNum=12`: almost nobody notices, and the simulated pal count drops by more than a third. Raising `BaseCampWorkerMaxNum` is the request you will get most often, and on a small private server it is fine - one guild with 20 or 25 workers per camp is well within what a server handles. On a public server, every guild gets the same allowance, so think in totals, not per guild. > [!NOTE] > Lowering a limit does not delete existing camps or remove existing workers. Players already over the new limit keep what they have; they just cannot add more. That makes reductions gentle, and it means a reduction only shows its full effect over time as old bases are abandoned or reset. #### Why some bases cost more than others Two bases with the same number of pals can have very different costs. Pals in Palworld path to their work, and the cost of pathfinding depends on the shape of the base. - **Multi-storey bases** with stairs, ramps and narrow corridors make pathing expensive and make stuck pals common. A stuck pal tries again, and again, every frame. - **Work stations spread far apart** inside the camp radius mean long walks with many path recalculations. - **Bases on uneven ground** produce pals that fall off ledges and struggle to return. - **Overlapping or crowded camps** where pals from different bases get in each other's way. If the frame rate drops when players gather at one particular base, that base is a candidate. Ask its owner to simplify the layout: work stations on one level where possible, wide paths, stairs replaced with ramps, and the palbox near the centre. It is a better fix than any setting, and players are usually happy to do it once they understand why their pals keep getting stuck too. #### Wild pals, items and the rest of the world Bases are the biggest cost on an established server, but not the only one. **Wild pal spawns.** `PalSpawnNumRate` scales how many wild pals the world spawns; the default is `1.0`. Lowering it to `0.8` or so reduces the number of pals the server simulates in active areas. Raising it makes the world feel busier and costs proportionally. It also affects capture and farming, so tell players before you change it. **Dropped items.** `DropItemMaxNum` caps how many items lie on the ground at once, and `DropItemAliveMaxHours` sets how long each one lasts. On a busy server, dropped items accumulate quickly - from deaths, from full inventories, from pals - and each one is an object. Halving the cap rarely affects anyone and is close to free performance. **Raids.** `bEnableInvaderEnemy` turns base raids on or off. A raid spawns a group of enemies at a base and is a short burst of extra simulation. On a server where several bases are raided at once, it shows up as a dip. Most groups keep raids on because they are part of the game; turning them off is an option if a server is struggling. **View distance.** Later builds added `ServerReplicatePawnCullDistance`, which controls how far away the server sends other players and pals to each client. Lowering it reduces network and replication work; raising it makes far-off things visible earlier. Check whether your version has it before you add it. **Structure counts.** Recent builds have a setting to cap structures (look for `MaxBuildingLimitNum` in your version's defaults). Every wall, floor and chest is an object in the save and in memory; a cap is the bluntest way to keep a public world from becoming a mega-base contest. #### Restarts and slow degradation A Palworld server that is restarted daily performs better than one left up for a week, even with the same world. Over long uptimes memory grows, small simulation problems accumulate (pals stuck in walls, items that never despawned), and the frame rate drifts down. A restart clears all of that; the world reloads from its last save and everything starts fresh. A daily restart at an hour nobody plays is normal practice for Palworld. Warn players first with `Broadcast`, save with `Save`, then restart. On RE:NODE, the Schedules tab runs that sequence on a cron expression - a broadcast, a wait, the save, a backup, and a restart - as ordered tasks, so nobody has to remember. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers the timing, and [Palworld backups and world reset](https://www.renode.space/blog/palworld-server-backups-and-world-reset) covers putting the backup in the same schedule. If a server needs restarting more than once a day to stay playable, the world is too big for the server. That is a decision between more resources and less world, not a reason to restart every six hours. #### Autosave hitches `AutoSaveSpan` sets how often the world is written to `Level.sav`, in seconds. Writing a large save takes time, and on a mature world it causes a visible hitch. The default is short - thirty seconds - which caps how much is lost in a crash but means frequent hitches on a big world. Raising it to 180 or 300 smooths play; the trade is up to that many seconds lost if the server stops uncleanly. On a stable server, the longer interval is usually the better trade. Fast storage shortens the hitch but does not remove it, because the cost is partly serialising the world, not only writing it. RE:NODE runs on NVMe throughout, which helps the write half. #### A tuning order that works When a server is slow, change things in this order and measure after each: 1. **Restart it.** If performance returns to normal and degrades again over days, add a daily restart and stop there. 2. **Check memory.** A server near its limit behaves badly before it runs out. If memory is the issue, read [Palworld server memory](https://www.renode.space/blog/palworld-server-memory). 3. **Count bases and workers.** Ask how many camps and workers exist. If it is in the hundreds, lower `BaseCampMaxNumInGuild` and `BaseCampWorkerMaxNum`. 4. **Find the expensive base.** Watch the frame rate as players move around. Simplify the base that drags it down. 5. **Trim the world.** `DropItemMaxNum`, `PalSpawnNumRate`, `AutoResetGuildNoOnlinePlayers` for abandoned guilds. 6. **Then look at resources.** If the server is consistently at its CPU limit after all of that, it needs more CPU. On RE:NODE, changing plan raises the limit on the same server without rebuilding it - see [when to upgrade your plan](https://www.renode.space/blog/when-to-upgrade-your-plan). #### Troubleshooting **Pals teleport and doors open late for everyone.** Server frame rate. Check the metrics endpoint and the CPU graph, then work through the tuning order. **Performance was fine for weeks and slowly got worse.** World growth. More bases, more workers, a larger save. Restart daily and trim limits. **One base is unplayable, the rest of the world is fine.** That base's layout. Simplify it, and check for stuck pals. **A hitch every thirty seconds.** `AutoSaveSpan` at its default on a large world. Raise it. **The server is fast after a restart and slow by evening.** Uptime degradation. Daily restarts, and check memory growth across the day. **Lowering limits did nothing.** Existing camps and workers above the new limits remain until they are removed. The effect builds up as old bases go. #### FAQ ##### How many base camps can a Palworld server handle? It depends on the workers per camp and the server's CPU. Think in total working pals rather than camps: a hundred or two is comfortable on a mid-sized server, several hundred is where frame rates start to suffer. ##### Does lowering BaseCampWorkerMaxNum remove existing pals? No. Pals already working stay; nobody can assign new ones beyond the limit. The full effect appears as bases are rebuilt or abandoned. ##### Why does my Palworld server lag with only a few players? Because the cost is the world, not the players. A few players with many large bases can load a server more than a full server of new players. ##### Will more CPU cores make a Palworld server faster? Only up to a point. Most of the simulation runs on one main thread, so a faster core helps more than extra cores. The multithreading launch flags help use what extra cores there are. ##### How often should I restart a Palworld server? Daily is normal. It clears accumulated problems and memory growth. If the server needs restarting more often to stay playable, it is undersized for the world. Palworld servers on RE:NODE start from 8 GB on NVMe storage, with graphs for memory, CPU and disk against the plan's limits in the console. The Schedules tab runs the daily save, backup and restart, and moving to a bigger plan raises the limits without rebuilding the server. [See Palworld plans](https://www.renode.space/game-servers/palworld) --- ### Palworld: move a co-op world to a server Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/palworld-save-transfer-co-op-to-dedicated To move a Palworld co-op world onto a dedicated server, copy the world's folder from `%LOCALAPPDATA%\Pal\Saved\SaveGames\\\` on the host's PC into the server's `Pal/Saved/SaveGames/0/`, delete `WorldOption.sav` from it, set `DedicatedServerName=` in the server's `GameUserSettings.ini`, and start the server. Everyone's bases and pals arrive intact, and every guest keeps their character. The one person who does not is the host: in co-op their character is saved under a fixed placeholder ID, and on a dedicated server they are identified by their real account, so the server greets them with character creation. Getting the host's character back takes one extra step with a community tool. This post walks through all of it, including what to do when it goes wrong. #### Why the host loses their character Palworld stores each player as a separate file in the world's `Players` folder, named with a 32-character ID. On a dedicated server, that ID is derived from the player's platform account. In co-op, guests get the same kind of ID, so their files carry over untouched. The host does not: in a co-op world the host is always saved as `00000000000000000000000000000001.sav`, whoever they are. ```text /Players/ 00000000000000000000000000000001.sav the co-op host 4A7F2C1E000000000000000000000000.sav a guest 9C21B08D000000000000000000000000.sav another guest ``` When the host joins the dedicated server, the server looks for a file matching their real ID, does not find one, and starts a new character. The old one is still in the folder, attached to nobody. The guild, bases and pals still reference the old ID too, which is why simply renaming the file is not enough: the world itself holds that ID in many places inside `Level.sav`. The fix is to rewrite those references from the old ID to the new one. That is what the host save fix tools do. #### Before you start Gather four things first; the transfer is quick once they are ready. | You need | Where it comes from | | --- | --- | | The co-op world folder | The host's PC, see below | | A running dedicated server on the same game version | Your host, or SteamCMD app `2394010` | | Access to the server's files | File manager or SFTP | | Python 3 and the host save fix tool (only for the host's character) | Installed on any PC | The game version matters. A save from a newer client will not load on an older server, and the save format itself has changed more than once over Palworld's life. Update the server before you upload, and if the host's PC has not played since a big patch, load the world once in co-op first so it is saved in the current format. Do this at a time when nobody needs to play. The whole job takes half an hour if nothing goes wrong and an evening if something does. #### Finding the co-op save On a Steam copy on Windows, co-op worlds live here: ```text %LOCALAPPDATA%\Pal\Saved\SaveGames\\\ ``` Paste the first part into the Explorer address bar. Inside the folder named after the host's SteamID64 there is one folder per world, each named with a 32-character hex ID. If there are several, open each one's `LevelMeta.sav` date or check which was modified most recently; the world you played last night is the one with today's timestamps. A world folder looks like this: ```text / Level.sav the world: bases, pals, structures, items LevelMeta.sav name and metadata for the world list WorldOption.sav the settings the world was created with Players/ one file per character backup/ rolling backups, if enabled ``` Copy the whole folder somewhere safe on the PC before you do anything else. That copy is your rollback if every later step fails. > [!NOTE] > Xbox app and Game Pass copies of Palworld store saves in a different container format, not as plain `.sav` files in this folder. They need a conversion step with a community tool before they can be used on a dedicated server, and those tools change with game updates. Steam saves need no conversion. #### Uploading the world With the server stopped: 1. Upload the whole `` folder into `Pal/Saved/SaveGames/0/` on the server. The `0` folder is where the dedicated server keeps its worlds. Upload the folder, not its contents loose. 2. Delete `WorldOption.sav` from the uploaded folder. While it exists, it carries the co-op world's settings and can override your server's `PalWorldSettings.ini`. The [Palworld server settings guide](https://www.renode.space/blog/palworld-server-settings-guide) explains why this is the step that makes edited settings appear to do nothing. 3. You can delete the `backup` folder from the upload to save space. The server makes its own. 4. Point the server at the world. Edit `Pal/Saved/Config/LinuxServer/GameUserSettings.ini` (`WindowsServer` on a Windows server): Pal/Saved/Config/LinuxServer/GameUserSettings.ini: ```ini [/Script/Pal.PalGameLocalSettings] DedicatedServerName=4F6A2D1B8C9E4E1F9A0B3C5D7E8F1A2B ``` The value is the folder name, exactly. If the file does not exist yet, start the server once with no world to let it create the folders, stop it, then edit. If the line already exists with another ID - the world the server generated on its first start - replace that ID with yours. 5. Start the server and watch the console. A successful load is quiet; the tell-tale sign of failure is a brand-new world folder appearing in `SaveGames/0/` next to yours, which means `DedicatedServerName` did not match and the server created a fresh world. For large saves, upload over SFTP rather than through a browser. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) has the connection details. At this point guests can join and will find their characters, levels, pals and bases. The host will be asked to create a character. Do not let the host play on the new character yet beyond creating it. #### Restoring the host's character The common tool is the community "Palworld Host Save Fix", which uses the "palworld-save-tools" library to decode `Level.sav`, swap the host's old ID for the new one everywhere it appears, and write the save back. There are command-line and GUI versions, and forks appear when the save format changes. Use one that states support for your game version. The procedure, in the order that works: 1. With the world uploaded and running, the host joins the server and creates a new character. Any name; it is a placeholder. Then they log out. 2. Stop the server. This writes the new player's file. 3. Look in `Pal/Saved/SaveGames/0//Players/`. There is now a new file besides the ones you uploaded - the newest file by date. Its name without `.sav` is the host's **new ID**. The **old ID** is `00000000000000000000000000000001`. 4. Download the whole world folder to your PC. 5. Run the fix tool against the downloaded folder with the new ID and the old ID. The command-line form looks like this; the exact arguments vary by version, so read the tool's README: ```bash $ python fix_host_save.py "C:\palfix\4F6A2D1B8C9E4E1F9A0B3C5D7E8F1A2B" \ 9D3E0F2A000000000000000000000000 00000000000000000000000000000001 False ``` 6. Delete the server's copy of the world folder and upload the fixed one in its place. 7. Start the server. The host joins and should find their old character, items, guild and bases. The fix rewrites a large file. On a big world it takes several minutes and enough memory to hold the decoded save, which can be several gigabytes on a mature `Level.sav`. Run it on a PC with memory to spare. > [!WARNING] > Never run the fix against your only copy, and never run it twice on the same save. Keep the untouched original from the host's PC and the uploaded copy before the fix. If the result is wrong, you start again from those, not from a save that has already been partly rewritten. ##### Guild and base quirks after the fix The tools have a history of small, known issues that come and go with game versions: pals in the host's base not working until they are picked up and put back, ownership of certain containers or Viewing Cage pals not moving across, a guild that needs the host to be re-added. Some versions of the tool take a "guild fix" option for exactly this. Read the tool's list of known issues for your version before you run it, and do a quick check after: open the base, check the palbox, check the guild menu. #### If you would rather not use a tool There is a simpler option that some groups prefer. The host accepts the new character, and the group spends an evening carrying them back up. Items can be dropped from the old guild chests to the new character; pals can be handed over in the palbox if the host's new character joins the guild. The host loses their own level and technology unlocks, which is the real cost. On a world where the host played much more than anyone else, the tool is worth it. On a world everyone has played equally, starting the host over is often less work than debugging a save rewrite. If the tool cannot read your version's save yet, waiting is a legitimate third option. Upload the world, let the guests play, and have the host hold off until an updated tool appears - the old `00000000000000000000000000000001.sav` stays in the folder untouched, and the fix can be run later from a fresh backup. The only thing the host must not do in the meantime is build up the placeholder character, because the fix replaces it. #### Moving a dedicated world back to co-op The reverse trip has the mirror-image problem: in co-op the host must be `00000000000000000000000000000001`, so whoever is going to host locally loses their dedicated character unless their file is renamed and the save rewritten. The same tools can do the swap in the other direction. The rest is the same in reverse: download the world folder, put it under the host's `SaveGames\\` folder, and it appears in the world list. #### Settings after the move With `WorldOption.sav` gone, the server reads `Pal/Saved/Config/LinuxServer/PalWorldSettings.ini`. If that file is empty, the server runs on defaults, which may be quite different from what the group played with in co-op - different death penalty, different rates, a different base camp limit. Before the first evening on the server: - Copy `DefaultPalWorldSettings.ini` from the install root into `PalWorldSettings.ini` and edit it. - Match the rates and the death penalty to what the co-op world used, unless the group wants a change. - Check `BaseCampMaxNumInGuild` and `BaseCampWorkerMaxNum`. If the co-op world had more base camps than the server allows, the existing ones remain, but nobody can build new ones. The memory side of those limits is in [Palworld server memory](https://www.renode.space/blog/palworld-server-memory). - Remember that `OptionSettings=(...)` must be on one line. A server also needs an admin password before you need one. [Palworld admin commands and RCON](https://www.renode.space/blog/palworld-admin-commands-and-rcon) covers it. #### Doing this on RE:NODE On RE:NODE, a Palworld server starts from 8 GB of memory, which is the minimum a moved co-op world with established bases needs to stay comfortable. Upload the world folder through the file manager - folder upload is supported - or over SFTP for a large save; edit `GameUserSettings.ini` and `PalWorldSettings.ini` in the in-browser editor; and watch the load in the live console. Take a backup from the Backups tab before uploading and another after the host fix, so each stage has a restore point. Backup slots are on every plan and restoring is a single button. #### Troubleshooting a transfer **The server made a new world instead of loading mine.** `DedicatedServerName` does not match the folder name, or the folder is nested one level too deep (`SaveGames/0///`). Fix the path or the name and restart. Your world is still there. **My server settings are ignored.** `WorldOption.sav` is still in the world folder. Delete it with the server stopped. **Guests also have new characters.** The guests are joining from a different platform account than they used in co-op, or the world was loaded on an older server that did not read their files. Check versions. **The fix tool fails to read the save.** The tool does not support your game version's save format. Find an updated version or fork, and do not hand-edit anything. **The host has their character but their pals do not work.** A known tool quirk; pick the pals up into the palbox and place them again, or rerun from the original save with the guild fix option. **The world loads but takes minutes.** A large `Level.sav`. That is normal for a mature world and improves only by trimming the world, not by tuning - see [Palworld backups and world reset](https://www.renode.space/blog/palworld-server-backups-and-world-reset). #### FAQ ##### Do guests lose their characters when moving a Palworld world to a server? No. Guests are saved under an ID derived from their account in co-op as well, so their files work on the dedicated server unchanged. Only the host is saved under a placeholder ID. ##### Where is the Palworld co-op save folder? On a Steam copy on Windows, under `%LOCALAPPDATA%\Pal\Saved\SaveGames\`, then the host's SteamID64, then one folder per world with a 32-character hex name. ##### Why should I delete WorldOption.sav? It stores the settings the world was created with in co-op. While it exists, those settings can take priority over the server's `PalWorldSettings.ini`, so your server configuration appears to do nothing. ##### Can I merge two co-op worlds into one server? No. A world is one `Level.sav`. You can run one or the other, and characters cannot be carried between worlds with the normal tools. ##### Will the host save fix work after a game update? Only if the tool has been updated for the new save format. Check the tool's page before a transfer, and keep your untouched original save until the host has played on the fixed one for a while. Palworld servers on RE:NODE start from 8 GB with both ports allocated and an admin password generated for you. Upload a co-op world through the file manager or SFTP, and take a backup at each step - slots are on every plan and restoring is one button. [See Palworld plans](https://www.renode.space/game-servers/palworld) --- ### Palworld server backups and world resets Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/palworld-server-backups-and-world-reset A Palworld server's whole world is one folder: `Pal/Saved/SaveGames/0//`. Back that folder up - after a forced save or with the server stopped - together with `Pal/Saved/Config/LinuxServer/` and the ban list, and you can rebuild the server from nothing. Restoring is the same copy in reverse with the server stopped. Resetting the world is either deleting that folder (everyone starts over) or pointing the server at a new one (the old world stays on disk). The game's own `bIsUseBackupSaveData` copies are useful but sit on the same disk as the save, so they are not backups in the sense that matters. The rest of this post is the detail: what each file holds, how to get a consistent copy from a running server, how to restore, and how to reset without throwing away things you wanted to keep. #### What is in a Palworld world folder The dedicated server keeps each world in its own folder under `Pal/Saved/SaveGames/0/`, named with a 32-character hex ID. The server loads the one named in `GameUserSettings.ini` as `DedicatedServerName`. | File or folder | What it holds | Lose it and | | --- | --- | --- | | `Level.sav` | The world: every base, structure, pal, chest, guild, character's level and inventory | You have lost the world | | `LevelMeta.sav` | World name and metadata | The server rebuilds it; minor | | `Players/.sav` | Per-character data tied to each player's ID | That player starts over | | `WorldOption.sav` | Settings baked in when a world is created in co-op | Usually nothing - you should delete it on a server anyway | | `backup/` | The game's rolling backup copies | Nothing, unless you needed them | Outside the world folder there are three more things worth keeping: - `Pal/Saved/Config/LinuxServer/PalWorldSettings.ini` - all your game settings. (`WindowsServer` instead of `LinuxServer` on Windows.) - `Pal/Saved/Config/LinuxServer/GameUserSettings.ini` - which world to load. - `Pal/Saved/SaveGames/banlist.txt` - the server's ban list, if you have banned anyone. `Level.sav` is the important one and the fragile one. It is a single compressed file that holds almost everything, which makes the world easy to copy and makes corruption total: there is no recovering half of a damaged `Level.sav`. That one property drives every recommendation below. [Palworld server memory](https://www.renode.space/blog/palworld-server-memory) explains why the same file grows over a server's life. #### Getting a consistent copy Palworld writes the world on a timer set by `AutoSaveSpan` in `PalWorldSettings.ini`. Between saves, recent changes exist only in memory. A copy taken while the server is running is the state at the last save, and a copy taken during a save can catch a half-written file. Two ways to get a good one: **Stop the server, then copy.** The simplest and safest. A clean stop writes the world before exit, so the files on disk are complete and current. For a nightly backup at an hour nobody plays, this is the right method. **Force a save, wait, then copy.** When you cannot stop the server, issue a save first and give it time to finish. In game or over RCON the command is `Save`; over the REST API it is a POST to `/v1/api/save`: ```bash $ curl -X POST -u admin:YOUR_ADMIN_PASSWORD http://203.0.113.10:8212/v1/api/save ``` The REST API needs `RESTAPIEnabled=True` and listens on `RESTAPIPort`, `8212` by default; the username is `admin` and the password is your `AdminPassword`. On a large world the save takes several seconds, so wait at least thirty before the copy starts. [Palworld admin commands and RCON](https://www.renode.space/blog/palworld-admin-commands-and-rcon) covers both interfaces. > [!WARNING] > Never copy over or restore into a world folder while the server is running. Palworld writes the world from memory on its next save and will overwrite whatever you put there - or you will restore a file that is then replaced by the version you were trying to get rid of. #### The built-in backups: what bIsUseBackupSaveData does `bIsUseBackupSaveData=True` in `PalWorldSettings.ini` makes the server keep rolling copies of the world in the `backup` folder inside the world folder, with timestamped subfolders. How many it keeps and how often it makes them has changed between game versions, so look in the folder on your own server rather than relying on a number from a guide. These copies are worth having on. They are the quickest way to undo a corrupt save or a bad evening - a griefer, an accidental release of a whole palbox, a base lost to a raid nobody wanted - because the file is already on the server and restoring is a copy within one folder. They are not a backup, for the reasons [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) goes through in general: - They live on the same disk as the thing they protect. A failed disk, a deleted server or a mistake with the file manager takes them too. - They rotate. A problem you notice after a few days may already have been copied over every one of them. - They are as old as the rotation, which may be minutes, not the day before an update when you actually want to go back. Use them as the first line of defence and keep real backups somewhere else. #### A backup routine that holds up A sensible routine for a group server: 1. **A daily backup at an hour nobody plays.** Stop or save first, then back up the world folder, the config folder and the ban list. 2. **A manual backup before every game update.** Palworld updates have changed the save format more than once. If an update goes wrong, you want the save from before it, with a server version that can still read it. 3. **A manual backup before any big change** - new mods, a settings overhaul, a host save fix, a world move. 4. **Keep at least a week.** Problems are not always noticed the same day. 5. **Restore one occasionally.** On a spare server, or locally. A backup nobody has restored is a hypothesis. On a panel, this is a schedule rather than a chore. On RE:NODE, the Schedules tab takes a cron expression and runs ordered tasks with delays - a console command, a backup, a power action - so the daily routine can be "broadcast a warning, wait, `Save`, wait, back up, restart". Backups are stored off the machine they protect, restore with one button, can be downloaded, and can be locked so rotation never deletes the one taken before a big update. [Scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) has more examples. ```text Schedule: nightly backup and restart cron: 0 5 * * * 1. command Broadcast Restart_in_5_minutes 2. wait 240 s 3. command Save 4. wait 60 s 5. backup 6. power restart ``` Older builds of the dedicated server treated spaces in `Broadcast` messages badly, which is why underscores are common in examples. Current builds handle spaces better; test on yours. #### Restoring a world Whether the copy comes from your own backup or from the game's `backup` folder, the procedure is the same. 1. **Stop the server.** Not restart - stop, and wait until it is fully down. 2. **Move the current world folder aside** instead of deleting it. Rename it to `.broken` or download it. If the restore turns out to be the wrong one, you still have what you started with. 3. **Put the backup in place** as `Pal/Saved/SaveGames/0//`, with the same folder name `DedicatedServerName` points to. 4. **From the game's own backups**, copy the contents of the timestamped subfolder (`Level.sav` and the rest) into the world folder over the current files. 5. **Start the server** and check the console. Then join and look at something recent you remember, to confirm you are where you think you are. If a restore loads but players are missing their characters, their `Players/*.sav` files did not come with it; restore the whole folder rather than `Level.sav` alone. If the server generates a new world, the folder name or `DedicatedServerName` does not match. > [!TIP] > When restoring after a game update went wrong, restore the save and roll the server back to the previous build, or wait for a fix. A new server will often refuse an old save less often than an old server refuses a new one, but a save written by the new build may not load on the old one at all. #### Resetting the world completely Every long-running server eventually wants a fresh start - the world is explored, the save is huge, the group is bored, or a new update added a region you want to experience from the beginning. There are two clean ways to reset. **Delete the world.** Stop the server, back up the world folder (you will want it later, if only for nostalgia), delete it, and start. With `DedicatedServerName` pointing at a folder that no longer exists, or emptied, the server creates a new world with a new ID. Check `GameUserSettings.ini` after the first start; the server writes the new ID there. **Keep the old world and switch.** Stop the server, clear `DedicatedServerName` or set it to something that does not exist, and start. A new world is generated and the old one sits untouched in its folder. To switch back later, put its ID back. This is the better option on a server with enough disk, because it makes a reset reversible for as long as you keep the folder. What a full reset keeps and loses: | Kept | Lost | | --- | --- | | `PalWorldSettings.ini` - all rates and rules | Every character, level and technology unlock | | The ban list | Every pal, base and item | | Admin password, RCON and REST settings | Guilds | | Server name and port allocation | The map exploration | There is no supported way to carry characters into a new world. Character level, inventory and pals live in `Level.sav`, not only in the per-player files, so copying `Players/` into a new world does not bring anyone's progress along. Tell players that before the reset, not after. #### Partial resets Sometimes the problem is one guild, one player or one abandoned base, not the world. Palworld's tools for partial resets are limited, so pick the right one. - **Abandoned guilds.** `AutoResetGuildNoOnlinePlayers=True` with `AutoResetGuildTimeNoOnlinePlayers` in hours makes the server delete the bases of guilds with nobody online for that long. It is the cleanest way to keep a public server's save from filling with bases nobody will return to. Choose a generous time - a week rather than three days - and announce it. - **One player starting over.** Deleting that player's `Players/.sav` with the server stopped resets them to character creation. Their guild's bases remain; items and pals that belonged to them may be left in odd states. Back up first. - **Clearing ground clutter.** Lower `DropItemMaxNum` and `DropItemAliveMaxHours` so dropped items expire sooner. It does not reset anything, but it removes one source of slow decline. - **A soft reset of one area.** Not possible with vanilla tools. Save editors exist, but editing `Level.sav` by hand is the fastest way to corrupt it; do it only on a copy and only if you have a tested backup. #### Planning resets on a public server On a server with a regular community, a reset is an event rather than an accident. A few things make it go well: - **Announce it at least a week ahead,** with the date and time, and post it where people will see it. [Announcing maintenance and downtime](https://www.renode.space/blog/announcing-maintenance-and-downtime) covers the wording. - **Tie resets to big updates** when you can. A major content update is the moment most players want a fresh start anyway. - **Keep the old world folder** for a while after a reset, for appeals ("I had a legendary pal in my palbox") and for the inevitable "can we go back". - **Change settings at the reset, not between resets.** Rate changes on a live world make earlier progress look cheap or wasted; a reset is the clean point to adjust. #### Troubleshooting **The restore loaded the wrong world.** `DedicatedServerName` points at a different folder. Check `GameUserSettings.ini` and the folder name. **Restored, and the world is back to how it was before the restore.** The server was running when you copied the files, and its next save overwrote them. Stop, restore again, then start. **The server will not load the backup after an update.** The save format changed and the backup predates it, or the server is older than the save. Match the server version to the save. **Backups are huge.** `Level.sav` has grown and the game's `backup` folder holds several copies of it. Exclude `backup/` from your own backups if space is tight; your backups replace it. **A reset kept the old world.** The server loaded it because `DedicatedServerName` still names its folder. Clear the value or move the folder. **Players lost characters after a restore but bases are there.** Only `Level.sav` was restored. Restore the `Players` folder from the same backup. #### FAQ ##### Where are Palworld server save files? In `Pal/Saved/SaveGames/0//` inside the server install, one folder per world. `Level.sav` in that folder is the world itself; `Players/` holds one file per character. ##### Does Palworld back up automatically? With `bIsUseBackupSaveData=True`, the server keeps rolling copies in a `backup` folder inside the world folder. They protect against a bad save but sit on the same disk, so keep separate backups too. ##### Can I reset the world but keep everyone's characters? Not with supported tools. Character progress is stored in `Level.sav` along with the world. A new world means everyone starts at level one. ##### How do I reset just one player? Stop the server and delete that player's file from `Players/`. They will create a new character on next join. Back up first, because their items and pals can end up in an inconsistent state. ##### How often should I back up a Palworld server? Daily at a quiet hour, plus before every game update and every major change. Keep at least a week of backups, because problems are not always noticed the same day. Palworld servers on RE:NODE come with backup slots on every plan, stored off the machine they protect, restorable with one button and lockable against rotation. The Schedules tab runs the save, backup and restart routine on a cron expression, so the nightly backup happens without anyone remembering. [See Palworld plans](https://www.renode.space/game-servers/palworld) --- ### Palworld admin commands, RCON and REST API Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/palworld-admin-commands-and-rcon Administering a Palworld dedicated server comes down to one password and three ways of using it. Set `AdminPassword` in `PalWorldSettings.ini`, and you can type `/AdminPassword ` in the in-game chat to unlock the command set, connect a Source RCON client to port `25575`, or make HTTP calls against the REST API on port `8212`. The command list is short - about a dozen entries, no cheat commands, no item spawning - but it covers announcements, kicks, bans, teleports, forced saves and a countdown shutdown, which is everything an automated restart script needs. This post covers all three routes, the player ID formats that decide whether a kick works, and the quirks that make Palworld's RCON different from every other game's. #### Setting the admin password One line in the config, with the server stopped: PalWorldSettings.ini: ```ini OptionSettings=(...,AdminPassword="7Tz-quay-brindle",ServerPassword="...",...) ``` Three rules for the value. It must not contain a comma, a closing bracket or a double quote, because the whole config is one comma-separated tuple inside brackets and those characters end it early. It must not be the same as `ServerPassword`, which is the join password that every player knows. And it is stored in plain text in a file that anyone with file access can read, so treat file-manager and SFTP access as admin access - [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege) is the shape of that problem on a panel. The rest of the config file is covered key by key in [Palworld server settings](https://www.renode.space/blog/palworld-server-settings-guide). To use it in game, press `Enter` to open chat and send: ```text /AdminPassword 7Tz-quay-brindle ``` The server replies that you are now an admin. That state lasts for the session and is lost when you disconnect. There is no admin list, no per-player admin flag and no way to grant one person admin without handing them the password. If somebody leaves the group, change the password and restart. ```diagram title: Three ways into the same command set chat = In-game chat | /AdminPassword rcon = RCON client | TCP 25575 rest = REST API | TCP 8212 auth = AdminPassword | one shared secret server = Palworld server | the command handler chat -> auth rcon -> auth rest -> auth auth -> server ``` #### The command list In chat every command is prefixed with `/`. Over RCON and in most panel consoles you send the same word without the slash. The list is short and deliberately so. | Command | What it does | | --- | --- | | `Info` | Server version and name | | `ShowPlayers` | CSV of everyone connected, with their IDs | | `Save` | Writes the world to disk now | | `Broadcast ` | Message to every connected player | | `KickPlayer ` | Disconnects a player | | `BanPlayer ` | Disconnects and adds to the ban list | | `UnBanPlayer ` | Removes a ban (newer builds only) | | `TeleportToPlayer ` | Teleports you to them | | `TeleportToMe ` | Teleports them to you | | `Shutdown ` | Countdown, announcement, clean stop | | `DoExit` | Stops the process immediately | That is the whole thing. There is no command to spawn an item, change the weather, set the time, promote a player or edit a guild. Anything beyond the list above needs a server-side mod, and Palworld's modding scene is much thinner than Valheim's or Minecraft's, so plan around the built-in set rather than assuming a plugin exists. Two of them deserve attention. `Shutdown 60 "Restarting for the weekly update"` is the one you build automation on: it warns everyone, waits, saves and exits cleanly. `DoExit` does none of that, and on a game that writes a large world file continuously it is how you end up with a truncated save. Use `Save`, then `Shutdown`, and keep `DoExit` for a server that has stopped responding. `Broadcast` has a long-standing quirk: in several builds it treats the message as a single token and drops everything after the first space when sent over RCON. If your announcements arrive as one word, substitute underscores for spaces as a workaround, or send the message through the REST API's announce endpoint instead, which does not have the problem. #### Player IDs, and why your kick did nothing `ShowPlayers` returns comma-separated text with a header row: ```text name,playeruid,steamid Odin,1234567890,76561198012345678 Freyja,0987654321,76561198087654321 ``` Those are two different identifiers. The `playeruid` is the game's internal handle and changes meaning between builds; the `steamid` is the 17-digit SteamID64 that everything else in the Steam ecosystem uses. Current builds expect the platform-prefixed form for kicks and bans: ```text BanPlayer steam_76561198012345678 KickPlayer steam_76561198012345678 ``` Passing a bare SteamID64, or the `playeruid`, is the most common reason a ban appears to succeed and the player walks straight back in. If the command returns nothing at all, that is also usually the ID format rather than a permissions problem. Copy the value out of `ShowPlayers` rather than asking the player for it, because a name with a comma or a non-Latin character in it will not survive the CSV either. > [!TIP] > Run `ShowPlayers` and paste the output somewhere before you kick anyone. Once they are disconnected you cannot look their ID up again from the server, and the ban you wanted to apply five minutes later needs it. #### Turning on RCON RCON is the Source protocol: a TCP connection, one password, plain text both ways. Two keys switch it on, and the admin password is the RCON password. ```ini OptionSettings=(...,RCONEnabled=True,RCONPort=25575,AdminPassword="...",...) ``` Restart, then talk to it. Any Source RCON client works. `mcrcon` and `gorcon`'s `rcon-cli` are the two usually reached for: ```bash $ rcon-cli --address 203.0.113.10:25575 --password '7Tz-quay-brindle' "ShowPlayers" $ mcrcon -H 203.0.113.10 -P 25575 -p '7Tz-quay-brindle' "Save" "Info" $ rcon-cli -a 203.0.113.10:25575 -p '7Tz-quay-brindle' \ "Broadcast Server_restarts_in_five_minutes" ``` Palworld's implementation is not quite standard, and it is worth knowing which oddities are yours and which are the game's: - Replies can arrive one packet behind, so a client may print the previous command's answer. Clients written for Minecraft usually cope; very simple ones do not. - Non-ASCII player names come back mangled in some builds, because the response is not encoded the way the protocol expects. It affects display, not the command. - `Shutdown` may not return a reply at all, since the server is on its way out. A client that waits for one will appear to hang. That is expected. There is one more thing that surprises people arriving from other games: **Palworld does not read commands from standard input.** Typing `ShowPlayers` into a panel console does nothing on its own, because the game never looks there. Some panel images bridge the console to RCON so it appears to work; if yours does not, RCON or the REST API is the only route. That also means an automated "send this console command" task is really an RCON call under the hood. RCON has no encryption and no per-user accounts, so it should never be reachable from the open internet. Bind it behind a firewall rule, or reach it through an SSH tunnel from the machine you administer from. [RCON safely](https://www.renode.space/blog/rcon-safely) covers the minimum, and [firewall rules that matter](https://www.renode.space/blog/firewall-rules-that-matter) covers the rule itself. On a panel you control which ports exist on the Network tab, and RCON is one of the allocations rather than something you can quietly forget about. #### The REST API Newer builds ship an HTTP admin API, which is easier to automate against than RCON and does not have the broadcast quirk. Two keys: ```ini OptionSettings=(...,RESTAPIEnabled=True,RESTAPIPort=8212,AdminPassword="...",...) ``` Authentication is HTTP Basic with the username `admin` and the admin password as the password. The endpoints live under `/v1/api/`: | Method | Path | Purpose | | --- | --- | --- | | `GET` | `/v1/api/info` | Version, server name | | `GET` | `/v1/api/players` | Connected players with IDs and ping | | `GET` | `/v1/api/settings` | The active settings, as the server parsed them | | `GET` | `/v1/api/metrics` | Server FPS, frame time, player count, uptime | | `POST` | `/v1/api/announce` | Broadcast a message | | `POST` | `/v1/api/kick` | Kick by user ID | | `POST` | `/v1/api/ban` | Ban by user ID | | `POST` | `/v1/api/unban` | Lift a ban | | `POST` | `/v1/api/save` | Force a save | | `POST` | `/v1/api/shutdown` | Countdown shutdown with a message | | `POST` | `/v1/api/stop` | Stop now | ```bash $ curl -u admin:'7Tz-quay-brindle' http://203.0.113.10:8212/v1/api/metrics $ curl -u admin:'7Tz-quay-brindle' -H 'Content-Type: application/json' \ -d '{"message":"Restarting in 5 minutes"}' \ http://203.0.113.10:8212/v1/api/announce $ curl -u admin:'7Tz-quay-brindle' -H 'Content-Type: application/json' \ -d '{"userid":"steam_76561198012345678","message":"Griefing"}' \ http://203.0.113.10:8212/v1/api/ban ``` `GET /v1/api/settings` is the most useful call on the list and almost nobody uses it. It returns the settings **as the server parsed them**, which is the one reliable way to find out that your config file has a syntax error and every rate quietly reverted to `1.0`. Diff it against what you think you wrote after any config change. `GET /v1/api/metrics` returns the server's frame rate and frame time alongside the player count. A healthy Palworld server sits at its target frame rate; a number that sags in the evening while memory climbs is the signal described in [why your Palworld server needs more memory than you think](https://www.renode.space/blog/palworld-server-memory), and it is a better early warning than waiting for players to complain about rubber-banding. > [!WARNING] > The REST API is plain HTTP with Basic authentication, which means the admin password crosses the network in near-plaintext on every call. Do not expose port `8212` to the internet. Keep it on a private interface, or tunnel it. #### Bans, the ban list and the global list A ban is written to a plain text file next to the saves: ```text Pal/Saved/SaveGames/banlist.txt ``` One entry per line, in the same prefixed form the commands take. You can edit it by hand with the server stopped, which is how you unban someone on a build that has no `UnBanPlayer`, and how you seed a new server with an existing list. Edits made while the server is running are liable to be overwritten, because the server rewrites the file when it bans someone. There is also a network-wide list. `BanListURL` defaults to Pocketpair's published ban list, and the server fetches it at startup. Two practical consequences: your server inherits bans it did not make, and if the URL is unreachable the server logs a failure and carries on. You can point `BanListURL` at a plain text list you host yourself, in the same format, to share one ban list across several servers - useful if you run more than one and want a griefer gone from both. Bans are by platform account, not by address. Someone with a second Steam account is not stopped by a ban, and nothing in the base game does IP bans. If a server is being targeted, `ServerPassword` is a more effective tool than the ban list. #### Automating the boring parts Everything worth automating on a Palworld server is a `Save`, a warning, and a `Shutdown`. A restart every night keeps memory flat, and the announcement is what stops people losing a base assault to it. ```bash # 23:55 - five minute warning, save, then a clean countdown shutdown $ rcon-cli -a 127.0.0.1:25575 -p "$RCON_PASS" "Broadcast Nightly_restart_in_5_minutes" $ sleep 240 $ rcon-cli -a 127.0.0.1:25575 -p "$RCON_PASS" "Save" $ rcon-cli -a 127.0.0.1:25575 -p "$RCON_PASS" "Shutdown 60 Nightly_restart" ``` Keep the password in an environment variable rather than in the script - [environment variables and secrets](https://www.renode.space/blog/environment-variables-and-secrets) explains why that is not just tidiness. If you are writing the cron line yourself, [cron expressions explained](https://www.renode.space/blog/cron-expressions-explained) has the five fields; on a panel, the Schedules tab takes the same expression and runs ordered tasks with delays between them, so the warning, the save and the power action become three steps of one schedule. [Scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) lists the handful that are actually worth the trouble. One thing not to automate: a restart on a timer with no player check. A countdown shutdown at 23:00 lands in the middle of somebody's evening at least once a month. Either pick an hour nobody plays, or drive the restart from the player count that `/v1/api/metrics` gives you. #### Troubleshooting **RCON refuses the password.** The password in the ini contains a comma, a bracket or a quote and the config parser stopped early, so the server is running with an empty admin password. Check `GET /v1/api/settings`, or look at the config again. **RCON connects, commands return nothing.** Usually the off-by-one reply behaviour. Send the command twice and see whether the first answer arrives on the second call; if so, it is the client, not the server. **The port is open but nothing answers.** `RCONEnabled=True` only takes effect after a restart, and it is a TCP port while the game port is UDP, so a firewall rule copied from the game port will not cover it. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) has the general shape of this mistake. **A banned player keeps coming back.** Wrong ID form, a second account, or the ban list being rewritten under you. Check `banlist.txt` after the ban and confirm the line is there in `steam_` form. **`/AdminPassword` says nothing in chat.** The password does not match, or you are on a build where the chat reply is suppressed. Try `/Info` straight after: if you get a version string back, you are an admin. **Shutdown warnings never reach players.** The broadcast-splits-on-spaces bug. Use underscores, or the REST announce endpoint. #### FAQ ##### Do Palworld admin commands work in co-op? No. The command set exists on the dedicated server only. A world hosted from inside the game has no admin password, no RCON and no REST API, which is one of the better reasons to move a group's world onto a dedicated server. ##### Can I give someone admin rights without sharing the password? Not in the base game. There is one shared `AdminPassword` and no per-player admin list, so the practical approach is to keep the password to one or two people and give everybody else what they actually need: a panel subuser account with console access and nothing else. ##### What is the difference between Shutdown and DoExit? `Shutdown` takes a countdown in seconds and a message, announces it, saves and exits cleanly. `DoExit` ends the process immediately with no warning and no guaranteed save. Use `DoExit` only when the server has stopped responding to anything else. ##### Is RCON or the REST API the better choice? The REST API, when your build has it. It returns structured JSON, it has a working announce endpoint, and `/v1/api/settings` and `/v1/api/metrics` have no RCON equivalent. RCON is worth enabling as well because more existing tools speak it. ##### How do I find a player's SteamID64? Run `ShowPlayers` while they are connected and take the third column. Do not ask them for it: the number shown on a Steam profile page is the same value, but people paste the vanity URL or the 32-bit form instead, and neither works. ##### Does enabling RCON slow the server down? No. It is an idle TCP listener that does nothing until a client connects. The cost of enabling it is the security exposure, not the performance, which is why the answer is to enable it and firewall it rather than to leave it off. Every Palworld plan on RE:NODE comes with an admin password generated per server, two port allocations so RCON has somewhere to live, and a Schedules tab that will run the nightly save-warn-restart sequence on a cron expression. The console shows the server's unfiltered output, which is where the ID formats and the parse errors actually appear. [See Palworld plans](https://www.renode.space/game-servers/palworld) --- ### Palworld server settings: PalWorldSettings.ini Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/palworld-server-settings-guide 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. ```text /DefaultPalWorldSettings.ini <- template, read-only reference /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](https://www.renode.space/blog/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: ```bash $ ./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. PalWorldSettings.ini: ```ini [/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. ```diagram title: Which settings the server actually uses default = DefaultPalWorldSettings | template in the root ini = PalWorldSettings.ini | LinuxServer config folder args = Launch arguments | -port, -players world = WorldOption.sav | inside an imported save server = Running server | the values in play default --> ini : you copy it once ini -> server args -> server : wins over the file world -> server : wins over everything ``` #### Server name, passwords and ports These are the keys you set before anyone connects. | Key | Default | What it does | | --- | --- | --- | | `ServerName` | `Default Palworld Server` | Shown in the community list | | `ServerDescription` | empty | Free text under the name | | `ServerPassword` | empty | Join password. Empty means anyone can walk in | | `AdminPassword` | empty | Required for admin commands, RCON and the REST API | | `PublicIP` | empty | Only set this if the server advertises the wrong address | | `PublicPort` | `8211` | The port advertised to the list | | `ServerPlayerMaxNum` | `32` | Hard cap on connected players | | `CoopPlayerMaxNum` | `4` | Co-op only. Does nothing on a dedicated server | | `bUseAuth` | `True` | Platform authentication. Leave it on | | `Region` | empty | Region tag for the community list | | `RCONEnabled` | `False` | Source RCON, on `RCONPort` | | `RCONPort` | `25575` | TCP | | `RESTAPIEnabled` | `False` | HTTP admin API | | `RESTAPIPort` | `8212` | TCP | | `BanListURL` | Pocketpair's list | The global ban list the server pulls at start | `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: | Port | Protocol | Purpose | | --- | --- | --- | | `8211` | UDP | Game traffic. The only one players need | | `27015` | UDP | Steam query, set with `-queryport` | | `25575` | TCP | RCON, only when you enable it | | `8212` | TCP | REST API, only when you enable it | 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](https://www.renode.space/blog/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](https://www.renode.space/blog/palworld-admin-commands-and-rcon). > [!WARNING] > `AdminPassword` is stored in plain text in a file that anyone with file access on the server can read. Give subusers file access deliberately, not by default, and use a password you have not used anywhere else. #### 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`. | Key | Default | What it changes | | --- | --- | --- | | `DayTimeSpeedRate` | `1.0` | Higher makes daylight pass faster | | `NightTimeSpeedRate` | `1.0` | Set to `2.0` if your group hates the dark | | `ExpRate` | `1.0` | `1.5` to `2.0` suits a group that plays a few evenings a week | | `PalCaptureRate` | `1.0` | Chance of a sphere landing | | `PalSpawnNumRate` | `1.0` | Wild pal density. Also a performance lever | | `WorkSpeedRate` | `1.0` | How fast base pals work | | `CollectionDropRate` | `1.0` | Yield from ore, trees and stone | | `CollectionObjectHpRate` | `1.0` | Hits needed to break a node | | `CollectionObjectRespawnSpeedRate` | `1.0` | Node respawn timing | | `EnemyDropItemRate` | `1.0` | Loot from defeated pals and humans | | `PalEggDefaultHatchingTime` | `72` | Hours, not a multiplier. `1` is the usual change | 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: | Key | Default | What it changes | | --- | --- | --- | | `PlayerDamageRateAttack` | `1.0` | Damage you deal | | `PlayerDamageRateDefense` | `1.0` | Damage you take | | `PalDamageRateAttack` | `1.0` | Damage your pals deal | | `PalDamageRateDefense` | `1.0` | Damage your pals take | | `PlayerStomachDecreaceRate` | `1.0` | Hunger speed. Lower is kinder | | `PlayerStaminaDecreaceRate` | `1.0` | Stamina drain | | `PlayerAutoHPRegeneRate` | `1.0` | Passive healing | | `PlayerAutoHpRegeneRateInSleep` | `1.0` | Healing in a bed | | `PalStomachDecreaceRate` | `1.0` | How fast base pals get hungry | | `PalAutoHPRegeneRate` | `1.0` | Pal passive healing | | `BuildObjectDamageRate` | `1.0` | Damage structures take | | `BuildObjectDeteriorationDamageRate` | `1.0` | Decay. `0` switches decay off | `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 | Key | Default | Notes | | --- | --- | --- | | `DeathPenalty` | `All` | `None`, `Item`, `ItemAndEquipment`, `All` | | `bEnablePlayerToPlayerDamage` | `False` | Players can hurt each other | | `bEnableFriendlyFire` | `False` | Damage within a guild | | `bIsPvP` | `False` | PvP mode | | `bCanPickupOtherGuildDeathPenaltyDrop` | `False` | Loot other guilds' death bags | | `bEnableDefenseOtherGuildPlayer` | `False` | Base defence fires on outsiders | | `bEnableInvaderEnemy` | `True` | Raids on your base | | `bEnableNonLoginPenalty` | `True` | Penalty applied to offline players | | `bEnableFastTravel` | `True` | Fast travel points | | `bIsStartLocationSelectByMap` | `True` | Pick your spawn on the map | | `bExistPlayerAfterLogout` | `False` | Your body stays in the world after logout | | `GuildPlayerMaxNum` | `20` | Members per guild | | `bAutoResetGuildNoOnlinePlayers` | `False` | Delete guilds that go quiet | | `AutoResetGuildTimeNoOnlinePlayers` | `72` | Hours before that happens | | `bActiveUNKO` | `False` | Pals produce droppings | `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](https://www.renode.space/blog/palworld-server-memory). Four of these keys decide how many things there are. | Key | Default | Effect on load | | --- | --- | --- | | `BaseCampMaxNum` | `128` | Total base camps on the server | | `BaseCampWorkerMaxNum` | `15` | Pals working per base | | `PalSpawnNumRate` | `1.0` | Wild pals alive in the world | | `DropItemMaxNum` | `3000` | Dropped items tracked at once | | `DropItemMaxNum_UNKO` | `100` | Droppings tracked at once | | `DropItemAliveMaxHours` | `1.0` | Hours before a dropped item vanishes | | `SupplyDropSpan` | `180` | Minutes between supply drops | | `ChatPostLimitPerMinute` | `10` | Chat rate limit | | `bIsUseBackupSaveData` | `True` | Keep rolling copies of the save | | `LogFormatType` | `Text` | `Text` or `Json` | 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](https://www.renode.space/blog/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](https://www.renode.space/blog/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: ```text Pal/Saved/SaveGames/0// 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/.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 `` 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/.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](https://www.renode.space/blog/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 `` 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](https://www.renode.space/blog/rcon-safely) sets out the minimum. Palworld plans on RE:NODE start at 8 GB because that is where the game becomes honest, with two port allocations, an admin password generated per server, and backup slots on every tier. The file manager opens `PalWorldSettings.ini` in a syntax-highlighting editor, which is the cheapest insurance against a missing bracket. [See Palworld plans](https://www.renode.space/game-servers/palworld) --- ### Palworld server memory: how much RAM Published 2026-06-30, updated 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/palworld-server-memory Most game servers scale with players. Palworld scales with pals. Every creature on every base, working or idle, captured or stored, is simulated whether or not anybody is standing near it - which is why a four-player Palworld server can use more memory than a twenty-player Minecraft one, and why sizing it by player count gives the wrong answer every time. The short version: **8 GB is the honest floor** for a small group past its first few hours, 10-12 GB covers a developed server for four to eight people, and a full lobby with mature bases wants 14 GB or more. Below 8 GB a Palworld server does not run badly. It runs fine for an evening and then stops, which is worse, because it looks like something else broke. #### Why Palworld scales with pals, not players Palworld's dedicated server is an Unreal Engine 5 build that keeps the whole inhabited world resident. There is no meaningful equivalent of Minecraft's chunk unloading for the things that matter: a base camp with fifteen pals working continuously is fifteen active AI agents with inventories, stamina, sanity, work assignments and pathfinding, and they keep being all of that while their owner is asleep, offline, or has not logged in for a fortnight. Ranked by what they actually cost: - **Base pals.** The largest term. Each guild can hold several base camps, each camp holds a worker roster, and every one of those pals is simulated for production, hunger and condition around the clock. - **The pal box.** Stored pals are not free. The box holds everything a player has ever caught rather than the working subset, and players do not delete anything. - **Structures.** Every wall, conveyor, chest and production building is an object with state. Large bases cost more than their footprint suggests, because production chains tick. - **Dropped items.** A surprisingly large term on a busy server. Items on the ground persist until they expire, and the cap is in the thousands by default. - **Players.** The smallest term in the equation, by a wide margin. > If your server slows down over weeks rather than minutes, look at how many pals exist, not at how many people are online. This also explains the shape of the problem over time. A fresh world is cheap. The same world after a month of four people playing seriously - three guilds, a dozen base camps, several hundred stored pals - is a different server with the same name, and it needs more memory than it did on day one without a single extra player having joined. #### How much memory a Palworld server actually needs | Server | RAM | vCPU | Notes | | --- | --- | --- | --- | | 2-4 players, first week | 8 GB | 2 | Comfortable while bases are small | | 4-8 players, developed bases | 10-12 GB | 2-3 | The common long-running case | | 8-16 players, several guilds | 12-16 GB | 3+ | Base camp count matters more than head count | | 20-32 players | 16 GB and up | 4+ | Beyond what a shared game plan is built for | Two calibration points for that table. Pocketpair's own dedicated server guidance asks for considerably more than most hosts sell - in the region of 16 GB - which tells you the direction of travel even though 8-12 GB runs a real server perfectly well in practice. And the 32-player figure in `ServerPlayerMaxNum` is a hard cap, not a recommendation: a genuinely full 32-player world with thirty-two players' worth of bases is a dedicated machine's job, not a shared plan's. If you are heading there, [our dedicated servers](https://www.renode.space/dedicated-servers) are the honest answer rather than the top game tier. RE:NODE's Palworld plans start at 8 GB and run to 14 GB, from $19 a month, because anything below 8 GB is a server that works until it does not. Moving up a tier changes the limit on the server you already have, so the world stays where it is - [when to upgrade your plan](https://www.renode.space/blog/when-to-upgrade-your-plan) covers reading the graphs that tell you it is time. #### The settings that set your memory ceiling Palworld's configuration is one file: `Pal/Saved/Config/LinuxServer/PalWorldSettings.ini` on Linux, `WindowsServer` in place of `LinuxServer` on Windows. It is created empty on first start, and the working method is to copy the contents of `DefaultPalWorldSettings.ini` from the install root into it and edit from there. Pal/Saved/Config/LinuxServer/PalWorldSettings.ini: ```ini [/Script/Pal.PalGameWorldSettings] OptionSettings=(Difficulty=None,ServerPlayerMaxNum=16,GuildPlayerMaxNum=8, BaseCampMaxNumInGuild=3,BaseCampWorkerMaxNum=12,DropItemMaxNum=1500, DropItemAliveMaxHours=1.000000,AutoSaveSpan=180.000000, AutoResetGuildNoOnlinePlayers=True,AutoResetGuildTimeNoOnlinePlayers=168.000000, ServerName="Longship",AdminPassword="...",RCONEnabled=True,RCONPort=25575) ``` > [!WARNING] > That block is shown wrapped so it fits on the page. In the real file, `OptionSettings=(...)` must be **one single line**. A newline inside the brackets, a missing comma or a stray space is not an error - the server silently falls back to defaults for everything after the break, and you spend an evening wondering why your difficulty settings did nothing. The settings that actually change memory use, as opposed to the dozens that change game feel: | Setting | Default | Effect on memory | | --- | --- | --- | | `ServerPlayerMaxNum` | `32` | The cap, not a target. Lower it to what you will really have | | `GuildPlayerMaxNum` | `20` | Guild size; large guilds concentrate bases | | `BaseCampMaxNumInGuild` | `4` | Base camps per guild. The biggest single lever | | `BaseCampWorkerMaxNum` | `15` | Pals per camp. Multiply by the line above | | `DropItemMaxNum` | `3000` | Ground items held at once. Halving it is free performance | | `DropItemAliveMaxHours` | `1` | How long dropped items persist | | `AutoResetGuildNoOnlinePlayers` | `False` | Deletes bases of guilds nobody has logged into | | `AutoResetGuildTimeNoOnlinePlayers` | `72` | Hours before that happens | The arithmetic is worth doing once. At defaults, a guild of twenty players may hold four base camps of fifteen workers, which is sixty permanently simulated pals per guild before anybody opens their pal box. Three guilds like that is 180 pals, and that is the server, not the players. Dropping `BaseCampMaxNumInGuild` to three and `BaseCampWorkerMaxNum` to twelve takes the same three guilds to 108 - a third less work, and a change most players will not notice, because the fourth base camp is usually an abandoned one. `AutoResetGuildNoOnlinePlayers` is the setting nobody turns on and everybody should consider. A public server accumulates guilds that played for one evening in March and left behind a base camp that has been simulating ever since. Set the timer to something generous - a week rather than the default three days - and the server cleans up after people who are not coming back. On a private server for friends, leave it off and accept the cost. Note that key names and defaults have moved between builds, and later patches added server-wide caps that earlier ones did not have. `DefaultPalWorldSettings.ini` in your own install is the authoritative list for your version; a guide is not. [The Palworld settings guide](https://www.renode.space/blog/palworld-server-settings-guide) goes through the rest of the file - rates, difficulty, death penalty, breeding - which are about how the game plays rather than what it costs. #### Launch options and what they do ```bash $ ./PalServer.sh -port=8211 -queryport=27015 -players=16 \ -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS ``` Those last three arguments are the standard trio and they are worth understanding rather than copying. `-useperfthreads` and `-UseMultithreadForDS` push more of the dedicated server's work onto additional threads, and `-NoAsyncLoadingThread` moves asset loading onto the main thread instead of a background one. Together they generally improve frame pacing on a server with several cores available, which is most of them. They do not reduce memory use, and nothing on a launch line will: memory is a function of how much world exists. On a Linux install you will also meet the `steamclient.so` problem, where the server starts and immediately exits with a Steam initialisation failure: ```bash $ mkdir -p ~/.steam/sdk64 $ cp ./linux64/steamclient.so ~/.steam/sdk64/ ``` The dedicated server is app id `2394010` on SteamCMD and downloads anonymously. On a panel host both of those steps are already done and the launch arguments are fields on the Startup tab. | Port | Protocol | Purpose | | --- | --- | --- | | `8211` | UDP | Game traffic | | `27015` | UDP | Steam query, so the server appears in the list | | `25575` | TCP | RCON, when `RCONEnabled=True` | | `8212` | TCP | The REST API, when `RESTAPIEnabled=True` | RCON and the REST API are both worth enabling on a server you care about, because they are how you save, announce and kick without a client - see [Palworld admin commands and RCON](https://www.renode.space/blog/palworld-admin-commands-and-rcon). #### Saves, save bloat and the slow decline The world lives in `Pal/Saved/SaveGames/0//`. `Level.sav` is the whole world in one file and it is the one that matters: every base, every pal, every chest. `Players/` holds one small file per player, and `LevelMeta.sav` and `WorldOption.sav` hold metadata. `Level.sav` grows, and it grows faster than the world feels like it is growing, because it keeps things the world no longer shows you. A long-running server can reach hundreds of megabytes, and both startup time and resident memory scale with it. When a server that was fine in month one takes four minutes to start in month three, the save file is the reason. - **`AutoSaveSpan`** defaults to 30 seconds. On a big world, writing `Level.sav` that often produces a visible hitch every half minute. Raising it to 180 or 300 smooths play at the cost of losing up to that many seconds in a crash. On a server with frequent restarts, keep it low; on a stable one, raise it. - **`bIsUseBackupSaveData`** keeps rolling copies beside the save. They are protection against a corrupt write, not against a deleted server - they are on the same disk as the thing they protect. - **`WorldOption.sav`** is the trap when migrating a world from a co-op session. If it is present, it can override your `PalWorldSettings.ini`, which is why a migrated world ignores every setting you carefully typed. Delete it and configure the server from the ini alone. The other half of the decline is uptime. Palworld's server has grown its memory usage over long uptimes through most of its life, patch by patch getting better without ever getting fixed. A restart every twelve to twenty-four hours is normal practice and costs nothing on a game where nobody plays for twenty-four hours straight. [Restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers doing that without annoying the people who are on at the time. #### CPU, disk and the rest of the sizing picture Memory gets the attention, but it is not the only thing to get right. - **CPU.** The server has one heavy thread plus workers. Clock speed matters more than core count, but two cores is a genuine minimum and three is comfortable at sixteen players, because the threads the launch flags enable need somewhere to run. A server pinned at its CPU limit is slow, not broken - [CPU vs RAM for game servers](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) walks through telling which of the two is the actual constraint before paying for either. - **Disk.** The install is modest and the save is small next to it. What matters is that saves are frequent and large, so slow storage shows up as a stutter every `AutoSaveSpan` seconds rather than as a disk-space problem. - **Network.** Not the constraint at these player counts. Palworld's traffic per player is unremarkable; if the server feels bad, memory or CPU is why. - **Player count as a proxy.** It is a bad one. [How many players fit on a server](https://www.renode.space/blog/how-many-players-fit-on-a-server) makes the general argument; Palworld is the clearest example of it in the catalogue. #### Restarts, backups and running out of memory Running out of memory in a container does not behave the way running out of memory on a PC does. On RE:NODE, a server that reaches its limit is stopped by the kernel and restarted clean rather than being allowed to swap, which keeps the node healthy and keeps one server from dragging the others down. For Palworld that has a specific consequence: the stop is not a clean shutdown, so you lose whatever happened since the last autosave. It is one more argument for not running a mature world on the smallest plan that technically boots. The watcher that notices this is worth knowing about too. A server that goes down and comes back repeatedly raises a warning and an automatic ticket rather than quietly looping - [why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) covers reading that pattern, and [reading a server load graph](https://www.renode.space/blog/reading-a-server-load-graph) covers seeing it coming. Back the world up before every game update, and before any change to the ini that you are not sure about. Backup slots are included on every plan, backups are stored off the machine they protect, and restoring is one button. A Palworld world is one large file and one folder of small ones, which makes restoring fast and makes corruption total - there is no partial recovery of a `Level.sav`. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is the argument for testing one before you need it. #### Troubleshooting **The server stops after a few hours with nothing in the log.** Memory. A container at its limit is killed rather than warned, so the log ends mid-line. Check the memory graph for a climb that ends in a vertical drop. **Memory is at 90% and nothing is wrong.** That can be normal. What matters is the trend across days and whether it ever comes back down after a restart. A flat 90% is a plan that fits; a 90% that was 60% last week is a plan that is about to not fit. **Settings in the ini do nothing.** Either `OptionSettings` has a line break in it, or a `WorldOption.sav` is overriding it, or you edited the file in the install root instead of the one under `Pal/Saved/Config/`. In that order of likelihood. **The server takes minutes to start.** `Level.sav` has grown. Expected on a mature world; alarming on a new one, where it usually means the save is being read from slow storage. **Players can see the server but cannot join.** The query port is open and the game port is not. Both `8211` and `27015` are UDP and both are needed. **Everything stutters every thirty seconds.** `AutoSaveSpan` at its default on a world that has outgrown it. Raise it. #### FAQ ##### How much RAM does a Palworld server need? Eight gigabytes is the working floor for a small group, 10-12 GB for a developed server of four to eight players, and 14 GB or more once you have several guilds with mature bases. Below 8 GB it will start and then stop later, which is the worst failure mode. ##### Why does my server need more memory than a Minecraft server with five times the players? Because Palworld simulates pals continuously whether anyone is near them or not. Sixty working pals across a guild's base camps exist all day; sixty Minecraft mobs in unloaded chunks do not. ##### Does lowering the player limit reduce memory use? Indirectly. Fewer players eventually means fewer guilds, fewer base camps and fewer stored pals, which is where the memory goes. Lowering `ServerPlayerMaxNum` on its own changes nothing until the world is smaller as a result. ##### Will more CPU fix a Palworld server that feels laggy? Sometimes. Check which limit is being hit first. If memory is near the ceiling, more CPU changes nothing; if memory is comfortable and the CPU graph is flat at its limit, more CPU is exactly the fix. ##### Should I restart the server on a schedule? Yes. Every twelve to twenty-four hours, at an hour nobody plays. Palworld's memory use grows with uptime, and a scheduled restart keeps it flat for free. ##### Does the number of pals in the pal box matter, or only working pals? Both, though working pals cost more. Stored pals still occupy memory and are written into `Level.sav` on every save, which is part of why the save file grows and startup slows on a long-running server. Palworld plans on RE:NODE start at 8 GB rather than at a number that boots and fails later, and run to 14 GB with two port allocations, backup slots on every tier and a Schedules tab for the nightly restart. Changing tier changes the limit on the server you already have, so the world does not move. [See Palworld plans](https://www.renode.space/game-servers/palworld) ## Rules for the assistant - Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead. - Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository. - An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port. - On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker. - Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak. - Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository. - Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current. - For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one. - If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.