Update guide

Follow Backup and recovery to save the database, configuration, application keys and certificates together before updating. Read the release notes and verify access to the selected version. Keep the previous version and its matching backup until validation is complete.

Which versions and steps does this guide cover?

This release covers RMON 1.3.0 → 1.4.0, RMON Server 6.33 → 7.0 and Agent 1.20 → 2.0. RMON, RMON Server and Agent have separate version numbers. Record the installed version of each before starting; updating one does not update the others.

Scroll horizontally to view the full table.

ComponentFromToRequired actions
RMON web application1.3.01.4.0Complete backup, maintenance stop, application and database update, then validation. Choose the installation procedure below that matches your deployment. Include the database update when staying on a native installation as well.
RMON Server6.337.0Preserve the receiver configuration, access token and certificates. Update each receiver and verify fresh results. For a joint web/server update, keep receivers stopped until the RMON database update succeeds. See the server guide for a separate receiver.
Agent1.202.0Use agent management for each host after verifying the updated receiver. Preserve its settings and verify a new check result after each agent update. An agent-only update does not require the web database update procedure.

For versions older than those listed, review the intervening release notes and the update instructions supplied for your installed version before starting. The transitions above do not specify a direct upgrade path from every earlier release.

RMON 1.4 removes browser notifications, the Socket service integration and the related RabbitMQ settings. Before relying on alerts after the update, select the required notification channels on checks and verify failure and recovery delivery. RabbitMQ monitoring checks remain available.

Choose the procedure for your installation

For RMON 1.3.0 → 1.4.0, the database update is part of the full procedure. Also check for pending database updates when replacing an earlier RMON 1.4.0 installation with the current 1.4.0 release. The version label alone does not confirm that the database is current. The update tool applies pending changes and skips changes already recorded as applied.

Native package update

Use the public RMON package repository. Before starting the maintenance window, check the available versions using the package-manager commands in the installation guide. An update command cannot install a version that has not been published for your platform. If the repository is not configured on this host, follow the repository setup steps for RPM or Ubuntu. Downloading packages requires no account, password or access key. Stop services that write to the RMON database for the update and use the database update procedure supplied for your installed version. Preserve the original application keys and database settings.

On an RPM installation, update the installed RMON services:

sudo dnf upgrade rmon rmon-server

On Ubuntu:

sudo apt update
sudo apt install --only-upgrade rmon rmon-server

Update an external result server on its own host. Complete the database update before restarting services, then verify sign-in, agents, fresh results and notifications.

After updating RMON, verify that rmon-web, rmon-scheduler and rmon-operations are running. Submit an agent operation and wait for its completion. Keep agent operations stopped while applying database updates.

Update controls in RMON

Native installations can expose update controls under Admin area → Update. Use them only after the same backup and maintenance preparation. Docker installations are updated from the deployment host using the procedure below.

Update agents separately through the agent administration workflow. A web or result-server update does not confirm that every agent has been updated. If an update fails, keep the error and follow update troubleshooting.

Update or restore RMON in Docker

This procedure starts with an existing Docker installation. Check the source and target versions and choose the appropriate procedure first. A normal Docker update includes backup, update and validation. Use the restore section only if you need to roll back.

Run these commands on the Docker host from the existing deployment directory, using one shell session. Keep the same Compose project name and file selection. If you use compose.server.yaml, keep COMPOSE_FILE=compose.yaml:compose.server.yaml in .env throughout the procedure. Do not run init on an existing installation.

Prepare a backup

Complete the Docker backup procedure before pulling images or changing configuration. Save the current images, configuration, application keys, certificates and matching database. Keep RMON and every external database writer stopped, then return here to apply the update.

Apply the update

Set RMON_WEB_IMAGE, RMON_PROXY_IMAGE, and, if used, RMON_SERVER_IMAGE in .env to the intended available versions. Keep all storage paths, application keys and the Compose project name unchanged. Check for shell variables that would override .env.

For images obtained from a registry, download them before applying changes:

docker compose config --quiet
docker compose pull web proxy

Also run docker compose pull server when using the optional server. For images supplied as an archive, use docker image load --input <image-archive> instead and select the loaded references in .env.

When updating the RMON web application, review and apply pending database updates before starting the new version. Run these checks even if the displayed RMON version has not changed; already applied updates are skipped:

docker compose run --rm --no-deps --pull never --user 33:33 -e RMON_SCHEDULER_ENABLED=0 \
  --entrypoint /opt/rmon-venv/bin/python web app/migrate.py list
docker compose run --rm --no-deps --pull never --user 33:33 -e RMON_SCHEDULER_ENABLED=0 \
  --entrypoint /opt/rmon-venv/bin/python web app/migrate.py migrate
docker compose run --rm --no-deps --pull never web check

Run one migration operation at a time. If it fails, keep RMON stopped and review the error before retrying or restoring the backup. Do not start an older image against a partially updated database.

After the checks succeed:

docker compose up -d --no-build --pull never
docker compose ps
docker compose logs --tail=100 web scheduler operations proxy

For the optional server, also run docker compose exec -T server python -m modules.common.probe ready. Restart external result servers after the database update succeeds. Verify sign-in, fresh monitoring results, agent management and a test notification. Keep the backup and previous images until you have verified the update.

Restore the previous version

If the update fails and you need to roll back, use restoring a Docker backup. Restore the saved version with its matching database and application keys. After a successful update, retain the backup; no restoration is needed.