Upgrade the server

Server upgrades are a container image change. The server applies database migrations on start, so there is no separate migration step.

Before you upgrade

• Read the release notes on the releases page.
• Take a backup of the database and the state volume. Migrations only move forward; the backup is your way back.
• Pick a quiet time. With one replica, the web UI is down for the restart, and agents reconnect within seconds of the server returning. Firewalls keep working the whole time: pfCentral is not in their traffic path.

Docker Compose

1. Change the pinned tag in compose.yaml, for example ghcr.io/danielmichaels/pf-central:0.0.13.

2. Pull and restart:

   docker compose pull pf-central
   docker compose up -d pf-central
   docker compose logs -f pf-central

3. Check the log for database migrations applied and server listening, then confirm the version in the avatar menu and that the devices come back online.

Kubernetes

Change the image tag in the Deployment and apply it.

• Single replica (embedded NATS): the Recreate strategy stops the old pod before the new one starts.
• Several replicas (external NATS): RollingUpdate replaces pods one at a time. The first new pod takes the migration lock; the others wait for it.

Give the startupProbe enough time for migrations (the example manifests allow 150 seconds).

Agents and server versions

There is no version check between the server and the agents: any agent version connects to any server version. New server features that need new agent subjects only work after you upgrade the agents. Upgrade the server first, then the agents.

Rolling back

Caution

There is no command to undo migrations. To roll back, stop the server, restore the database and the state volume from the backup you took, and start the previous image tag.