You can install server-side mods on a Palworld dedicated server running the Windows edition. The supported workflow is to place a compatible Workshop package in the server’s Mods/Workshop folder, confirm that its Info.json declares "IsServer": true, add the manifest’s exact PackageName to Mods/PalModSettings.ini, and restart the server. Pocketpair warns that mods can corrupt save data or crash a server, so make a separate backup of the world and configuration before changing anything.
This guide follows Pocketpair’s official server documentation (version 1.0.4, checked October 14, 2026) and explains staging, activation, verification, updates, removal and recovery. The documented server-mod procedure is for a Windows dedicated server; native Linux server installations are not covered as officially supported by that guide.
Are Palworld server mods supported on your platform?
Official server-side mod support currently applies to the Windows edition of the dedicated server. Pocketpair’s guide states that “At this time, server-side mods work only on the dedicated server with Windows edition.” You should therefore treat Linux-native dedicated-server setups, peer-hosted sessions and console worlds as outside this documented workflow rather than assuming the same files will work.
Start with the mod’s manifest, not its download-page title. A package intended for a client only can load incorrectly or do nothing on a dedicated server. Open its Info.json and look for a server installation rule containing "IsServer": true. Check the same manifest or the author’s notes for prerequisites, supported game/server revisions, package version and any client files players must install.
The server and the players do not always need identical files. Some packages change only server logic; others require every player to install a matching client component. The package author’s instructions and your host’s file-access policy are authoritative for those details.
What should you prepare before installing a mod?
Prepare a stoppable Windows dedicated server, an account with permission to edit its files, the mod’s complete package folder and a backup that is stored outside the live server directory. Do not edit package files while the server is running.
Back up the world and configuration
Pocketpair explicitly warns: “Use mods at your own risk. They may cause save-data corruption or crashes.” Copy the world saves, server settings and the mod package files to another location before the first installation. A separate internal drive, external SSD or hard drive can provide a convenient second copy, but no storage device guarantees recovery by itself.
The community guide PalMods’ Palworld 1.0 Dedicated Server Mods guide also recommends testing on a copied world before production. Keep the original world untouched until the mod has started successfully and you have checked normal gameplay, saving and shutdown.
Collect the package and its prerequisites
- Download a package built for dedicated servers, not a client-only cosmetic or local save tool.
- Read
Info.jsonand record the exactPackageName,Versionand server installation rules. - Download every prerequisite package named by the author and plan to activate each required dependency.
- Check whether players need a corresponding client installation and whether the package supports your current Palworld server revision.
How do you create the server’s mod configuration?
Launch the dedicated server once if it has never run. Pocketpair’s loader generates Mods/PalModSettings.ini after the first launch. Stop the server completely before copying packages or changing this file.
The default directory is the folder containing the dedicated-server executable. Within it, the relevant structure will look like this:
PalServer.exe
Mods/
PalModSettings.ini
Workshop/If the file was not generated, confirm that you started the dedicated-server edition rather than a client session, allow the process to finish its first initialization, then shut it down cleanly and check the executable directory again. Do not create several competing settings files in unrelated folders; the loader must read the one belonging to the running server.
Where should a Workshop mod package be placed?
By default, copy each Workshop item below the server’s Mods/Workshop directory. The folder name is only organizational; Info.json must sit directly at the root of the package folder, not inside an additional nested directory.
PalServer.exe
Mods/
PalModSettings.ini
Workshop/
MyOrganizationalFolder/
Info.json
(package files)A common mistake is extracting an archive so that the manifest ends up one level too deep, for example Workshop/MyOrganizationalFolder/PackageName/Info.json. Move the contents up until the first folder under Workshop contains Info.json directly.
Use a different Workshop root when necessary
You can keep packages elsewhere by setting an absolute path in the [PalModSettings] section of Mods/PalModSettings.ini:
[PalModSettings]
WorkshopRootDir=D:PalworldModsWorkshopAlternatively, launch the server with the -workshopdir argument:
PalServer.exe -workshopdir="D:PalworldModsWorkshop"Use one deliberate location and make sure the Windows service, scheduled task or hosting panel that starts the server passes the same argument every time. If you use Steam’s client Workshop content as a source, Pocketpair gives C:Program Files (x86)Steamsteamappsworkshopcontent1623730 as an example path. That is a client-path example, not a requirement that every dedicated server use it; copy or point the server to the location that actually contains your package folders.
How do you enable a package in PalModSettings.ini?
Open Mods/PalModSettings.ini while the server is stopped. Set the global switch to true and add one active-list entry for every package you want loaded:
[PalModSettings]
bGlobalEnableMod=true
ActiveModList=ExamplePackage
ActiveModList=RequiredDependencyReplace each example with the exact PackageName value from that package’s Info.json. Do not use the download-folder name unless it happens to be identical. Package names are identity keys for the loader, so differences in capitalization, punctuation or spacing can prevent activation.
Multiple ActiveModList lines are supported. Keep required dependencies active even when you do not interact with them directly; a dependent package can fail if its framework or library is present on disk but missing from the active list. Preserve the existing section header and normal INI syntax, and avoid adding quotes around the package name unless the package’s own documentation specifically requires them.
How do you restart and verify that the mod deployed?
Save the configuration, start the dedicated server and wait for it to finish loading. Mods are applied during a restart, not by editing the file while the process is live. Watch the server console or log output for errors, then inspect the generated management files if startup completes without an obvious message.
The loader creates a manifest at:
Mods/ManagedMods/<PackageName>/InstallManifest.jsonOpen that manifest to see what the loader recognized and where it deployed files. Compare those destinations with the package’s InstallRules. A successful copy into Workshop alone does not prove that the runtime component loaded; the managed manifest and the server log provide stronger confirmation.
Join with a test character or use a copied world and exercise the feature the package is supposed to add. Check that the world saves and that a normal stop and restart still work. If the server crashes, freezes during startup or behaves unexpectedly, stop it and restore the pre-mod backup before attempting another change.
Where does Palworld deploy different types of mods?
Pocketpair lists these runtime destinations. Treat the package’s own InstallRules as authoritative because a package can use only one of these locations or combine several.
| Mod type or loader target | Runtime location | What to verify |
|---|---|---|
| UE4SS | ModsNativeModsUE4SS |
Confirm the package’s native-mod rule and that the server build supports the required loader. |
| Lua | ModsNativeModsUE4SSMods{PackageName} |
The {PackageName} directory should match the manifest identity used by the package. |
| PalSchema | ModsNativeModsUE4SSModsPalSchemamods{PackageName} |
Check that the package declares the PalSchema dependency and its required activation order, if specified. |
| LogicMods | PalContentPaksLogicMods |
Do not substitute a manually copied file for the package’s installation rule. |
| Paks | PalContentPaks~WorkshopMods{PackageName} |
Look for the package-specific directory and the corresponding entry in InstallManifest.json. |
These paths explain why manually dropping a DLL, Lua file or pak into a guessed runtime directory is a poor first troubleshooting step. Let the Workshop package and its installation rules perform deployment, then use the manifest to diagnose a mismatch.
What should you check when a mod does not load?
Work through the checks below in order. Changing several variables at once makes it difficult to identify the cause.
1. Confirm server compatibility
Reopen Info.json and verify that the relevant InstallRule includes "IsServer": true. A package can be perfectly valid for a client while having no server rule at all. Also compare the package’s stated game or server revision with the revision your dedicated server is running.
2. Confirm the loader switch and file location
Make sure bGlobalEnableMod=true is in the PalModSettings.ini read by the running server. If you used WorkshopRootDir or -workshopdir, verify the absolute path and ensure the account that launches the server can read it.
3. Confirm the manifest identity
Copy the PackageName directly from Info.json into an ActiveModList line. Check capitalization and punctuation, and do not substitute the Steam Workshop item number or the folder’s nickname.
4. Install and activate dependencies
Read the package’s dependency declarations and author notes. Stage each prerequisite under the Workshop root and add its own exact PackageName to the active list. A missing framework can make the main package appear to be ignored even though its files are present.
5. Restart and inspect the manifest
Stop the process, wait for it to exit, then start it again. Look for Mods/ManagedMods/<PackageName>/InstallManifest.json, compare its entries with the package’s InstallRules, and review the server console or logs for permission, parsing, version or missing-file errors.
6. Test without the mod when necessary
Preserve the backup before further experiments. To forcibly disable all mods for diagnosis, add the -NoMods launch argument and restart:
PalServer.exe -NoModsThis is a diagnostic state, not a fix for damaged world data. If the world only opens with mods disabled, keep the server stopped, restore a known-good copy or follow the package author’s cleanup instructions before re-enabling anything.
How do you update a Palworld server mod safely?
Replace the staged package with the new release while the server is stopped, ensure its Info.json still declares server support, and leave the same manifest identity in ActiveModList if the author has not changed it. If the package’s Version value changes, Pocketpair says a restart automatically uninstalls the prior version and deploys the changed one.
After restarting, inspect the new InstallManifest.json and test the copied world before touching production. Read the release notes for dependency changes or client-file requirements; an update can require a new prerequisite even when the package name remains unchanged. Keep the previous package in your backup so you can roll back if the new version crashes or changes saved data.
How do you disable or remove a mod?
To disable one package, stop the server, remove its exact PackageName line from ActiveModList, save the file and restart. If you no longer need the package, you can also delete its staged Workshop folder after stopping the server. Keep a copy until you have confirmed that the world opens and saves normally without it.
For a broad diagnostic shutdown, use -NoMods rather than editing every active-list entry. Disabling a mod does not prove that changes it already made to a world have been undone; some data can remain in saves. Use the author’s removal or cleanup procedure and restore a pre-mod backup when the world will not load cleanly.
What are the practical differences between server setups?
The installation method is not equivalent across hosting arrangements. Use the following comparison before committing a live world:
| Setup | Official server-mod status | Operational requirements | Main limitation |
|---|---|---|---|
| Windows dedicated server with file access | Documented by Pocketpair | Stop/start control, editable Mods directory, log access and backups |
Still subject to package compatibility and save-corruption risk |
| Managed Windows host | Depends on the provider’s current policy | File manager or SFTP, custom launch arguments, restart controls and backup/restore tools | Some panels restrict WorkshopRootDir, -workshopdir or arbitrary package files; confirm before purchase |
| Native Linux dedicated server | Not covered as officially supported in the cited guide | Would require an independently validated compatibility path | Do not assume Windows loader behavior carries over |
| Peer-hosted or console session | Not the documented target | Platform-specific support would have to come from the game and mod author | The Windows dedicated-server procedure does not apply |
For a managed host, ask specifically whether you can upload Workshop packages, edit PalModSettings.ini, pass custom launch arguments, read startup logs and restore a world backup. A provider’s generic statement that Palworld is supported does not establish mod support.
Which client-side details must you confirm?
Server-side installation does not automatically tell players what to install. A server-only package may work for unmodified clients, while a package that adds assets, UI or input behavior may require matching files on every client. Follow the mod author’s stated client procedure and version pinning, and tell players to restart their game after installing or updating a required client component.
Do not distribute a server package to clients simply because the filenames look familiar. Keep server and client copies separated, and verify that the author provides a compatible client build. When no client requirement is stated, test with an unmodified client on a copied world rather than promising that every player can connect.
What does Pocketpair’s official documentation cover?
The primary reference is Pocketpair’s Installing Mods on a Server guide, version 1.0.4. It defines the Windows-only scope, Workshop staging path, manifest-based activation, launch-path overrides, deployment locations, automatic version replacement and the -NoMods switch. Because game updates can change loader behavior, revisit that page after a Palworld server update instead of relying on an old configuration.
The PalMods community guide adds operational advice such as backing up settings and package files and testing a copied world. It is useful supplementary guidance, but package-specific dependencies, client requirements and hosting-panel capabilities still need confirmation from the mod author and your provider.
Frequently Asked Questions
Can I install Palworld server mods on a Linux server?
Pocketpair’s documented procedure is limited to the Windows edition of the dedicated server. The guide does not establish native Linux support, so treat Linux installations as unverified unless the mod author and your server environment provide a separately tested method.
Do all players need to install the same Palworld mod?
No. Requirements vary by package: some run entirely on the server, while others require matching client files. Check the package’s client instructions and test a connection with the intended client version before opening the world to everyone.
Why does my mod folder name not work in ActiveModList?
The loader matches the manifest’s PackageName, not the folder name or Workshop item number. Copy that value exactly from Info.json, including capitalization and punctuation, then restart the server.
Will removing a mod remove its changes from my save?
Not necessarily. Disabling or deleting the package stops future deployment, but data already written to a world can remain or become incompatible. Use the mod author’s cleanup guidance and restore a pre-mod backup if the world behaves incorrectly.
How can I tell whether a mod actually deployed?
After a clean restart, inspect Mods/ManagedMods/<PackageName>/InstallManifest.json and compare its destinations with the package’s InstallRules. Server logs and a controlled test on a copied world provide additional confirmation.