Deploy Hummingbot on TradingHost
Run open-source Hummingbot from GitHub on always-on TradingHost runtimes.
Hummingbot is a market-making and liquidity framework with native connectors to 30+ centralised and decentralised venues. TradingHost gives that strategy a production runtime.
- GitHub-native deployment
- CLOB CEX, CLOB DEX, AMM DEX
- Native connectors (no CCXT)
- V2 Scripts and Controllers
- Pure and cross-exchange market making
- Always-on runtime
- Encrypted API keys
- Region proximity to exchanges
- MCP-ready
Introduction
New to Hummingbot?
Hummingbot is a free, open-source market-making and liquidity framework. It is built specifically for strategies where you continuously quote both sides of a market, arbitrage between venues, or supply liquidity to AMM pools, rather than for directional indicator-based trading.
The framework ships native connectors to 30+ exchanges across three classes: CLOB centralised exchanges (Binance, Coinbase, Kraken, Bybit, OKX, KuCoin, and many more), CLOB decentralised exchanges (dYdX, Hyperliquid, Vertex, Injective Helix), and AMM DEX integrations (Uniswap, Raydium, PancakeSwap, Curve, Jupiter and others). These connectors are written and maintained by Hummingbot directly, not via CCXT.
Hummingbot is Apache 2.0 licensed and stewarded by the Hummingbot Foundation, a community-governance model where exchanges and contributors fund connectors and strategy work through public proposals.
TradingHost is where Hummingbot runs in production. Instead of leaving the client on a laptop or generic VPS where a network hiccup means missed quotes, you deploy your Hummingbot setup to a TradingHost cloud runtime that stays online, manages your exchange API keys as encrypted secrets, and streams logs back to you.
Section 01 · At a glance
At a glance
- What Hummingbot is
- Open-source market-making and liquidity framework, Apache 2.0 licensed
- Stewarded by
- Hummingbot Foundation (community governance)
- Language
- Python (with Cython performance modules)
- Markets
- Crypto spot, perpetual futures, AMM and CLOB DEX
- Connectors
- Native, no CCXT dependency. 30+ venues across CLOB CEX, CLOB DEX, AMM DEX
- Strategy types
- V2 Scripts, V2 Controllers, legacy V1 strategies
- Operator surfaces
- CLI client, Hummingbot Dashboard, Telegram bridge
- Deployment source
- GitHub
- TradingHost role
- Runtime, deployment, logs, secrets, region selection
- Hummingbot role
- Strategy framework, native exchange connectors, order management
- Affiliation
- TradingHost is independent and is not affiliated with the Hummingbot Foundation
- Best for
- Pure market making, cross-exchange market making, AMM-CEX arbitrage, perpetual market making
Section 02 · Where Hummingbot fits
How Hummingbot fits into the trading stack
Hummingbot is a self-contained market-making client. It ships its own native connectors to centralised and decentralised exchanges, which is why CCXT is not a dependency and why the supported list includes AMM DEX integrations that CCXT does not cover.
You can deploy Hummingbot two ways on TradingHost:
Path 01
Out-of-the-box strategy
Pick a built-in strategy (Pure Market Making, Cross-Exchange Market Making, AMM-Arb, perpetual market making) and configure it. No code required for the canonical strategies.
Path 02
Custom Script or Controller
Write a V2 Script for a single-instance strategy, or a V2 Controller for production-grade multi-pair, multi-instance setups. Subclass StrategyV2Base in Python.
Either path runs the same way on TradingHost. You bring a Hummingbot GitHub repo. We run it.
- You
- Your strategy or config owns the quoting and execution rules.
- Hummingbot
- Runs the strategy loop, native exchange connectors, and order management.
- Exchange
- Your exchange or DEX wallet receives the orders.
- TradingHost
- Runs the Hummingbot client, manages secrets, streams logs.
Section 03 · Why on TradingHost
Why deploy Hummingbot on TradingHost
Market making is unforgiving about uptime. A few seconds of disconnect mean stale quotes, adverse fills, and risk inventory drifting away from target. Running Hummingbot on a laptop or generic VPS introduces operational drag, including process supervision, restarts, dependency management, log scattering, and manual deployment.
TradingHost gives a Hummingbot client a production-oriented runtime designed for long-running trading processes.
What you get
- GitHub-native deployment
- Always-on container runtime that survives your laptop sleeping
- Multi-instance support inside one runtime
- Encrypted exchange API key storage
- Region selection close to your matching engine
- Streaming logs and basic health
- Strategy-level start, stop, restart, inspect
- Update one instance without restarting the runtime
- MCP-compatible AI IDE workflows
What you keep
- Full control over your Hummingbot config and strategy code
- Direct ownership of your exchange accounts and API permissions
- Your choice of strategy class: V2 Script, V2 Controller, or legacy V1
Section 04 · Supported venues
Supported venues
Hummingbot ships native connectors across three categories: CLOB CEX (centralised limit-order books), CLOB DEX (on-chain limit-order books), and AMM DEX (automated market maker pools). The same Hummingbot client can run quoting strategies against any of them.
Five featured pairings are shown below. The wider directory follows.
- Hummingbot
- your venue
- TradingHost runtime
Hummingbot also ships native connectors to many other venues, grouped by category:
- CLOB CEX
- Kraken, OKX, KuCoin, Gate.io, HTX, BitMart, Bitget, BingX, Bitrue, Bitstamp, BTC Markets, AscendEx, MEXC
- CLOB DEX
- dYdX, Derive, XRP Ledger, Dexalot, Injective Helix, Vertex
- AMM DEX
- Raydium, PancakeSwap, Curve, SushiSwap, Balancer, QuickSwap, Trader Joe, Meteora, Jupiter, 0x Protocol
Section 05 · Deployment flow
How a Hummingbot deployment works
A Hummingbot client on TradingHost follows the same deployment pattern as any GitHub-based project.
- STEP 01
Connect or create a repo
Sign in with GitHub and connect an existing Hummingbot repo (with your config and any custom V2 Scripts or Controllers), or create one from a TradingHost Hummingbot template.
- STEP 02
Configure the runtime
TradingHost reads your project’s runtime configuration and Hummingbot config files to know how to install dependencies and start the client in headless mode.
- STEP 03
Add encrypted exchange API keys
Add exchange API keys (and any DEX wallet credentials) as TradingHost secrets. They are encrypted, injected into the runtime at start, and never written to your repository.
/platform/secrets/ - STEP 04
Choose a region
Select a region close to your venue’s matching engine. AWS Tokyo for Binance Spot, AWS Frankfurt for many EU-domiciled exchanges, and DEX-friendly regions for AMM strategies.
/platform/regions/ - STEP 05
Deploy
TradingHost starts Hummingbot in a managed container. Logs stream back to the dashboard. The Hummingbot Dashboard, when configured, runs alongside the strategy process.
/platform/observability/
Section 06 · Strategy shapes
Scripts, V2 Controllers, legacy strategies
Hummingbot offers three shapes for production strategies. The shape decides how many processes you need, how much code you write, and how much complexity the runtime is expected to absorb.
All three shapes run on the same TradingHost runtime. A common production pattern is one runtime hosting one V2 Controller that internally runs many pairs.
Section 07 · What we don’t do
What TradingHost does not do
- TradingHost does not act as your exchange or DEX.
- TradingHost does not provide market-making strategies, parameters, or financial advice.
- TradingHost does not modify your Hummingbot configuration, scripts, or controllers.
- TradingHost does not custody your exchange API keys or DEX wallets beyond encrypted runtime injection.
- TradingHost does not guarantee fill quality, exchange uptime, or market connectivity.
Section 08 · FAQ
FAQ
No. TradingHost is independent. Hummingbot is open-source, Apache 2.0 licensed software stewarded by the Hummingbot Foundation through community governance.
No. Hummingbot ships its own native exchange connectors, which is why the supported list includes AMM DEX integrations that CCXT does not cover.
Pure market making, cross-exchange market making, AMM and AMM-CEX arbitrage, perpetual market making, and any custom strategy you can write as a V2 Script or V2 Controller.
CLOB CEX: Binance, Coinbase, Kraken, Bybit, OKX, KuCoin, Gate.io, HTX, BitMart, Bitget, BingX, Bitrue, Bitstamp, BTC Markets, AscendEx, MEXC, and others. CLOB DEX: dYdX, Hyperliquid, Derive, XRP Ledger, Dexalot, Injective Helix, Vertex. AMM DEX: Uniswap, Raydium, PancakeSwap, Curve, SushiSwap, Balancer, QuickSwap, Trader Joe, Meteora, Jupiter, 0x Protocol.
V2 Scripts are single-file strategies inheriting from StrategyV2Base, suited to prototypes and single-pair setups. V2 Controllers are production-grade modular sub-strategies that can run many independent pairs and configurations inside one Hummingbot client.
Yes. A TradingHost runtime can host multiple Hummingbot processes, and a single Hummingbot client running V2 Controllers can host many sub-strategies internally.
You add them to TradingHost as encrypted secrets. They are injected into the Hummingbot runtime at start and are not written to your repository.
Yes. The Hummingbot Dashboard is part of the project and continues to work as configured. TradingHost runs the underlying client process and exposes the necessary networking.
No. Hummingbot places trades through your exchange API credentials or DEX wallet. TradingHost runs the Hummingbot process and streams logs.
Quote stability and adverse selection are sensitive to round-trip latency. TradingHost lets you pick a region close to the matching engine for your venue. See /platform/regions/ for the full list.
Deploy your first Hummingbot strategy
Connect GitHub, choose a Hummingbot template or your own repo, add your exchange API keys, choose a region, and launch into a TradingHost runtime.