A market-making bot is not a "set it and forget it" script. Hummingbot sits on live WebSocket connections to the exchange, watches the order book tick by tick, and places and cancels orders every few seconds to keep a spread around the mid price. Close the laptop, drop the Wi-Fi, let the machine sleep for an OS update — and you've either got stale orders resting on the book at prices the market has already left, or a bot that quietly stopped quoting. Neither is where you want to be with money on an exchange.
So Hummingbot belongs on a server. That part isn't controversial. The useful question is what kind of server, and how not to overpay for it.
What Hummingbot actually does to a machine
It's lighter than people expect, and heavier in one specific place.
The core loop — hold connections, read the book, quote a spread — barely touches the CPU. A single pure-market-making strategy on one exchange is happy in 1–2 GB of RAM and idles most of a core. If that's all you're doing, our Micro plan ($5/mo) is genuinely enough, and I'd rather tell you that than sell you something bigger.
Memory is where it grows, and it grows for concrete reasons:
- More markets. Each strategy instance and each connector holds its own state. Run three or four bots across two exchanges and you're comfortably into 3–4 GB.
- The dashboard. Hummingbot's newer setup runs the bot, a dashboard, and a database as separate containers. That stack wants more headroom than the bare CLI bot.
- Gateway for DEX trading. If you're arbitraging or making markets on on-chain DEXes, the Gateway container is a second Node service sitting next to the main one. Not huge, but not free.
That's why the honest recommendation is: start on Micro if you're running one strategy, and move to Small ($8/mo, 4 vCPU, 4 GB) the moment you add a second bot, the dashboard, or Gateway. Small is the plan most people who run Hummingbot seriously settle on.
Disk matters less than for a backtesting-heavy Freqtrade setup, but it still writes trade history and logs constantly. NVMe (ours is RAID1, ~800 MB/s reads) keeps that off the critical path. If you're coming from Freqtrade, our Freqtrade on a VPS write-up covers the backtesting-memory side in more detail — Hummingbot leans the other way, toward live connections rather than heavy backtests.
Latency: useful honesty
You'll see "low latency" on every trading-VPS page, including ours, so here's the real version. A server physically close to the exchange's matching engine reaches it faster than a home connection routed halfway across a continent — that's real and it matters for quoting tight spreads and for cross-exchange arbitrage where you're racing a price gap. Our nodes are in Europe (Germany and Finland), which is close to where a lot of the big matching engines actually live.
What it is not is co-located high-frequency trading. If your strategy only works when you're inside the same datacenter as the exchange, shaving microseconds, a shared $8 VPS won't get you there and no honest host would claim otherwise. For everything short of that — normal market-making, spread capture, cross-exchange arb on a human-plus-seconds timescale — a nearby VPS is exactly the right amount of infrastructure.
The part that's actually our angle
Your exchange already knows who you are; it did its KYC when you opened the account. The machine that holds your API keys and runs your strategy is a different question. There's no reason the infrastructure under a trading operation has to be tied to your identity too, and plenty of people running bots would rather it wasn't — a server rented with an email and paid in stablecoin is one less place your name is written down.
That's what we do. Sign up with an email, pay in USDC or USDT (Base, Ethereum or Polygon), get root in about a minute. No card, no documents. One caveat worth stating plainly: if you're on the cheapest plans, pay in a stablecoin, not BTC — Bitcoin network fees can eat an ugly chunk of a small order, so it's the wrong rail for a $5 box.
On the keys themselves: make them trade-only, withdrawals off, and if your exchange lets you whitelist an IP, put a dedicated IP on the plan so your API keys are bound to one fixed address. The bot is only as exposed as the server it runs on, so lock the server down like it's holding money — because effectively it is.
Bottom line
Hummingbot needs a machine that never sleeps and never drops its connection to the exchange — that's the whole reason a VPS exists for this. Size it to what you're actually running: Micro for one strategy, Small once the dashboard, Gateway, or a second bot show up. Pay in crypto if you'd rather not attach your name to the infrastructure. And don't buy latency you can't use — a nearby European server is the right call; a co-lo fantasy on a $8 plan isn't.
If you want the broader picture on running any trading bot with us, the VPS for crypto trading bots page covers plan sizing and the no-KYC setup across bots, not just Hummingbot.
Comments
No comments yet. Be the first.