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. Once the server offers a new agent version, every agent whose policy has Auto-update agent on installs it on its next sync.

• The policy option. In the Policy Settings editor, on the Agent tab, Auto-update agent is on by default. Leave it on; the only really valid reason to turn it off is a golden image. See Chapter 6.
• The concurrency limit. Max concurrent installations & updates in Settings → Updates caps how many agents update at the same time. See A.2 for what the 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. Check that Auto-update agent is on in the device's policy. If it is off, the agent stays on its current version.
• 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.
• Chapter 6 — Policies — the Auto-update agent policy setting.
• Deploy your first agent — installing an agent for the first time.