Choose the task and finish the next step
This is the official package-loader workflow for a Windows dedicated server: stage the package, enable its manifest identity, restart to deploy it, and verify the intended behavior on a copied world. Pocketpair’s captured server documentation is version 1.0.4; these operating instructions are separate from this site’s v1.0.3 game-data snapshot.
The official instructions currently support server-side mods on the Windows dedicated-server edition. They do not certify a Linux host, Wine/Proton setup or a client-only mod as supported. Read the author’s server/client requirements before changing the loadout.
What the official announcement confirms
- Back up save data before removing old mods or changing the game version.
- Pocketpair says old files and loaders can still load after a manager marks them disabled; remove or relocate the actual files as its guidance describes.
- Verify Steam game files, confirm an unmodded launch, then reinstall updated mods one at a time.
- A save that depends on added mod content may fail after that content is removed; keep a backup of the world and the corresponding loadout.
Follow the matching installation path
Use the Windows staging, activation and deployment steps below for official server packages. For client-only installation, return to the appropriate platform and format guide; keep that client workflow separate from a server rule with IsServer: true.
Official package facts
Pocketpair documents Windows Steam and Windows dedicated servers for its official loader. It supports Paks, Lua, LogicMods, UE4SS and PalSchema package types. PackageName identifies an enabled package; Version changes trigger deployment, and server rules require IsServer. These facts do not certify an arbitrary mod or another platform.
Evidence boundary
The exact server-loader paths and controls are from Pocketpair’s captured documentation marked 1.0.4, together with its public package specification. They are not inferred from the v1.0.3 Pal/tool dataset. Source recommendations are rewritten independently, and the version/platform limits remain visible. Mod-specific compatibility and recovery of a changed world require the author’s instructions and an actual controlled test.
Server preflight: stop and preserve a complete recovery set
- Stop the dedicated-server process fully before replacing packages or configuration. Confirm that the instance is no longer writing the world.
- Copy the world saves, PalWorldSettings, Mods/PalModSettings.ini and the known-good package set to a separate backup location. Keep the game build and package versions with that backup.
- Open each package’s root Info.json. Record PackageName, Version, MinRevision, Dependencies and the intended InstallRule entries. Look for IsServer: true on the server rule.
- Ensure the declared dependencies are available and configured. Use the framework releases and client requirements stated by the mod author; merely putting a client package on the server does not make it server-compatible.
- Check that active PackageName values are unique. Use the manifest identity rather than a Workshop title, numeric item ID or staging-folder label.
Stage a package under the running server’s directory
Use the directory containing PalServer.exe as the reference point. By default, the loader searches its Mods/Workshop folder. Create a child folder for each package and put Info.json directly inside that child; an extra enclosing folder can prevent the manifest from being found. The folder label organizes files; it is not the activation identity.
The paths below show a hypothetical ServerExample package, not a download or a tested compatible mod. Preserve the package’s real files and manifest from the author’s release. Launching the server once generates Mods/PalModSettings.ini if it is absent; stop it again before editing.
| Path relative to PalServer.exe | What belongs there |
|---|---|
| Mods/Workshop/ServerExample/Info.json | The package-root manifest, directly below its staging folder |
| Mods/Workshop/ServerExample/<package files> | The content referenced by the manifest’s InstallRule entries |
| Mods/PalModSettings.ini | The server instance’s loader configuration |
Enable exact PackageName values in PalModSettings.ini
Open Mods/PalModSettings.ini for this server instance. Under the PalModSettings section, enable the global flag and add a separate ActiveModList line for each chosen PackageName. Repeat the key for multiple packages; do not replace the first package with a comma-separated guess.
The example below assumes that two real manifests declare PackageName values ExampleCore and ExampleServerRules. Replace those placeholders with the exact values you read, including the identities of dependencies that need activation.
| Exact example line | Purpose |
|---|---|
| [PalModSettings] | The configuration section |
| bGlobalEnableMod=true | Enable the loader globally |
| ActiveModList=ExampleCore | Activate the dependency’s manifest PackageName |
| ActiveModList=ExampleServerRules | Activate the intended server package’s manifest PackageName |
Override the Workshop root only when needed
For shared staging storage, the documented alternatives are WorkshopRootDir=<absolute path> under PalModSettings or the launch option -workshopdir="<absolute path>". Use an actual absolute Windows directory. This changes where packages are discovered; it does not change their PackageName.
Pocketpair describes the explicit-root method as loading compatible mods found below that root. Point it at the intended package set and verify what the loader actually deploys. The Steam client’s usual Workshop directory is a different default from the dedicated server’s Mods/Workshop directory.
| Alternative | Illustrative syntax |
|---|---|
| Configuration file | WorkshopRootDir=D:\PalworldPackages |
| Server launch argument | -workshopdir="D:\PalworldPackages" |
Restart, inspect deployment and test the copied world
- Start the server after staging and configuration are complete. A restart is required for package deployment.
- Inspect loader output for the enabled PackageName values, validation failures and unresolved dependencies. Successful server startup alone does not prove a mod deployed.
- Check the loader-created installation manifest for each PackageName at the exact path in the receipt table below, then inspect its server-rule runtime destination.
- Connect using the author-required client loadout. Perform the particular server action the mod changes, then save, stop and reload the copied world.
- Promote the same verified package versions and configuration to the intended server only after that test. Preserve the recovery set and note the result for each added package.
| Loader receipt | Exact path relative to the server root |
|---|---|
| Per-package installation manifest | Mods/ManagedMods/<PackageName>/InstallManifest.json |
Where the official server InstallRule types deploy
The loader interprets the InstallRule array in Info.json and deploys server-enabled entries to the locations below. Inspect these locations after startup rather than treating a manual copy into a runtime folder as evidence that package activation worked. A Lua or PalSchema package still needs its declared compatible framework dependencies.
| Type | Runtime destination relative to server root |
|---|---|
| UE4SS | Mods/NativeMods/UE4SS |
| Lua | Mods/NativeMods/UE4SS/Mods/{PackageName} |
| PalSchema | Mods/NativeMods/UE4SS/Mods/PalSchema/mods/{PackageName} |
| LogicMods | Pal/Content/Paks/LogicMods |
| Paks | Pal/Content/Paks/~WorkshopMods/{PackageName} |
Update one package with a matching recovery point
Stop the server, preserve the current recovery set and replace the staged package with the author’s update. Compare its PackageName and dependencies with the configuration. If the identity changes, update the activation entry deliberately.
For normal loader operation, a change to Version in Info.json causes the old version to be uninstalled and the new version to deploy on restart. Copying changed files while leaving the same manifest Version is not a reliable update signal. Package authors should publish a new Version and validate their server InstallRule entries.
After restarting, repeat deployment, connection, feature, save and reload checks. If the new package changes persistent world content, test removal or rollback only on a copied world; restoring the earlier world together with its matching packages and configuration is the controlled recovery path.
Disable, remove or isolate a failed loadout
For emergency isolation, add -NoMods to the server launch command; the official loader disables mod loading for that launch. Keep the existing package archive and configuration so you can compare the enabled and disabled runs. For example, from the server directory use .\PalServer.exe -NoMods.
For planned removal, stop the instance, remove the package’s ActiveModList entry and follow the author’s cleanup instructions. Check whether another active package depends on it. Remove its staged folder if needed, restart, and validate the copied world before reopening normal play.
A manually installed legacy loader or other unmanaged files are a separate layer from official package activation. If the clean-start comparison still fails, use the tracked-file recovery guide rather than assuming a changed ActiveModList entry removed every older installation.
Server starts but the mod is absent: inspect each layer
Change one layer at a time. If the manifest deployed but the expected feature is absent, record the package version, server revision, client requirements and exact test action before contacting its author. Avoid interpreting the presence of a file as proof that an arbitrary mod works.
| Check | Concrete evidence to inspect |
|---|---|
| Global switch | bGlobalEnableMod=true is inside [PalModSettings] in the file read by this instance |
| Manifest location | Info.json is at Mods/Workshop/<folder>/Info.json or under the configured absolute Workshop root |
| Activation identity | Each ActiveModList value equals PackageName from that package’s Info.json |
| Server rule | The intended InstallRule entry contains IsServer: true; client-only entries do not establish server support |
| Minimum revision | Compare the running server revision with MinRevision; do not substitute the display title or Workshop item number |
| Dependencies | The required package identities and framework files are staged, activated and reported as loaded |
| Deployment evidence | Inspect InstallManifest.json, runtime files and loader errors after a restart |
| Actual result | Test the mod’s stated server behavior with the required client set, then save and reload |
Operate and publish the server package deliberately
Keep a small change log of the server build, enabled PackageName values, manifest Versions and dependency set. Retain the package author’s attribution and release source. The workflow here is a loader procedure, not a compatibility or safety certificate for any listed mod.
For a release you author, validate the Info.json fields, add the server-enabled rules and dependencies, increment Version for updates, and test the deployed result on a copied world. Publishing to an external service follows that service’s account requirements; this site’s guide does not create an account or publish for you.
Dedicated-server questions answered
Can these official instructions be applied to Linux? The captured 1.0.4 documentation supports Windows dedicated servers only. What goes into ActiveModList? The manifest’s PackageName, with one line per package. Do players also need the mod? Follow the author’s client/server requirements; server deployment alone does not establish the answer. How can a loadout be disabled for a diagnostic launch? Use -NoMods and retain a known-good copied world and package set.
These steps and paths are documentation-backed. No native dedicated server, package installation, save migration or external publication was executed as part of writing this article. Later documentation or a particular mod can impose additional requirements.