How to tell an agent is behind
In Fleet, the Version column shows the version each self-hosted agent runs, followed by an Update available badge when a newer one exists. The agent’s own page shows the same version in its header, with Up to date or Update available beside it. On the agent’s page, select Update available for the upgrade command for that agent and a link to the matching section below. If no command is shown, use the section that matches how you deployed the agent. What is compared depends on the agent:- Replicas are checked one by one. If any live replica is behind, the agent shows Update available, with how many of its replicas are behind. A replica ahead of the newest release, such as a development build, counts as up to date.
- No badge means nothing to compare. An offline agent, a draft, or a worker whose version is not
a release number (
dev, a commit hash) shows no badge rather than a guess.
Both Helm commands below use the release name you installed with — the agent id, unless you changed
it — and
--reuse-values, which keeps everything you set at install time. That includes the worker
token and any model API key, which KAOP does not hold a copy of and cannot put back for you.Catalog agents
A self-hosted catalog agent runs a released image of that agent. The install values the console generates set its image tag tolatest. A running pod keeps the image it pulled when it started,
and a pod that is recreated pulls latest again, so replicas can end up on different versions.
Upgrade by setting the tag to the new release explicitly.
1
Note the version to upgrade to
Hover Update available to see the running and the newest release, for example
0.4.12.
The upgrade command on the agent’s page has it filled in already.2
Upgrade the release
Run this against the cluster the agent is installed in:
3
Confirm it
The new workers register on their first heartbeat and the badge clears. An agent with several
replicas shows how many are still behind until the rollout finishes.
Agents you built in KAOP
An agent created with Build from scratch and installed in your own cluster runs the KAOP agent base image, and the base image carries thekomodor-agentops SDK. Its values do not pin an image
tag, so the chart’s own version decides which base image runs: upgrading the chart upgrades the
agent.
1
Upgrade the release
--version, Helm installs the newest chart, which brings the newest base image.2
Confirm it
The new workers register with the newer SDK version and the badge clears.
If you set your own image when you built the agent, the chart no longer decides which image runs.
Rebuild that image — on a newer agent base image, or with a newer
komodor-agentops as described
in the next section — and deploy the new tag.Imported agents and your own images
An imported agent, or any agent that runs from an image you build, carries whicheverkomodor-agentops version you installed into it. KAOP cannot replace it, so you rebuild and
redeploy with your own tooling.
1
Raise the SDK version
Set With
komodor-agentops to the newest release shown on Update available, keeping the extra
for your framework:requirements.txt
pip directly:2
Rebuild and redeploy
Build the image again and roll it out the way you normally deploy the agent. Its environment —
AGENTOPS_URL, AGENTOPS_AGENT_ID and AGENTOPS_WORKER_TOKEN — stays as it is.3
Confirm it
The new replicas report the newer SDK version on their first heartbeat and the badge clears.
Next steps
Fleet health
The SDK version mix across your live workers, and whether each agent stays online.
Use specialized agents
Deploy a catalog agent, on Komodor cloud or in your own cluster.
Import an existing agent
Connect an agent you already run with the
komodor-agentops wrapper.Troubleshooting
What to check when an agent does not come back online after an upgrade.