Operations

Back up the database

If you back up one thing, back up Postgres. It is the source of truth: users, servers, settings, audit trail. Server worlds live on the node's data volume and matter too, but a lost database means a lost installation.

Valkey is in-memory by design. Losing it loses transient queue and discovery state, not your servers. Do not spend effort persisting it.

Updating

Pull the new images and recreate:

docker compose pull
docker compose up -d

One thing to know if you use Docker Swarm: docker service update with the same image tag is a no-op. It prints "converged" and deploys nothing at all. Pin a digest, or use a new tag, and then verify the behaviour changed rather than trusting the output.

Logs

docker compose logs -f core
docker compose logs -f node

Minecraft server output does not go through Docker logs. It is shipped to a stream and shown in the panel console, live.

The status page

The admin area has a status page that names what is wrong instead of showing a red dot. It reports the database, Valkey, storage, the nodes, and the scoped credentials each node is supposed to have.

One distinction it makes that matters: a node whose heartbeat is fine but whose control channel to Core is down shows as degraded, with the reason. Those are two separate paths, and a node can be alive while unable to take commands. Before, that looked healthy.

Storage

The library and backups can live on local disk across multiple paths, or on S3-compatible object storage. Core verifies at startup that the storage it was given is actually reachable and writable, rather than discovering it during your first backup.

Scaling out

Add a node host and it appears in the panel; servers can then be placed on it. Nodes behind NAT join over the tunnel and need no port forwarding, which means a spare machine at home counts as capacity.

Core itself can run more than one instance. They coordinate through Valkey and elect a leader for the work that must happen exactly once.