palworld-server-tool puts a web panel on a Palworld dedicated server

Three ways in: save files, the REST API and RCON

The project description is bilingual and blunt about the mechanism. It is a visual interface for managing a Palworld dedicated server, through parse .sav and REST&RCON. The README states the same thing in prose: management of the Palworld dedicated server through a visual interface and a REST interface, based on SAV archive parsing, the official REST API and RCON.

Those three inputs are complementary rather than redundant. The save file holds the world data that the server API does not expose, so player, guild, pal and inventory data comes from parsing it. The official REST API covers what the game server itself publishes, such as server information, metrics and the list of online players. RCON is the write path, and it is what carries actions like kicking, banning, broadcasting and the smooth server shutdown.

The dependency on the game server is explicit. PST needs the game server to have the official REST API enabled, and the custom RCON feature additionally needs RCON enabled. The order of operations matters in practice, because the server configuration file PalWorldSettings.ini and the WorldOption.sav file have to be edited with the administrator password set first, and only then can RCON and REST be turned on. The README points to an external configuration generator for that edit.

The stack behind the panel is Go for the server, Vue for the frontend and Python for save parsing, with a separate binary named sav_cli that does the parsing work.

Parsing Level.sav will cost you a gigabyte of memory

There is one number in the README that should stop you before you deploy this, and it is in the installation section as a standalone warning. Parsing Level.sav will use roughly 1GB to 3GB of memory for a short period, and you are told to make sure the runtime environment has enough resources.

That is the cost of doing save file parsing in the panel process rather than asking the game server for the data. The tool lists viewing player, guild, pal and inventory data as a feature, and that view is what the parsing buys. The alternative would be to have no view at all, so the trade is memory for visibility into world state.

The short period qualifier matters for how you size a host. A persistent requirement of three gigabytes would be a different sizing conversation from a spike of one to three gigabytes that clears once the parse finishes, and for a container with a memory limit the spike is what decides whether the container gets killed.

The parsing implementation is credited to two upstream projects, palworld-save-tools for the save parsing tool implementation and palworld-server-toolkit for the high performance parsing part. The README also credits PalEdit for the original data oriented thinking and logic, and gorcon for the basic RCON request and receive capability. The Dockerfile pins PalworldSaveTools to a specific commit that it describes as validated against the real saves under savs/, and the Makefile has a test-sav target that builds a two architecture image and validates it against real saves.

Two SQLite files, and the split protects your world data

State lives in two databases, and the separation is the kind of detail that prevents an unpleasant afternoon.

pst.db holds the business data, meaning players, guilds, RCON records and backups. config.db holds the PST configuration and the administrator credentials on their own. The README makes the consequence explicit: cleaning or resetting the configuration does not affect player, guild, RCON and backup records.

So a full config reset is a matter of stopping the tool, deleting config.db and starting again, and your world data survives it. The same instruction appears in the first-run section for the case where somebody else claimed the administrator account before you, since the first visitor to the web panel becomes the administrator.

There is also a migration story here worth reading, because the old configuration entry points are gone. The README states that apart from --port and PST_PORT, the tool no longer reads config.yaml, the -config argument, or other PST configuration environment variables such as WEB__*, RCON__*, REST__*, SAVE__*, TASK__* and MANAGE__*. Upgrading users are told to copy the old values into the web configuration dialog manually, confirm them, and then delete the old file and the old variables.

That is an aggressive change for an upgrade, and it is worth doing deliberately rather than discovering during a restart. The two databases, both in the working directory, are also the two files you must persist in a container.

Port selection follows a documented precedence order

The listen port defaults to 8080, and the override chain is spelled out in unusual detail because it interacts with the database in a non-obvious way.

The precedence is --port, then PST_PORT, then config.db, then the default of 8080. On Linux and macOS the argument form is.

./pst --port 18080

and the environment variable form is.

PST_PORT=18080 ./pst

On Windows the equivalent in PowerShell is .\pst.exe --port 18080, and for the double click start path the README tells you to edit start.bat so the launch command becomes start cmd /k .\pst.exe --port 18080.

What makes this more than a flag is what happens to the value afterwards. When the tool is started with a command line argument or an environment variable, the final port and the port_source override origin are written into config.db, so that internal services such as sav_cli read the same port the process is actually listening on. While an override is in place the configuration centre shows the real port and the source of the override and disables the port input, and the configuration API refuses to change the port. The source is recomputed on every start, and once the override is removed config.db keeps the last overridden port with port_source cleared, at which point the web interface can change it again.

That is a lot of machinery for a port, and it exists because the tool is deployed in several shapes, from a bare binary to a container behind a reverse proxy.

