Does your bot actually care about latency?
Ask one question: would the strategy behave differently if every order arrived 150 milliseconds later?
If no, latency is not your problem. Most retail bots fall here. A grid bot repositioning on a schedule, a DCA bot buying weekly, a portfolio rebalancer, a signal bot reacting to a candle close, all of these have decision intervals measured in seconds to hours. Another tenth of a second changes nothing. Put the server wherever is convenient and cheap, and spend the attention on uptime instead.
If yes, the region is the whole purchase. Arbitrage between venues, market making, anything where you are racing other participants to the same fill. Here a hundred milliseconds can decide whether the strategy works at all.
Be honest at this step. Far fewer people run latency-sensitive strategies than buy hosting as though they do.
If latency matters: get close to the venue
The rule is simple and geographic. Put the bot in the same city as the exchange's matching engine, or the nearest city with good peering to it.
Many large centralised exchanges run their infrastructure in a small number of hubs. Typically that means:
- Tokyo and Singapore for most exchanges serving Asian markets
- London, Frankfurt or Amsterdam for European venues
- New Jersey for US venues, where much of the traditional financial infrastructure sits
Do not take a list as authority, including this one. Exchanges move, and the only reliable answer is measured:
# from a candidate server, against the exchange's API host
ping -c 20 api.example-exchange.com
curl -w "%{time_connect} %{time_total}\n" -o /dev/null -s https://api.example-exchange.com/timeDeploy in two or three candidate cities, measure from each, keep the winner and destroy the rest. Because billing is hourly, an hour on three entry-level servers costs about four cents in total.
If latency does not matter: optimise for staying up
For most bots the realistic failure is a bot that stopped running on Tuesday and nobody noticed until Friday.
Things worth more than a faster city:
- A process supervisor.
systemdwithRestart=always, or a container with a restart policy. A bot that dies on an unhandled exception and stays dead is the most common way retail strategies lose money quietly. - A heartbeat you will actually see. Have the bot report in somewhere, a Telegram message, a healthcheck ping, so silence is noticeable. The bot knowing it is alive is not the same as you knowing.
- Log rotation. A chatty bot fills a 25 GB disk faster than you expect, and a full disk stops everything on the machine.
- Clock sync. Exchange APIs reject requests whose timestamp drifts too far. Stock Ubuntu and Debian images ship with
systemd-timesyncdenabled; check it withtimedatectlrather than assume it.
Sizing, briefly
A single bot polling an API and holding some state is small: a few hundred megabytes and almost no CPU. The entry plan (1 vCPU, 1 GB RAM, 25 GB disk) runs it comfortably.
It stops being small when you add a database of historical candles, run backtests on the same box, or run twenty strategies in parallel. Those are disk and CPU problems, and the answer is a larger plan. Moving to another city will not help.
Keys on a rented server
Worth saying plainly, because it is the part people skip. Your API keys are on a machine you do not physically control.
Disable withdrawal permission on the key. Every major exchange lets you scope keys to trading only. A trade-only key on a compromised server can cost you a bad position. A key with withdrawal rights can cost you the whole account.
Restrict the key to the server's IP where the exchange supports it. Every server here gets its own dedicated IPv4, so the allowlist is a single address that stays the same for the life of the server.
Do not leave keys in your shell history or a world-readable file. Environment file with 600 permissions, owned by the user the bot runs as.
The SSH hardening walkthrough covers the rest of the machine. The keys are the part specific to this workload.
Deploying one here
New servers run on Vultr, Hetzner and Linode, from $10 a month (about $0.014 an hour) for the 1 GB plan, billed hourly from a prepaid balance. You top it up with USDT or other crypto, or with a card. Tokyo, Singapore, London, Frankfurt, Amsterdam and New Jersey are all in the region list. Servers can also be created from the API with a personal token, which helps if you script the measuring step above. There is a broader guide to the setup itself if you are starting from scratch.