Updates

Nothing updates itself behind your back. New releases are announced to your instance automatically, but both collector and server updates wait for you unless you explicitly opt in to automatic updates.

Collector updates

When a new collector version is published, each collector’s row on Configure → Collectors shows that an update is available. Open the collector to act on it:

• Manual (the default) — click Upgrade now. The collector downloads the new version over its existing connection, swaps itself over, and reverts on its own if the new version fails to come up healthy.
• Automatic (opt-in) — set the collector’s Auto-upgrade policy to Auto after 24h or Auto after 7 days. The collector then upgrades itself once a new release has been out for that hold window, giving you a soak period before it reaches your fleet.

Each collector has its own policy, so you can auto-upgrade low-risk sites while keeping critical ones manual.

Server / UI updates

Server and UI updates are handled by the bundled updater service — it ships enabled with everything it needs; there is nothing to configure or no credentials to set.

When GridNMS publishes a new server release, your instance learns about it on its next check-in. By default the updater is notify-only: it records that a release is available and logs it, but never applies it on its own. Check for a pending release with:

docker logs gridnms-updater

A pending update shows as SERVER UPDATE AVAILABLE with the target version.

Apply an update

To apply a pending release, opt the updater in by setting the flag in .env (in your install folder) and recreating the updater service:

echo "UPDATER_AUTO_APPLY=1" >> .env
docker compose -f docker-compose.selfhosted.yml up -d updater

Within a minute the updater:

1. Downloads the release published by GridNMS,
2. Recreates the server container (which carries both the API and the UI),
3. Health-checks the new container, and
4. Auto-reverts to the prior version if the new one fails to come up.

There is no rebuild step, and your data is untouched either way.

Leave UPDATER_AUTO_APPLY=1 in place if you want future releases applied unattended as they’re published; remove the line (and recreate the updater service again) to return to notify-only.

Migration boundaries are never skipped

GridNMS never skips a required database-migration boundary. If your version is too far behind a target release, the platform walks you up through the required intermediate release(s) first.