The server is almost never the expensive part. Whenever someone asks me what it costs to keep a trading bot running around the clock, they are picturing a serious machine in a datacenter somewhere, and the honest answer is that the compute for a retail bot costs about as much as a couple of coffees. A small virtual server with one or two cores and a couple gigabytes of memory runs roughly five to ten dollars a month from any commodity host, and that is genuinely enough. A bot spends nearly its whole life waiting on the network. A price ticks in over a websocket, the bot does a few milliseconds of arithmetic, and it goes back to waiting. Paying for more CPU mostly buys idle silicon.
The interesting question is where the money actually goes, and it splits into two buckets. Some costs are flat and stay the same whether you trade once a week or once a minute. Other costs scale with trade frequency and data appetite, and those are the ones that quietly turn a ten dollar hobby into a few hundred a month without anyone deciding that on purpose.
The flat costs, and why they are boring
Hosting is flat. You want a VPS instead of your home machine, and the reason is uptime rather than speed. Residential internet drops, laptops go to sleep, power flickers, and a bot that misses the exit on an open position because your ISP had a bad night is worse than no bot at all. There is a second reason people miss. Most exchanges let you whitelist an API key to a specific IP address, which is one of the best free security controls you can get, and it needs a static IP that home connections rarely offer. Any of the big commodity providers will do, the bot does not care which one.
Monitoring is flat, and mostly free. The setup I trust is a heartbeat instead of a ping. Do not ask whether the server is up, because the server can be up while the bot process died six hours ago. Have the bot itself check in with a dead man's switch service every few minutes and alert you when the check-ins stop. Free tiers of the usual uptime services cover this comfortably, and a Telegram or Discord webhook for trade notifications and errors costs nothing either.
Database storage is flat until you make it otherwise. SQLite on the same box is fine for a single bot, and Postgres costs nothing extra if you prefer it. Your trades, your orders, and a reasonable candle history for a handful of pairs will take years to outgrow the disk that comes with a ten dollar server.
The costs that scale with how often you trade
Live market data is the pleasant surprise. Exchange websockets are free, and for crypto they are good, so a bot trading on the same venue it gets data from pays nothing for its feed. The bill starts when you want data the exchange does not hand you. Historical candles for backtesting, aggregated feeds across venues, equities or futures data, order book depth beyond what the public stream carries. Retail data plans typically start in the tens of dollars a month and climb fast, and the temptation to upgrade a tier is constant.
API usage scales with frequency too. Exchanges meter requests by weight, and a bot that polls REST endpoints every second across twenty pairs will hit limits a websocket subscriber never sees. Streaming instead of polling fixes most of that for free, but if you lean on a third party API with metered pricing, every extra pair and every shorter timeframe multiplies your call volume. Overage fees on metered data APIs are the closest thing this hobby has to a gym that charges by the rep.
Storage scales the moment you get ambitious. Minute candles for ten pairs are trivial, a few megabytes a day. Full order book snapshots run to gigabytes a day, and people archive them for months out of vague ambition and then never read them. Logs deserve their own warning. I have personally watched a runaway log file eat an entire disk and take the database down with it, while the bot kept cheerfully trying to trade the whole time. Rotate logs on day one, before the bot has anything to say.
Three budgets that actually work
The ten dollar tier is real and I would start everyone there. One small VPS, one exchange, websocket data, SQLite, a free heartbeat monitor, Telegram alerts. That runs a single strategy on a handful of pairs with no compromise that matters. What you give up is scope, meaning one venue, no deep history on tap, and if the box dies you are down until you notice.
The fifty dollar neighborhood buys resilience and history. A slightly bigger server, or better, two small ones so the bot and your database are not sharing fate. Automated snapshots or a managed database, so a dead disk is an inconvenience rather than an autopsy. A modest historical data subscription so you can backtest against more than whatever you managed to scrape yourself. Most serious hobbyists should sit here, and plenty never need to leave.
A few hundred a month is where small operations land, and it is usually the data that gets them there, since compute stays cheap even at this level. A proper vendor feed across venues or asset classes, redundant servers in different regions, error tracking, a managed database with point-in-time recovery. What this tier mostly should not buy is latency. Shaving milliseconds is a professional arms race, and if a strategy dies because the order arrived two hundred milliseconds late, a retail budget was never going to save it.
Where the surprise bills come from
Almost every blowup I have seen follows the same shape. The monthly run cost was fine, then a one-time decision multiplied a scaling cost. Someone moves a strategy from hourly bars to minute bars and the API calls, the storage, and the vendor tier all jump together. Someone backfills five years of history through a metered API over a weekend. Someone turns on debug logging to chase a bug and forgets about it for a month. None of it shows up in the plan, because the plan was written when the bot was small.
- Rotate and cap log files before the first deploy, and put disk usage in your monitoring, because full disks kill databases quietly.
- Put the heartbeat on the bot process, and page yourself when check-ins stop, whatever the server says.
- Whitelist exchange API keys to your server IP, and never give a bot key withdrawal permissions.
- Budget historical data as a one-time project cost, separate from the monthly run rate, so a backfill weekend does not ambush you.
- Before adding any data subscription, write down the specific decision that data would change. If you cannot name one, skip it.
The habit I would push against hardest is spending on infrastructure before the strategy has earned it. A ten dollar server will faithfully execute a losing strategy all year, and I have watched people pay for twelve months of hosting and data to learn something a decent backtest would have told them in an afternoon, which is a fair chunk of why we built backtesting into Blockcircle. Kill or validate the idea cheaply first. A bot that deserves a few hundred a month of infrastructure will make that case with its own numbers, and until it does, ten dollars is plenty.