Updates

Nothing updates itself behind your back. New releases are announced to your instance automatically, but a server update waits for an admin to click Apply update (or for you to opt in to applying every release automatically), log forwarder updates wait for you to turn on auto-upgrade, and collectors are updated by re-running the installer.

Collector updates

There’s no automatic in-place upgrade for a collector. To move one to a newer version, download the newer build from the Customer Portal → Downloads and re-run the installer on that host — it’s safe to run on an already-installed collector and won’t lose its enrollment. See Installing a Collector for the full steps.

Log forwarder updates

Linux and macOS log forwarders update through the collector they report to. Updates are off until you turn on Auto-upgrade for a forwarder under Configure → Log Forwarders (or click Upgrade now for a one-time check). Windows forwarders are updated by reinstalling with the newer bundle. See Installing a Log Forwarder.

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 tells you about it, but never applies it on its own — you decide when the restart happens.

You’ll see a pending release as a banner in the UI (below). To check from the command line instead:

docker logs gridnms-updater

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

Apply an update from the UI

When a release is waiting, signing in as an admin shows a banner across the top of every page:

Server update available: v0.5.01 → v0.5.02    [Apply update]

Click Apply update and confirm. Within about a minute the instance:

1. Downloads the release published by GridNMS,
2. Recreates the tenant-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. The banner switches to “queued” while the update is being applied, and the UI is briefly unavailable during the restart.

Clicking Apply update approves that one release. The next release waits for you in exactly the same way. If an apply fails and is rolled back, the banner says so and the button retries. The × on the banner hides it until you reload the page — it doesn’t decline the update.

Apply every future release automatically

If you’d rather not click through each release, give the updater standing consent 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

Every release then applies on its own, with the same health check and auto-revert, and no banner to click. 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.