Two containers when the game server is on another host

The Docker path is a single container, and the deployment is a matter of touching two files and mapping three directories.

touch pst.db config.db

docker run -d --name pst \
  -p 8080:8080 \
  -v /path/to/your/Pal/Saved:/game \
  -v ./backups:/app/backups \
  -v ./pst.db:/app/pst.db \
  -v ./config.db:/app/config.db \
  jokerwho/palworld-server-tool:latest

The game save directory is mounted at /game inside the container, and in the web configuration you choose the local directory option and browse to /game. The RCON and REST API addresses have to be addresses the container can reach, which is the usual trap when the game server runs on the same machine but on a different interface.

If you need a different port, both the mapping and the environment variable have to change together.

docker run -d --name pst \
  -p 18080:18080 \
  -e PST_PORT=18080 \
  -v /path/to/your/Pal/Saved:/game \
  -v ./backups:/app/backups \
  -v ./pst.db:/app/pst.db \
  -v ./config.db:/app/config.db \
  jokerwho/palworld-server-tool:latest

The cross-host case is where a second image comes in. When the game server and the panel are not on the same machine, you start pst-agent on the game server side, with its own port and its own save directory variable, and then point the panel at it.

docker run -d --name pst-agent \
  -p 8081:8081 \
  -v /path/to/your/Pal/Saved:/game \
  -e SAVED_DIR="/game" \
  jokerwho/palworld-server-tool-agent:latest

The agent image is built from a separate Dockerfile.agent, and in this mode the panel container needs no configuration environment variables at all.

First run is a one shot admin creation, not a login form

The initial setup sequence is unusual and has a race built into it, which is worth understanding before you hand the URL to anyone.

The first visit to the web page must create the management mode password, and the README says this action is only allowed to succeed once. The first visitor becomes the administrator. If somebody else gets there first, the documented recovery is to stop the tool, delete config.db and start again, and pst.db is unaffected. That password protects the web panel only, and it is not the game server AdminPassword, which is a distinction that matters because confusing them leads to either a locked out panel or a locked out server.

After the administrator exists, the configuration dialog opens by itself. The RCON connection can be tested with the official read only Info command, which does not change game server state, and the configuration groups show a not configured, error or normal status so you can see which half is broken.

Most settings take effect immediately, including the save source, RCON, REST, messages, management options and the administrator password. Only the web listen and TLS settings and the scheduled task period need a restart, and the page lists the specific items that require one. Changing the administrator password invalidates old login tokens immediately.

The API surface is documented two ways, with an online API documentation service and a local Swagger page at http://127.0.0.1:8080/swagger/index.html, which is useful if the panel is deployed on a network where the external documentation host is not reachable.

Where it is the wrong tool

The first limit is that it is not a standalone server manager in the abstract. It is a panel for the Palworld dedicated server specifically, it expects the official REST API and RCON to be switchable, and the whole feature set is built on top of the game's own interfaces. There is no generic game server administration layer here.

The second limit is the deployment surface. The tool is a Go binary, a Vue frontend, a Python parsing service, two SQLite files, a map asset set that is pulled with Git LFS and verified by a script, and a set of scheduled tasks. The Makefile shows the build has an init step for submodules, a map step for LFS tiles, and separate build targets for local images and multi architecture OCI packages. That is a real amount of machinery to take on for a single game server.

The third limit is the memory spike, already covered, and the fourth is the version coupling. The panel talks to a live game server through interfaces that a game update can change, and the save format it parses is a third party format maintained outside this project. The project itself is active, with releases v0.12.2, v0.12.1 and v0.12.0 in July 2026 and a last push on 2026-07-16, but that is the panel being kept up with the game, not a guarantee about the format.

Finally, the licence needs reading rather than assuming. The licence field on the repository says Apache-2.0, and the README states the project is licensed under the Apache 2.0 licence, that any redistribution must credit the README and the file portions, and that any commercial use should be reported to the author. That last clause is an extra term on top of a standard permissive licence, and the LICENSE file is where you read what it means.

Editorial conclusion

Adopt palworld-server-tool if you run a Palworld dedicated server and want a dashboard for players, guilds, pals and inventories, plus scheduled RCON commands, save syncing and backups, since the panel handles all of that from one web interface. Do not adopt it if the official REST API and RCON cannot be enabled on your host, because the tool depends on them, and note that parsing Level.sav can take around 1GB to 3GB of memory for a short period. Verify first where the game server lives, because if it is on a different machine you need pst-agent rather than a mounted save directory, and read the LICENSE file yourself, since the README adds a condition on top of Apache 2.0 that asks for commercial use to be reported to the author.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zaigie/palworld-server-tool on GitHub