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 two switches are both enabled — one global, one per policy.

Step 1 — Enable platform updates

In the Console, open Settings → Updates. Enable the platforms you want agents to update on, and confirm that Max concurrent installations & updates is high enough for your fleet. See A.2 for what the concurrency value controls and how to size it.

Step 2 — Allow auto-update in the policy

Each device also obeys its policy. In the Policy Settings editor, on the Agent tab, confirm that Auto-update agent is on for the policy assigned to the devices you want to upgrade. See Chapter 6.

With both switches on, an agent installs the new version on its next sync.

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. Both switches must be on — the global platform toggle in Settings → Updates and Auto-update agent in the device's policy. If either 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.