docker-palworld-dedicated-server: a containerised Palworld server driven by the REST API

RCON is gone, and that changes how the container is operated

The most consequential line in the README is a warning: RCON has been removed, and the image no longer uses RCON for any container tooling, with all server management covering player detection, backups, restarts and CLI now running through the Palworld REST API. The RCON_ENABLED variable still exists but now defaults to false, and the README is careful to note that it only controls the game server INI setting rather than container functionality. The migration also renamed environment variables, with the full guide in the Changelog section. For an existing deployment this is the thing to read first, because a server that relied on RCON for its monitoring and its backups will not behave the same way after the upgrade. The RCON port 25575 is still published in the compose file, which is a leftover worth noting.

The compose file shows the whole deployment shape

The repository ships a compose.yml, and it is more informative than the documentation. The main service runs the image jammsen/palworld-dedicated-server:latest with restart unless-stopped and local logging capped at 10 MB with three files. Three ports are published in host mode: 8211 UDP for the game server, 8212 TCP for the game server API, and 25575 TCP for RCON. The env_file points at ./default.env, and the volumes are ./game mounted at /palworld and ./companion mounted read-only at /companion-data, the latter described as a read-only view of the companion's data directory whose settings-overrides.env is applied at boot. The service also sets COMPANION_DATA_DIR to /companion-data. That single block tells you where state lives, which ports matter and how the companion hands configuration back to the server.

A companion sidecar holds the web panel and the Discord card

The second service in the compose file is a sidecar running the image jammsen/palworld-companion:develop, with depends_on pointing at the game server. It is disabled by default and idles until you enable PANEL_ENABLED or DISCORD_STATUS_ENABLED in default.env, with all companion variables in a section of that file named for the companion sidecar settings. The compose comment notes the develop tag is used during a testing grace period and switches to latest with the companion's first stable release. The port block carries a warning not to expose that port to the internet. The separation is the design point: a web panel that is not hardened for the public internet lives in its own container with its own enable switch, rather than inside the game server image.

The image is built on SteamCMD with pinned digests and a checksum

The Dockerfile shows how the server is obtained. The first stage is a Debian bookworm-slim image pinned by digest, and it exists only to fetch and verify supercronic, a cron implementation, with the release URL and a SHA1 sum held in environment variables and the sum checked by sha1sum -c. The second stage starts from the cm2network/steamcmd image, also pinned by digest, and that is where the game is installed. Pinning by digest rather than by tag is the detail worth copying: the tags move, the digests do not, so a rebuild months later gets the same base. The environment block then defines the path variables the rest of the image relies on, with GAME_ROOT at /palworld, GAME_PATH at /palworld/Pal, GAME_SAVE_PATH at /palworld/Pal/Saved, the config path at /palworld/Pal/Saved/Config/LinuxServer, the settings file at PalWorldSettings.ini and the engine file at Engine.ini, and STEAMCMD_PATH at /home/steam/steamcmd.

default.env is the configuration surface, and one setting is mandatory

Beyond compose.yml the repository holds a default.env file, a configs directory, a scripts directory, an includes directory, an entrypoint.sh, a docker-build.sh and a docs directory. The README calls out the single most important variable for a working deployment: RESTAPI_ENABLED=true must be set in default.env. That follows from the RCON removal, since the REST API is now the management channel, so a server that leaves it disabled has a running game with no way to administer it through the container tooling. Other environment variables in the file control the rest of the runtime, and the compose file points the container at that file by name, so editing default.env and recreating the container is the update loop.

The hardware floor is stated per player count

The README gives a minimum system requirements table split by expected player count, which is more useful than a single number. For 1 to 8 players it calls for 4 CPU cores at high GHz, 8 GB of RAM as a base plus 2 GB per player, and 30 GB of storage. For 8 to 12 or more players it asks for 6 to 8 CPU cores at high GHz, 12 GB of RAM as a base plus 2 GB per player, and 30 GB or more of storage. CPU and RAM are the components that scale with the player count, while storage only moves at the higher bracket. A host that meets the 8-player figure will not meet the 12-player one, and the difference is substantial.

A custom script hook exists, and the maintainer disclaims it

The caution block about the custom script feature is unusually blunt, and it is worth reading as a security note rather than a legal one. The feature lets a script run before the server starts, added after community requests, and it is entirely opt-in through CUSTOM_SCRIPT_ENABLED which defaults to false. The README states the image will never ship with a custom script of any kind, and asks readers to be careful if they find an image that appears to be this one but includes a bundled script, because it is not this image and the maintainer has no affiliation with it. The maintainer adds that support will not be provided for the feature and that no liability is accepted for harm, data loss, corruption or security issues resulting from its use.

MIT licensed, with a companion project and a slow-ish cadence

The licence is MIT, and the image is published on Docker Hub under jammsen/palworld-dedicated-server with the README linking that page as the homepage. The repository also credits two alternative images, one by thejcpalma and one by thijsvanloef, and invites people who prefer a different feature set to try those instead. The default branch is develop, with separate build workflows for master and develop shown as badges. The last push to the repository was on 2026-08-01 and the repository publishes no GitHub releases, so the release train is the Docker tag rather than a versioned artifact, which is normal for container images but means you should pin a digest if you need to know exactly what you deployed.

Editorial conclusion

This image suits a self-hoster who wants a Palworld server that is reproducible, backed up and manageable over HTTP rather than over a console protocol, because the move from RCON to the REST API removes a class of port and credential problems and the compose file wires up the ports, volumes and env file in one place. It is a poor fit if you need the RCON port or if you want the bundled convenience tooling, since RCON_ENABLED now defaults to false and the container tooling no longer speaks RCON at all. Verify first that RESTAPI_ENABLED=true is set in your default.env, as the README states explicitly, and read the CHANGELOG.md before migrating an existing server because the environment variables were renamed in the change.

Frequently asked questions

Official sources

1. Issues
2. jammsen/docker-palworld-dedicated-server on GitHub
3. License: MIT
4. Project website
5. README