Skip to main content
New to Condor, or picking up where you left off? Use the tables below to find the fastest route to what you actually want to do—no need to read every page in order.

​
By experience level

​
Which install do you want?

The installer asks how you will drive Condor, and where it runs. Three paths, all running the same agents, bots, routines and dashboard.
Local mode has no login. It binds 127.0.0.1 so only that machine can reach it. Exposing it (setting WEB_HOST=0.0.0.0) puts full trading control in reach of anyone who can hit the port—only do that behind something that authenticates, such as Tailscale, an SSH tunnel, or an authenticating reverse proxy.
You are not locked in: the usual route is Local first, Telegram alerts when you want your phone in the loop, and a server once real capital is involved — re-running make setup switches mode any time. Configured servers are shared and carry across; switching Telegram → Local keeps your id and with it your preferences and agent history, while a Local-only install that adds Telegram moves from id 1 to your Telegram id, so per-user history stays behind — make that hop early. Steps for each hop: Start local, grow later.

​
What do you want Condor to do?

Condor gives you four ways to execute a trade, from fully autonomous to fully manual. Most users end up combining more than one.

​
Key features

What Condor actually does, and where each is documented. Most people arrive wanting one of these.

​
By use case

Installing (local install—Tailscale not required; Local mode skips Telegram entirely) → Credentials → dry-run an agent in Build Your First Agent
Installing (remote install—Tailscale required) → Servers → Managing Sessions
Trading Agents Architecture (multi-agent via controller_id) → Global Routines → Servers

​
Do I need Tailscale?

Installed before the API’s port lockdown? Check it. Hummingbot API used to publish port 8000 on every interface, including a VPS’s public IP. It now binds 127.0.0.1 by default (${API_BIND:-127.0.0.1} in docker-compose.yml), and so do Postgres and the EMQX broker — but an existing stack keeps its old bindings until the containers are recreated. Run make deploy in hummingbot-api, then make doctor, which flags any of those ports still sitting on a public interface.If you do need the API reachable off-box, widen it deliberately with API_BIND in hummingbot-api/.env — prefer a specific interface over 0.0.0.0, and with the Tailscale overlay API_BIND=<your-tailscale-ip> keeps MagicDNS working without publishing anything to the internet. Note that Docker’s published ports are not blocked by ufw: its rules are evaluated before ufw’s, so ufw deny 8000 leaves a widened port reachable unless you write DOCKER-USER rules yourself. Close the port in your cloud provider’s firewall instead — that is enforced off-host.
See Installing for the full setup, or the Tailscale security walkthrough for a deeper guide.

​
Something not working?

Run make doctor from the Condor directory. It re-checks dependencies, your .env and config.yml, the AI model, whether the dashboard is on a public interface, Tailscale, and whether every configured Hummingbot API server is actually reachable and authenticating—and names the fix for each thing it finds. It is read-only and safe to run at any time. On the API host, docker compose ps (are the containers up) and make tailscale-status (is the tailnet node connected) from the hummingbot-api directory cover the execution layer, and curl -u USER:PASS http://localhost:8000/ confirms the API answers an authenticated request.

​
Next steps

Introduction

What Condor is and who it’s for

Motivation

Why Condor is architected this way

GitHub

Source code and issues

Give Feedback

2-minute survey that shapes the roadmap

Help shape Condor

What’s working? What’s confusing? What do you wish Condor could do? Your answers go straight to the Hummingbot Foundation team and directly shape what we build next.