A Palworld 1.0 release is more than a zip of files. The official loader recognizes a package by the single Info.json at its root, then uses PackageName, Version, Dependencies, MinRevision, Tags, and one or more InstallRules to decide whether and where it can deploy. Good packaging turns installation and server operation into deterministic metadata instead of prose that every user interprets differently.
Design that manifest alongside the mod. Choose a stable identity, keep runtime targets in dedicated source folders, declare the complete dependency graph, and test the package after the official uploader creates or validates it. The artifact you publish—not your development tree—is the product.
Canonical package layout
| Entry | Purpose | Rule |
|---|---|---|
Info.json | Machine-readable package identity and deployment rules | Exactly one at package root; valid JSON |
thumbnail.png | In-game and Workshop package art when named by Thumbnail | Ship the referenced file with suitable readable artwork |
Scripts/ | Lua runtime content | Target from a Lua InstallRule |
Paks/ | Resource pak/ucas/utoc sets | Target from a Paks InstallRule |
LogicMods/ | Cooked LogicMod package files | Target from a LogicMods InstallRule |
PalSchema/ | PalSchema JSON/JSONC mod content | Target from a PalSchema InstallRule |
A complete client Lua manifest
Replace dependency identities and revision with values verified for your release. PackageName must contain only ASCII letters and digits in the official uploader.
{
"ModName": "Example Runtime Utility",
"PackageName": "ExampleRuntimeUtility",
"Thumbnail": "thumbnail.png",
"Version": "1.0.0",
"DebugMode": false,
"MinRevision": 82182,
"Author": "YourName",
"Dependencies": ["UE4SS"],
"Tags": ["Utilities", "UE4SS"],
"InstallRule": [
{
"Type": "Lua",
"Targets": ["./Scripts"]
}
]
}Every Info.json field has a job
| Field | Use | Author decision |
|---|---|---|
| ModName | Human-readable display name | Clear and recognizable; it may contain spaces. |
| PackageName | Activation, dependency, deployment-folder identity | Stable, distinctive, alphanumeric only; changing it creates a new identity. |
| Thumbnail | Image shown in game and Steam | Reference an included package-relative image. |
| Version | Plain-string redeployment comparison | Change on every update; semantic versioning is optional but helpful to humans. |
| DebugMode | Forces reinstall every launch when true | Use for local iteration, ship false unless perpetual redeployment is intentional. |
| MinRevision | Minimum Palworld revision; last five title-screen digits | Set from the oldest build you actually tested. |
| Author | Attribution metadata | Use the publishing identity users can verify. |
| Dependencies | Required PackageName identities | Declare every runtime/framework package, not display titles. |
| Tags | Official Workshop classification | Use supported tags: PalSchema, UE4SS, Model Replacement, Utilities, Gameplay, User Interface. |
| InstallRule | Type, Targets, and optional server application | One or more precise rules matching real package folders. |
Add an explicit server rule
The server rule is separate even when it deploys the same source. This makes client and server intent machine-readable.
{
"InstallRule": [
{ "Type": "Lua", "Targets": ["./Scripts"] },
{ "Type": "Lua", "IsServer": true, "Targets": ["./Scripts"] }
]
}Create and validate with Mod Uploader
- 01
Run Steam under the owning account
Start Steam, sign in with an account that owns Palworld, then launch Palworld Mod Uploader and confirm the Workshop content directory for app
1623730. - 02
Create the intended package type
Use
Create New Modand select Lua, Paks, LogicMods, or PalSchema. Hold Shift while creating only when you intentionally want a local package with no Workshop item. - 03
Replace the generated template content
Keep
Info.jsonat root and place only final runtime files in the generated type folder. Do not add your repository, build cache, logs, or secrets. - 04
Save and inspect Info.json
Set a stable PackageName, real Version, minimum tested revision, dependencies, tags, and install types. Manually add server rules when needed.
- 05
Launch and test the installed package
Enable it under
Options → Mod Management, save/restart, and verify deployment plus behavior. Test the package folder the uploader manages—not a separate manual copy. - 06
Upload with useful change notes
The uploader validates readable JSON, alphanumeric PackageName, and nonempty InstallRules/Targets. Change Version before updates, write migration/removal notes, then set Workshop visibility and description.
What Info.json can safely prefill
A publishing wizard should treat the official manifest as suggestions, preserve explicit author choices, and show conflicts instead of silently guessing.
| Manifest signal | Safe PalMods use | Do not infer |
|---|---|---|
| ModName | Suggest title when empty | Long description, summary, permissions |
| Version | Prefill release/file version | Semantic ordering beyond the author’s string |
| InstallRule.Type | Suggest loader type(s) and validate archive layout | One loader when several rules are present |
| IsServer: true | Suggest dedicated-server compatibility | Server-only side; the package may also contain client rules |
| Tags | Suggest recognized taxonomy tags for confirmation | Claims not represented by official tags |
| PackageName / Dependencies / MinRevision | Persist identity, dependency graph, collision check, and build floor | Signed-in author identity, crossplay safety, or save safety |
Release gate
Clean-package install
A separate clean game can install and run only the release artifact plus declared dependencies.
Update tested over prior public version
The new Version redeploys, settings migrate or preserve correctly, and stale files do not survive unexpectedly.
Client/server matrix tested
Every claimed side and platform was actually run, including mismatched-client behavior and server restart where relevant.
Persistence and removal tested
New world, copied existing world, save–exit–reload, disable, uninstall, and dependency removal have documented outcomes.
Package contents audited
No credentials, personal paths, source-only assets, editor cache, crash dumps, or unrelated executables are included.
User documentation complete
Requirements, loader, supported revision, install, configuration, conflicts, removal, support/log location, license, and change notes are present.
Publish for maintainability
A new Workshop item starts hidden, giving you time to set visibility, description, images, required items, and support information. Use that draft window. Invite a tester who receives the package through the real subscriber path; author machines often contain undeclared frameworks or stale files that mask a broken release.
For each update, retain the previous artifact and manifest, change Version, name the supported Palworld revision, document breaking config or save changes, and provide a rollback statement. When you cannot update promptly, mark compatibility honestly instead of leaving users to discover a native crash.
Primary release references
Research sources
The claims in this guide were checked against these current references. Primary sources are marked first.