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 final archive through PalMods’ upload and install path. The artifact users receive—not your development tree or a storefront—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 | Portable 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. Keep PackageName to ASCII letters and digits for broad package-tool compatibility.
{
"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 | Package image used by compatible tools and game surfaces | 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 | Portable package classification | Use recognized 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"] }
]
}Build a PalMods release
- 01
Stage a clean release candidate
Create a fresh package folder outside the development tree. Keep
Info.jsonat root and include only final runtime files, documentation, and referenced artwork—never build caches, logs, source-only assets, or secrets. - 02
Author or generate Info.json
Write the manifest directly or use Mod Uploader’s local-package mode as a template. Select the real Lua, Paks, LogicMods, or PalSchema layout without creating a Workshop item.
- 03
Inspect every package claim
Set a stable PackageName, real Version, minimum tested revision, dependencies, tags, and exact install types. Add separate server rules only when the server artifact was actually tested.
- 04
Zip the portable artifact
Place
Info.jsonat the archive root and confirm every InstallRule target exists inside the zip. The archive should not depend on a storefront-owned folder or metadata file. - 05
Upload and review on PalMods
Upload the final zip, review the detected manifest fields and scanner results, then complete the human metadata: summary, description, compatibility, save impact, permissions, requirements, and removal notes.
- 06
Test what users will receive
Install the uploaded artifact in a clean setup with only declared dependencies. Verify first install, update, disable, removal, client/server behavior, and the logs users will need for support.
What Info.json can safely prefill
PalMods treats manifest values as reviewable suggestions, preserves explicit author choices, and shows 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
Before making a PalMods release public, have another person install the exact uploaded artifact in a clean setup. Author machines often contain undeclared frameworks, development files, or stale configuration that can hide a broken release.
Change Version before updates, retain the previous artifact and manifest, 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.



Comments
Loading discussion...