Upgrade NetLock RMM

This guide upgrades a NetLock RMM deployment to the latest release: first the server and Web Console, then the agents. The server side applies only to self-hosted deployments — on cloud, the hosted operations team upgrades the platform for you, and you only need the agent steps.

Before you start

• For the server upgrade (self-hosted): shell access to the host running the NetLock RMM containers, and the path to the docker-compose.yml that defines your deployment.
• For the agent upgrade: a Console account that can reach Settings → Updates and edit the policy your devices use — see A.2 and Chapter 6.
• No database migration is required — see the note below.

Upgrade the Web Console and Server

Self-hosted only: This section does not apply to cloud deployments.

The server and Web Console ship as container images. Upgrading means pulling the latest images and recreating the containers. NetLock RMM deployments use a fixed compose-file path, so from the host this single command is all you need:

sudo docker compose -f /home/netlock/docker-compose.yml pull && sudo docker compose -f /home/netlock/docker-compose.yml up -d --remove-orphans

Note: The database structure updates automatically when the new server image starts — there are no manual migration steps. The agent installer packages the server distributes are refreshed at the same time.

Check for new images automatically

To avoid pulling manually, you can run a container-update watcher such as Watchtower alongside the stack. The command below starts Watchtower with a 15-minute check interval:

sudo docker run --detach \
    --name watchtower \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --restart unless-stopped \
    nickfedor/watchtower \
    --interval 900

Watchtower is a third-party tool and is not part of NetLock RMM; adopt it at your own discretion.

Upgrade the agents

Agents update themselves. On every sync an agent compares its version with the server's; when they differ, it downloads the new agent package, verifies its signature and installs it. There is no switch to turn this off, neither globally nor per policy.

Check the update concurrency

In the Console, open Settings → Updates and confirm that Max concurrent installations & updates is high enough for your fleet. The server only hands out that many updates at the same time; the remaining agents pick up the new version on a later sync. See A.2 for what the concurrency value controls and how to size it.

Verify it worked

• The Web Console reports the new version once the server containers have restarted.
• A device shows the new agent version on its detail page after it has synced and applied the update.

Troubleshooting

• Agent not updating. Agents always update, so the cause is elsewhere: the concurrency limit in Settings → Updates may be reached, in which case the agent updates on a later sync; the server may not have the update package of the new version yet, or its package manifest is missing; or the agent rejected the downloaded package because its signature did not verify. In the last two cases the agent logs the reason and keeps syncing on its current version until a valid package is available.
• Slow rollout. Raise Max concurrent installations & updates in Settings → Updates, within what your network bandwidth supports — see A.2.
• An agent upgrade failed. A failed agent upgrade normally recovers on its own — the agent's self-healing brings it back, usually within about 15 minutes.
• An update appears stuck on the server. Inspect the container logs with docker logs <container-id> to see what the service reported.

Related

• A.2 — Updates & maintenance — the Settings → Updates page and the concurrency cap in detail.
• Deploy your first agent — installing an agent for the first time.