> ## Documentation Index
> Fetch the complete documentation index at: https://condor.hummingbot.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Updating Condor

> Update Condor and Hummingbot API from Telegram or the Workspace, and how update checks and notices work

Updating is admin-only and available from **both** surfaces, over one shared
engine: `/update` in Telegram and **Settings → Updates** in the Workspace. They
are two views of the same run, so an update started in Telegram can be watched
to completion in the browser and vice versa — starting a second one hands you
back the one already in flight rather than queueing it.

> [!NOTE]
>
> This is what makes a **Local mode** install self-sufficient: the Workspace
> panel is the surface it has, so an install with no Telegram bot does not need
> one to update.

## What can be updated

Two components, versioned by what actually governs them:

| Component | How it is versioned |
| - | - |
| **Condor** | A git checkout — `HEAD` against `origin/<branch>` |
| **Hummingbot API** | A git checkout **and** a container image. The repo governs the compose file and the bind-mounted `bots/`; the image governs the API's own code, so both are reported |

The API always runs the published image: an update pulls the new image with
`docker compose pull`. If you built your own image locally, the update leaves it
alone and tells you so.

## Preflight: what is in the way

Before anything runs you get the blockers, the warnings, and the ordered plan.

**Blockers** stop the update and say why in terms you can act on — the checkout
is not a git repo, it has commits the remote does not (so it cannot be
fast-forwarded), local changes would be overwritten, or the registry could not
be reached. Where a blocker has a safe way out it offers one: a dirty checkout
can be resolved with **Discard** or **Stash** without leaving the panel. When
every conflicting file is an edit to a shipped agent under `agents/`, it also
offers **Keep my version**, which moves your edit to `.condor/agents/` (where it
keeps overriding the shipped file) and lets the update go ahead.

**Warnings** never refuse — they tell you a consequence worth knowing:
restarting the API container stops its executors, and Condor keeps running the
code it booted with until it restarts.

## The restart step

An update lands the code, syncs dependencies and rebuilds the Workspace, then
hands you the moment to restart, because bots may be trading and a chat may be
mid-answer.

* **Workspace:** a banner says *Condor has been updated. Restarting in 5s to apply it* and
  then restarts Condor and reloads the page. Bots and open positions are not
  touched. **Cancel** stops the countdown; the banner then offers **Restart
  now** for when you are ready.
* **Telegram:** `/update` shows a **Restart Now** button.
* **Shell:** `make restart` works too.

The restart is in place: Condor shuts down cleanly and replaces itself under the
same process, so no second copy comes up on the port. Restarting needs the
admin role; a seat without it is told to set `role: admin` in `config.yml` or
run `make restart` on the host.

If Condor does not come back, the banner says so and the reason is in
`.condor/restart-failure.log`. The run is journalled to `data/update_run.json`
at every step, so the panel picks the result back up across the restart and the
next boot tells you whether the update worked.

## Update notifications

Condor checks in the background and tells the admin when a component falls
behind — **once per update, not once per check**, so deferring one does not
bury the rest of your notifications. Each surface gets a next step it can
actually take: a Telegram message, and a bell entry that opens the update panel
for a browser-only admin.

Tune it with `UPDATE_CHECK_INTERVAL` in `.env` — seconds, default `3600`, and
`0` disables the checks. The first runs 30 seconds after startup.

> [!NOTE]
>
> Both paths are **git-based**, so they work on a git checkout — which is what
> the Quick Start and manual installs both produce. An install unpacked some
> other way is reported as a blocker rather than silently skipped, and updates
> by whatever means it was installed.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.