Updating the server

Before you start

Take a backup. Read the release's notes on the server releases page; each one lists new tables, columns and settings, and anything that needs a hand. Updates apply schema changes on start and are meant to be taken in order, but skipping releases works.

Docker

docker compose pull
docker compose up -d

Volumes carry over. To pin a version instead of following latest, set ODM_IMAGE_TAG in .env and pull again. A local --build rebuilds the content pack from the network; a pulled image never needs the network at all.

From source

git pull                # or unpack the newer release archive over the old one
npm install
npm run build
# restart the service

If the release notes mention a new dependency for a native module, npm install takes care of it. The content pack and the embedding model are kept. Since 0.23.10 the server needs Node 22.18 or newer, 24, or 26. The account menu's About dialog says when a newer release is out.

What players notice

A restart ends voice calls; players rejoin from the dock. A turn in progress is resumed from the persisted conversation, or the lead sends it back in. Open pages reload themselves.

The apps and the server version

The desktop and Android apps draw a server's screens themselves when the server is 0.21.0 or newer; a server from 0.16.0 to 0.20.x is drawn through portal mode; older servers open their own pages inside the app. An app release is built against a specific server version and the notes say which. Updating the server to the version its notes pair with the current app keeps everything on the apps' own screens. See Version compatibility.

Rolling back

Pin the previous image tag or check out the previous tag, then restore the backup taken before the update: a newer release may have added columns the older code does not expect. Never run two versions against one data folder.