App Updates

This page is about updating PalCommand itself, the desktop app. For updating your PalServer game server installs, see Patch Day.

Channels

PalCommand ships two update channels:

• Stable, the default, and the channel every install starts on.
• Beta, earlier access to new PalCommand features, at the usual risk of a beta: rougher edges, and no promise a beta build is as stable as the release it is testing.

Switch channels with Get beta updates in the Updates section of App Settings. The switch is a preference, not an action: it changes nothing about the build you’re running, and PalCommand reads it when it starts, so the new channel takes effect the next time you launch the app.

Checking for an update

PalCommand checks for updates automatically in the background: about 30 seconds after launch, and every 24 hours after that. A check is a check and nothing more. It downloads no installer, changes no file, and never touches a running server.

You can also click Check for app updates now in App settings to check immediately. Either way, PalCommand tells you which version is available on your channel, or that you’re up to date. The “Update check interval” setting further down that page is about Palworld server updates, not PalCommand’s.

To stop the background checks, turn Check for updates automatically off in the Updates section of App settings. The manual button keeps working with the switch off, and so does installing an update you already know about: the switch is about unattended checks, not about what you choose to do.

Installing an update

When a check finds a newer build, PalCommand shows a notice with two choices: Install now and Later. If you don’t pick either, the notice dismisses itself after a few seconds. Choosing Later does the same: the app is left exactly as it was, and the “Update available” chip next to the version number in the sidebar keeps the version visible for the rest of the session — the chip is informational only, not a way to reopen the notice. Your next chance to install is the next automatic check (about once a day) or the next time you restart the app.

Install now runs the whole update, in this order:

1. Download. PalCommand fetches the installer and checks it against the release signature. Your servers keep running throughout, because nothing is installed yet. If the download fails, or if the signature does not verify, the update stops here and no server is touched. PalCommand does not install an update it cannot verify.
2. Save and stop your servers. This is the same shutdown that closing PalCommand runs: each running server is announced, its world is saved, and then it stops. The overlay stays on screen for as long as that takes, because your servers are only safe while PalCommand is still open.
3. Install. The installer replaces the app. If PalCommand does not reopen on its own when it finishes, start it normally.

If a server cannot be stopped cleanly, the update is abandoned. The installer never runs, nothing is replaced, and PalCommand names the server so you can go and look at it. That is deliberate: the installer closes PalCommand, and closing PalCommand while a server is still up is the one thing that costs a world everything since its last save.

Plan an update the way you would plan a restart. Anyone playing is disconnected when step 2 begins, so it is worth a word in chat first.

While PalCommand is checking or downloading, the overlay offers a Cancel button. Cancelling there costs you nothing: no server has been asked to stop yet, and the only thing thrown away is a part-finished download. Once the overlay reaches “Saving and stopping your servers” the Cancel button is gone, because by then there is nothing to cancel back to.

Downgrading

PalCommand rolls forward, not back. If a build turns out to be broken, the fix ships as a newer signed build on the same channel, usually quickly. That is the supported route, and it is the only one that leaves your data where PalCommand expects to find it.

Going back to an older build is possible, but it is a repair step, not a supported mode. Do it only if you have been asked to, or if a new build is unusable for you and you can wait on the older one until a fix ships.

What an older build does with newer data. PalCommand’s stored files carry a version number, and an older build refuses anything it does not recognise rather than rewriting it:

• Its databases stop the app at startup with a message naming the file and saying the data belongs to a newer PalCommand. That is deliberate: opening it anyway is how a rollback would destroy the history it cannot read.
• Its app settings file (app.json) does the same, and for the same reason.
• An individual server profile written by a newer build is skipped, and PalCommand tells you which one. A skipped server does not appear on the dashboard, so its schedules do not run and its ports look free. Nothing about it is deleted: it comes back the moment you are on a build that understands it.

Where the older installers are. Every published PalCommand installer stays available at https://updates.palcommand.com/artifacts/vX.Y.Z/, where X.Y.Z is the version you want. Download the PalCommand_X.Y.Z_x64-setup.exe from that folder and run it. Your servers are not stopped by that download, but the installer closes PalCommand, so stop your servers from the dashboard first.

If an older build will not start. The startup message names the file that stopped it. Two of those files are derived data that PalCommand rebuilds by itself, so deleting them is a safe last resort:

• metrics.db (and its metrics.db-wal / metrics.db-shm siblings), the CPU and memory history behind the charts. Deleting it loses the history and nothing else.
• bans.db, which PalCommand re-reads from each server’s own ban list.

Both live in PalCommand’s data folder (App settings shows you where). Close PalCommand, move the file somewhere else rather than deleting it outright, and start the app again. Never delete app.json or anything under instances/ to get past a startup message: those are your settings and your servers, and the refusal is what is protecting them. Get back onto a newer build instead.

If an update check fails

Public releases use signed update metadata and installers. A channel may have no published release yet; that is different from a failed network request or a rejected signature. Check the download page for current stable and beta availability. If a check fails, confirm your connection and try again. If it keeps failing, contact support with the error and your app version.

Safety Mode blocks installing both app updates and game-server updates. You can still download and run the latest app installer manually; see account access and updates.

What an update never touches

A PalCommand app update never touches your managed servers’ installs, saves, or settings. Those live entirely under your configured install roots, independent of where PalCommand itself is installed, and the installer does not go near them.

Your servers are stopped during an update, but they are saved first and they are all still there afterwards. Start them again from the dashboard once the new version opens, or leave Auto-start servers on launch on and PalCommand does it for you.