Skip to main content
Settings (the gear in the top bar) is where the install itself is configured, across seven tabs. Logout sits top right.

Servers

The Hummingbot API servers this Condor drives. Each entry shows its health dot, host and port, an OWNER badge, and a DEFAULT star β€” the server new work goes to. Add Server takes a name, host, port, and the API’s username and password; the pencil edits an entry and the trash removes it. This is the tab to use when you add a VPS API to a local Condor.
Settings β†’ Servers: configured servers with default star
Multiple servers let one Condor drive separate accounts, venues, or strategies β€” the top-bar selector switches which one every page reads from. To check a server by hand, its root endpoint answers an authenticated request with its name, version, and status:

Gateway

The Gateway container on the selected server: its status, image, and age, with Restart and Stop. Below, three drawers: Pull Image (upgrade Gateway), Networks & RPC (per-network RPC endpoints), and Logs.
Settings β†’ Gateway: container status and management drawers
Gateway is the separate service that gives the API its DEX reach β€” swaps and liquidity on Jupiter, Orca, Raydium, Meteora, and Uniswap, across Solana and EVM networks. You use it from the DEX page; this tab manages the service itself. The API reference covers what runs underneath.

Keys and Wallets

Two stores in one tab: exchange API credentials (per account, added with Add API Key) and DEX wallets (per chain, added with Add Wallet, with a default badge per chain). Secrets are write-only β€” entered here, stored by the API server, never displayed back.
Settings β†’ Keys and Wallets: credentials and wallets
Give exchange keys read + trade permissions only β€” never withdrawal or transfer. DEX wallet private keys are stored encrypted by the API server.
Connector names follow the exchange / exchange_perpetual convention (binance, binance_perpetual, hyperliquid_perpetual, …). Credentials can also be managed over the API β€” one call per operation:
Multiple accounts (/accounts/add-account) keep credential sets apart β€” paper vs. live, one strategy per account, or per-teammate keys.

LLM Endpoints

Custom OpenAI-compatible endpoints β€” Venice AI, Together, Fireworks, or your own vLLM / LM Studio server. Add endpoint takes a base URL and optional key, validates it by listing its models, and saves it under a nickname; saved endpoints appear in the chat model picker and in the Telegram bot. See LLM Integration.
Settings β†’ LLM Endpoints: custom OpenAI-compatible endpoints

Voice & AI

Voice input for the chat box: which local Whisper model transcribes (tiny β†’ large-v3, accuracy vs. speed), the language (auto-detect by default), and whether a transcription auto-sends or lands in the input for editing. The keyboard shortcut for push-to-talk is shown here.
Settings β†’ Voice & AI: Whisper model, language, and auto-send

Privacy

Both privacy switches, readable by every seat and changeable by the admin:
  • Telemetry β€” usage / ping / off, with the never sent list right on the page. This is also where an install running without Telegram answers the consent prompt in the first place.
  • Conversation sharing β€” Off / Ask me / Always, what is currently shared, and the install-wide veto that hides the share button for everyone.
The full story: Privacy: telemetry and sharing.
Settings β†’ Privacy: telemetry consent and conversation sharing

Admin

Users and roles (admin, user, pending, blocked), and the code execution grant β€” code_run lets a non-admin run arbitrary Python inside the bot process, so the tab spells out exactly what that reaches before you grant it. Grants and revocations are recorded in the audit log and take effect immediately.
Settings β†’ Admin: users, roles, and the code execution grant

Updates

Admin only. Shows what Condor and the Hummingbot API are each running and what is available β€” for the API that is both its git checkout and its container image, since the repo governs the compose file and the bind-mounted bots/ while the image governs the API’s own code. Refresh re-checks past the 60-second cache. Starting a run reports its blockers first, with a resolution where one exists: a checkout with local changes offers discard or stash without leaving the panel, while a diverged checkout or an unreachable registry can only be cancelled and fixed by hand. Warnings are shown but never refuse β€” restarting the API stops its executors, and Condor keeps running the code it booted with until you relaunch. The run is journalled at every step, so the panel survives the restart it causes: it keeps polling, picks the result back up, and the next boot says whether the update worked. Done clears a finished run. This is the same engine behind Telegram’s /update, and there is one run at a time β€” start it in either place and watch it in the other. On a Local mode install, where there is no bot, this panel is the update surface.
An update stops one step short of running the new code: it lands the code, syncs dependencies, rebuilds the dashboard, and then asks you to relaunch (make restart). Condor is rarely the top of its own process tree, so re-execing itself would race the parent into a second Condor on the same port and token. Until you relaunch, every seat sees a relaunch to apply banner β€” the browser is running the new bundle against the old API.

Using Telegram

  • /servers β€” the same server list: βž• Add Server, then set πŸ“ Name, 🌐 Host, πŸ”Œ Port, πŸ‘€ User, πŸ”‘ Pass field by field; pick the default; live status per server.
  • /keys β€” read-only: it lists connected exchanges, and connecting or removing keys happens here in the dashboard β€” the command hands you a 🌐 Open Web Dashboard login link, valid for 5 minutes.
  • /gateway β€” Gateway status and DEX connector configuration.
  • /admin β€” the user list and role approvals (Admin tab equivalent).
  • /update β€” the same update flow as Settings β†’ Updates, over the same engine: a run started in either place is visible in the other. See Keeping Condor updated.