Every few months someone asks me what to rent for their bot, and they have almost always over-specced it. They price out a dozen cores and a big pile of RAM because it feels like a trading machine should be beefy. Then the thing sits at two percent CPU forever, and the money would have been better spent on anything else. A retail bot that polls a few markets, runs some indicators, and fires orders through a REST API is not a compute problem. It is a reliability and networking problem wearing a compute costume.
So before you pick a box, be honest about what your bot actually does with a machine. Most of them spend their life waiting. Waiting on a websocket to push a tick, waiting on a rate limit to clear, waiting for the next candle to close. The work happens in short bursts and then goes quiet again, and that shape should drive every decision here.
What the machine actually needs
For a single-account bot watching a handful of symbols, two virtual cores and two gigabytes of RAM is plenty, and honestly one core often does it. CPU only matters if you do something heavy on every tick, like recomputing a large feature set, running an ML inference step, or backtesting live against a long history in memory. If your strategy is moving averages, RSI, some order-book imbalance math, none of that touches the sides of a modern vCPU.
RAM is the thing people misjudge in the other direction. It is not the strategy math that eats memory, it is holding candle history and order-book snapshots for a lot of symbols at once. Track one or two pairs and you will never notice. Scan a few hundred with rolling windows for each and memory climbs fast, so you want headroom to keep the box from swapping at the worst possible moment. My rule of thumb is to run the bot for a day, watch the actual resident memory, and rent for roughly double the peak you see. Not ten times. Double.
Two things matter more than raw specs and get ignored. First, use a machine backed by NVMe or at least SSD, because a bot that logs heavily and writes state on every fill will feel sluggish on spinning disks. Second, favor providers that do not oversell CPU. Cheap shared plans sometimes pack so many tenants onto a host that you get random latency spikes from a noisy neighbor, and a spike at the wrong second is a missed exit. A slightly pricier plan with dedicated or lightly shared cores buys you consistency, which is the only thing your bot really wants.
Region, and why it matters less than people think
Latency to the exchange is real, but how much it matters depends entirely on what you are doing. If you are running a market-making or arbitrage strategy where being ten milliseconds late means someone else took the fill, physical proximity to the matching engine is the whole game. In that world you find out where the exchange actually hosts its engine, often a specific cloud region, and rent as close to it as you can. A few milliseconds is worth paying for.
For everyone else, and that is most retail bots, the obsession over region is misplaced. If your strategy holds positions for hours and enters on candle closes, whether your round trip to the exchange is 15 milliseconds or 90 changes nothing about your edge. What you are protecting against is the tail, not the average. A box halfway around the world will usually be fine and then occasionally see a big hiccup during a congested moment, and that hiccup lands exactly when volatility spikes and you most want your order in. So the sane version of caring about region is picking a location on the same continent and network path as the exchange, not chasing the last millisecond.
One concrete way to decide. Before committing, spin up a cheap instance in a candidate region and ping the exchange API endpoint for a while, ideally through a couple of busy market opens. Look less at the average and more at the worst tenth of readings. If the average is good but the tail is ugly, that region will hurt you when it counts, so try another.
When a second box earns its keep
Redundancy is where people either do nothing or wildly overbuild. Ask what actually breaks, and for a retail bot the honest answer is that your own box crashing is rarely the biggest risk. The exchange goes into maintenance, your API key hits a rate limit, the network wobbles. A hot failover server does nothing for most of those.
Before you rent a second machine, get the cheap resilience first. A process supervisor that restarts the bot on crash, like systemd or a simple watchdog, handles the most common failure. Persisting state to disk so a restart does not lose track of open positions handles the second. Idempotent order logic, so a restart mid-flight does not double an order, handles the third. Most of what people hope a second server will give them is actually just these three habits on one server.
A genuine failover box starts to make sense when the cost of the bot being down for a few minutes is larger than the cost of running and maintaining two of everything. That usually means real size, tight strategies where a missed exit is expensive, or a book you cannot babysit manually. If that is you, a workable pattern looks like this:
- Run the live bot on the primary, and a warm standby on a second box in a different datacenter, ideally a different provider so a single host outage cannot take both.
- Keep position and order state in a shared store both can read, so the standby always knows the true book and does not have to reconstruct it from scratch.
- Use a lock or heartbeat so exactly one instance is authoritative at a time. Two bots both convinced they are live and both sending orders is far worse than being down.
- Test the failover on purpose, on a schedule. A standby you have never actually cut over to is a guess, not a backup.
That last point is the one people skip and later regret. Untested redundancy tends to fail the first time you need it, usually from config drift you never noticed.
Hardening a rented machine
A VPS with an exchange API key on it is a small treasure chest, and the internet scans for open boxes constantly. You do not need anything exotic, just the boring basics done properly. Work through this list on day one and you have closed off most of how these boxes get popped:
- Disable password SSH entirely and use key-based auth only. Moving SSH off port 22 is noise reduction, not real security. The key is what protects you.
- Create a non-root user for the bot and stop logging in as root. The bot process itself should never run as root.
- Put up a firewall that denies everything by default and opens only what you need, which for most bots is SSH in and outbound to the exchange. There is no reason for the bot to be accepting inbound connections from the world.
- Keep the OS patched and turn on unattended security updates. The unglamorous stuff is what actually gets exploited.
- Never hardcode API keys in the code or a committed config file. Keep them in environment variables or a secrets file readable only by the bot user, with file permissions locked down, and give the exchange key the narrowest scope it can do the job with. If the exchange lets you disable withdrawals on an API key, disable them, so a leaked key cannot drain the account.
- Restrict the API key by IP if the exchange supports it, so even a leaked key is useless from anywhere but your box.
- Ship logs off the machine, so if the box is compromised or dies you can still see what happened.
None of this is clever, and that is the point. The failures I have seen were almost never sophisticated. They were a key committed to a public repo, or a root login with a weak password, or withdrawals left enabled on a key that leaked. Get the fundamentals right and the machine mostly takes care of itself.
The through-line here is to spend your effort where the actual risk lives. For most retail bots the risk is not horsepower or milliseconds. It is whether the machine stays up, restarts cleanly, and does not hand your keys to a stranger. Running execution across a lot of venues at Blockcircle taught the same lessons at scale. Rent modestly, watch the tail latency, and make the box boring and hard to break into.