Updates & rollouts

The OpsMerge agent updates itself. You don't need to push patches, run an update task, or rebuild your MSI library. This article covers how that works, the one control you have, and what to do when an update misbehaves.

Regional ingest hosts

References to ingest-eu.opsmerge.cloud below are for EU-cell tenants. Other regions use a region-specific ingest hostname (ingest-us.opsmerge.cloud, etc.). The agent uses the value baked into its config at install time — operators don't usually need to think about this after the fact.

How updates work

The agent runs an internal update-check loop. On its check interval (default: every six hours, set by update_check_interval in the agent config) it:

1. Asks OpsMerge what the current published version is for its platform and architecture.
2. Compares that against the version it's running. If the published version isn't newer, it does nothing. If it would be a downgrade, it refuses — a safety guard against a stray "current" flag pointing at an older build.
3. If the published version is newer, downloads the new agent binary from ingest-eu.opsmerge.cloud, verifies its SHA-256 checksum (and an Ed25519 signature, when the tenant has a signing key), then applies it.
4. Logs the result and reports the outcome back to OpsMerge.

How the swap itself happens depends on the platform:

• Linux / macOS — the agent replaces its own binary in place and re-executes, so the service comes back up on the new version. There's no separate helper process.
• Windows — a small helper binary, rmm-updater.exe, does the swap. A binary can't replace itself while it's running and locked by the service, so the agent hands off to the helper, which stops the service, swaps the binary, and starts it again. The helper is refreshed on every check so it can't drift behind the agent.

Automatic rollback

Before the new binary is allowed to take over, it's checked. On Windows the helper runs a quick self-test (rmm-agent -version) to catch a truncated download, an AV-quarantined file, or a wrong-architecture binary. If that fails — or if the new binary won't start, or the service exits straight after starting — the helper restores the previous binary and starts that instead. The endpoint ends up back on the version it was running, not broken.

A broken binary is kept on disk (as rmm-agent.broken.exe) for forensics, and on Windows an hourly recovery Scheduled Task acts as a second-layer net if the service is ever left down.

Publishing flow (what we do, what you see)

When the OpsMerge team publishes a new agent version:

1. We tag a release in our CI.
2. CI builds Windows / macOS-x64 / macOS-arm64 / Linux-x64 / Linux-arm64 binaries, signs them, and uploads.
3. We promote the build to "current" — at which point agents in the field start picking it up on their next check.

What to expect during a rolling update

Across a fleet of endpoints, an update takes a few hours to fully propagate — the check interval is six hours, so the last endpoint to update is one that just finished a check before the version was promoted. Offline endpoints update on their next check after they reconnect.

If you want to update a single endpoint sooner than its next scheduled check, open the agent's detail page. When the agent is behind the current version, an update arrow appears next to the version number ("Update to v…"). Clicking it tells that one agent to check and update now. If the agent is offline, the request is queued and runs when it next reconnects (held for up to 28 days).

There's no per-agent or per-client update channel, no auto-update toggle, and no version-pinning in the UI — every agent tracks the current published version, and the only manual lever is "update this one now".

Common issues during updates

Update reported but version didn't change. Look at the agent log on the endpoint:

• Windows: C:\ProgramData\rmm\rmm-agent.log (the rmm-updater.exe helper also writes to the Windows Event Log, source RMMAgent-Updater).
• macOS / Linux: /var/log/rmm-agent.log.

If the log shows "no update available", the published version doesn't actually differ from what's installed. If it shows the update applied but the running agent still reports the old version, the service restart raced — see the troubleshooting article.

Checksum mismatch. Something between us and the endpoint is rewriting the binary mid-flight. Most commonly: a TLS-inspecting proxy, an over-zealous content-filter, or a corporate antivirus rewriting executables. Allow-list ingest-eu.opsmerge.cloud from any in-line rewrite/inspect.

Endpoint stuck on an old version with no errors in the log. Check the agent config — if update_check_interval is set to 0s, automatic update checks are disabled on that box and it will only update when you trigger it from the agent's detail page.

One endpoint won't update; many do. Usually local — disk space, AV blocking the swap, or an install directory the service can't write to (on systemd, the install dir must be in ReadWritePaths= when ProtectSystem= is set). The agent logs a warning at startup when its install directory isn't writable.

Pausing a rollout

There's a platform-wide kill switch — PAUSE_AGENT_UPDATES in the OpsMerge platform config — that's owned and operated by us, not by tenants. It exists so we can halt a bad rollout for everyone within one update-check cycle, without requiring a code deploy. If you specifically want a tenant-level pause control, tell us and it'll go on the roadmap.

Next

• Troubleshooting agents
• Policies — controlling agent behaviour beyond version