> ## Documentation Index > Fetch the complete documentation index at: https://docs.komodor.com/llms.txt > Use this file to discover all available pages before exploring further. # Upgrade a self-hosted agent > Find a self-hosted agent running an older version, and move it to the newest release with the command for how it was deployed. An agent you run yourself is upgraded by you, with the command that matches how it was deployed. The Komodor Agentic Operation Platform (KAOP) compares the version each live replica reports with the newest one available, and marks the agent **Update available** when it is behind. Agents on Komodor cloud show no version indicator. ## 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: | Agent | Compared | Newest available | | - | - | - | | Catalog agent | The version of the catalog agent's image | The newest release of that catalog agent | | Any other self-hosted agent | The version of the `komodor-agentops` SDK inside the worker | The SDK version your KAOP control plane ships with | * **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. The indicator is enabled per account. > [!NOTE] > > 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 to `latest`. 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: ```sh theme={null} helm upgrade oci://ghcr.io/komodorio/charts/agentops-agent-base \ --reuse-values --set image.tag= ``` **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. > [!WARNING] > > Applying a values file generated by the agent's **Edit** wizard sets the image tag back to `latest`. > Run the command above again afterwards to keep the agent on a fixed release. ## 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 the `komodor-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** ```sh theme={null} helm upgrade oci://ghcr.io/komodorio/charts/agentops-agent-base \ --reuse-values ``` Without `--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. > [!NOTE] > > 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 whichever `komodor-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 `komodor-agentops` to the newest release shown on **Update available**, keeping the extra for your framework: ```text requirements.txt theme={null} komodor-agentops[langchain]>= ``` With `pip` directly: ```sh theme={null} pip install --upgrade "komodor-agentops[langchain]>=" ``` **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](/manage-your-agents/optimize/fleet-health.md)** > > The SDK version mix across your live workers, and whether each agent stays online. > **[Use specialized agents](/manage-your-agents/build/use-specialized-agents.md)** > > Deploy a catalog agent, on Komodor cloud or in your own cluster. > **[Import an existing agent](/manage-your-agents/build/import-an-agent.md)** > > Connect an agent you already run with the `komodor-agentops` wrapper. > **[Troubleshooting](/reference/troubleshooting.md#an-agent-appears-offline)** > > What to check when an agent does not come back online after an upgrade. ## Related topics - [Import an existing agent](/manage-your-agents/build/import-an-agent.md) - [Fleet health](/manage-your-agents/optimize/fleet-health.md) - [Use specialized agents](/manage-your-agents/build/use-specialized-agents.md) - [How it works](/manage-your-agents/build/how-it-works.md) - [Deployment methods](/get-started/deployment-methods.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.