Skip to main content

Upgrade a sensor on Linux (Docker)

An upgrade is a new image tag and a container replacement. Because the sensor's identity lives in the mounted data directory rather than in the container, the upgraded sensor rejoins as the same sensor — same name, same history, same integration assignments. There is no re-enrolment and no new deployment token.

This assumes the layout from Install a sensor on Linux (Docker), where ./data/, ./logs/ and config.json are mounted from the host.

Before you start​

Find the version to move to. The release notes list every Lumen Edge release, newest first — the latest entry is the version you want, and its notes are where anything you need to know before upgrading is called out. Subscribe to the RSS or Atom feed if you would rather be told than remember to look.

Pick your moment. A task the sensor is running when the container stops is requeued rather than lost, but it does start again from the beginning. For a sensor that runs long active scans, disable it in the console first (sensor detail → Disable), let the current run finish, then upgrade — see Disabling versus deleting.

Note the version you are on. The sensor list shows it, and it is what you compare against afterwards.

Update the image tag​

Set the tag to the version you took from the release notes:

docker-compose.yml
    image: lumenedge-agent:v0.9.1

Nothing else in the compose file changes. In particular, do not put a deployment token back — the sensor already has its own API token in ./data/.

Pull and recreate​

docker compose pull
docker compose up -d

Confirm​

Within a poll interval the sensor's Version in the console shows the new build and its last-seen time is current. Re-enable it if you disabled it beforehand.

If the version does not move, the container is probably still the old one — a docker compose up -d with an unchanged tag is a no-op. Check the tag, then the sensor's log in the mounted logs/ directory.

Rolling back​

Set the previous tag and repeat the pull-and-recreate. The data directory is forward- and backward-compatible in the ordinary case, so the sensor rejoins on the older build as the same sensor.

TODO

Document which sensor versions are safe to roll back to, and whether any release changes the on-disk data format in a way that prevents it.

What not to do​

Do not clear the data directory to fix an upgrade

Deleting ./data/, or starting with MODE: reset, throws away the API token. The host then enrols as a new sensor with a fresh identity, and the old entry stays in the console holding the integration assignments — which now point at a sensor that no longer exists. Recovering means reassigning every integration by hand.

Upgrade one sensor first

Upgrade a single, low-consequence sensor and let it run a full cycle before rolling the fleet. Mixed versions are expected and tolerated in the meantime; the sensor list's Version column is what tells you how far along you are.

TODO

The sensor detail view offers an Update agent action intended to trigger this from the console. Document it once it is wired; until then, upgrade on the host as above.

See also​