VPS for a Crypto Trading Bot: We Measured the Latency Claim

Axel Grubba, October 19, 2026
Start selling digital products with Crevio
Crevio E-Commerce Platforms logo
Crevio
Sponsored
5.0
(1)
Free plan available
Crevio is an AI-powered platform that runs your business while you sleep. Describe what you want to se... Learn more about Crevio
Get an AI summary of this post on:

One thing to get out of the way: a trading bot and a miner are not the same question to a hosting provider. Bots are among the lightest workloads on a VPS; miners are named in the prohibited list at most hosts — Hostinger’s terms list them beside Trojan horses. Everything below is about the permitted kind.

Every “best VPS for trading bots” list tells you to choose a data centre near the exchange. It’s plausible advice and almost nobody tests it, so we did — from a server in Nuremberg and a server in Ashburn, Virginia, to the public API endpoints of three major exchanges.

The result isn’t what the advice predicts.

What we measured

TCP connect time, and the IP each hostname resolved to:

Endpoint From Nuremberg From Ashburn
api.binance.com 7.5 ms 16.3 ms
api.coinbase.com 16.8 ms 2.3 ms
api.bybit.com 9.2 ms 17.3 ms

Single-digit to mid-teens milliseconds from both continents, to all three exchanges. That shouldn’t be possible if you’re reaching a matching engine in one specific region.

Then we looked at the addresses:

Endpoint Nuremberg resolved to Ashburn resolved to Owner
api.binance.com 3.174.49.178 13.225.199.163 Amazon CloudFront
api.bybit.com 13.32.99.91 18.238.25.36 Amazon CloudFront
api.coinbase.com 2a06:98c1:3102::ac40:98f1 the same address Cloudflare anycast

Binance’s and Bybit’s public REST endpoints are CloudFront-fronted, serving a different edge IP depending on where you ask from. Coinbase’s returns the identical anycast address from both continents.

Why the standard latency test is misleading

If you ping api.binance.com from a VPS, you are measuring your distance to the nearest CDN edge. CDN edges are near almost everywhere — that’s their entire purpose.

Three consequences:

A “latency test” between hosting locations mostly measures CDN routing, not proximity to an exchange. Both our locations got under 20ms to all three exchanges despite being 6,000 km apart.

Coinbase’s case makes it explicit. The same anycast IP answered from Germany and Virginia. Any difference you’d measure between two hosting regions is BGP routing to the nearest Cloudflare PoP — nothing to do with where Coinbase runs.

So comparison tables built on pinging public endpoints can’t support the conclusions drawn from them. We were going to build one. The measurement is why we didn’t.

The same trap catches forex traders, with one important difference: some broker trade servers really are single-origin machines in a known building, so proximity is a genuine variable there rather than an illusion. We ran the same test on real broker addresses and found one that answered in 4ms from Germany and 86ms from Virginia — a CDN — alongside another that was a real origin server in Northern Virginia.

What this does not mean: that latency is irrelevant to trading. It means the retail path to these exchanges runs through a CDN, and the sub-millisecond game is played by firms with co-located hardware and direct connectivity — not by anyone choosing between $6 VPS plans. If you’re doing high-frequency arbitrage, none of this article’s advice is aimed at you and you already know it.

For a retail bot placing orders on signals, the honest position: pick a region on the right continent, then stop optimising latency and start on the two things below, which are where retail bots actually fail.

Where retail bots actually fail

Your API keys

A compromised trading server means someone else has your exchange credentials. The defences are configuration rather than software, and all are free:

Disable withdrawal permissions on the API key. This is the single most important setting in this article. A trading key needs read and trade permissions. It does not need withdrawal. Set that way, a fully compromised server cannot move your funds off the exchange — an attacker can make bad trades, which is bad, but not the same category of bad.

Use IP allowlisting. Every major exchange lets you bind an API key to specific IPs. Bind it to your server. A stolen key is then useless from anywhere else.

Keep keys out of the code and out of your shell history. Environment variables loaded from a file with restrictive permissions, or a secrets manager. Never in the repository, never in a config you might paste into a support ticket.

One correction to that if you run the bot in Docker. We tested this since publishing: a 600-permission env file passed with --env-file still ends up in the container’s stored configuration, where docker inspect prints the key in plain text to anyone in the docker group. The file permissions protect the file, not the container. Mount the secret as a read-only file instead and have your entrypoint read it.

Use separate keys per bot, so revoking one doesn’t stop everything.

Restarts and interruptions

A bot that dies silently at 3am and stays dead is worse than one that never ran.

Run it under a supervisor. A systemd unit with Restart=always and a RestartSec delay, or Docker with restart: always. Then reboot the server deliberately once and confirm the bot comes back on its own. Most people never test this.

Make your bot’s startup safe. On restart it must reconcile state with the exchange — query open orders and current positions rather than assuming what it left behind. A bot that resumes from local state after a crash can double up a position.

Understand what live migration does. Cloud providers move running VMs between physical hosts for maintenance, which can pause a VM briefly. For a web server that’s invisible; for a bot holding a WebSocket feed it can mean a dropped connection and a gap in market data. Your bot needs to handle reconnection and treat any gap as “re-query state,” not “carry on.”

Alert on silence, not just on errors. A heartbeat that pages you when the bot stops reporting catches the failure mode that error logging misses entirely.

What to actually buy

Given latency isn’t the differentiator for retail bots, the specs that matter are unglamorous: enough RAM that nothing gets killed, a region on the right continent, and billing you can stop.

Cloudzy is a reasonable default here because it bills month-to-month with no term — $8.97 for 2GB, $17.37 for 4GB — and a trading bot is exactly the kind of project you might stop running. Nothing stranded.

AccuWeb Hosting markets specifically to trading workloads and offers a wide spread of regions, which matters for picking the right continent. We haven’t verified its current pricing.

Hostinger is the cheapest capable option — 4GB at $6.49 promotional and $11.99 at renewal, with one-click Docker templates. The trade is that the promotional rate needs a long prepaid term, which sits awkwardly with a project you may abandon.

DigitalOcean is the documentation choice at $24 for 4GB, with a broad region list and predictable APIs. Its tracked link isn’t working on our end, so we’ve named it without linking.

JavaPipe is worth knowing for DDoS-protected hosting if your setup is exposed in a way that warrants it — though a properly configured bot needs no inbound ports at all.

UltaHost gives more cores per plan than most at this price, and unusually its 2-year discounted rate is also its renewal rate.

On sizing: 2GB is enough for a bot polling REST endpoints; 4GB if it holds WebSocket feeds and any local state. Memory is what kills these processes, and when it happens the kernel terminates them with nothing in your bot’s log — which looks exactly like the silent 3am death described above.

If you’re trading FX rather than crypto, best forex VPS hosting covers that market, where broker proximity and platform requirements genuinely differ.

How we checked this

The measurements are ours, which is unusual for this series and worth stating precisely.

On 19 August 2026 we measured TCP connect time using curl‘s time_connect from two servers we control: one in Nuremberg, Germany and one in Ashburn, Virginia. Targets were api.binance.com, api.coinbase.com and api.bybit.com over HTTPS. We resolved each hostname from both locations and looked up the resulting IPs in ARIN’s RDAP registry, which returned AMAZON-CF — Amazon CloudFront — for 3.174.49.178, 13.225.199.163, 13.32.99.91 and 18.238.25.36. Coinbase returned the identical IPv6 address 2a06:98c1:3102::ac40:98f1 from both locations, a Cloudflare anycast range.

The limits of that, stated clearly:

  • Two locations, not a dozen. The brief for this article asked for a dozen data centres; we have two, because those are the two we control. Two is enough to demonstrate that CDN edges terminate these connections, and not enough to build a regional ranking.
  • Single-sample connect times, taken once, not averaged over a period. Treat the individual numbers as illustrative; the finding they support — that both continents reach all three exchanges in under 20ms — is robust to sampling noise because the gap between “CDN edge nearby” and “matching engine 6,000 km away” is an order of magnitude, not a few milliseconds.
  • TCP connect, not WebSocket round-trip. We did not measure order-placement latency or WebSocket message RTT, which is what actually matters for execution and which we cannot measure without funded accounts and API keys on three exchanges.
  • Public REST endpoints only. Exchanges may offer different endpoints, co-location products or direct connectivity to institutional clients. Nothing here describes those.

So the conclusion we’d stand behind: pinging public exchange hostnames from a VPS does not measure your distance to the exchange, and comparison tables built that way don’t support their conclusions. The conclusion we would not draw is a ranking of hosting regions for execution speed — that needs the WebSocket measurement we didn’t take.

The security and restart practices are standard operational advice rather than findings — withdrawal-disabled API keys and IP allowlisting are features the exchanges document, and we have not audited any specific exchange’s implementation of them.

The host links above are affiliate links. The most valuable recommendation in this article — disable withdrawals on your API key — costs nothing and earns us nothing.

FAQ

Does VPS location matter for a crypto trading bot?

Less than every guide claims. We measured under 20ms to Binance, Coinbase and Bybit from both Germany and Virginia, because the public API endpoints are behind Amazon CloudFront and Cloudflare. Pick the right continent, then stop optimising.

How do I test latency to an exchange?

Not by pinging the public API hostname — that measures your distance to a CDN edge. Meaningful measurement needs WebSocket round-trip time against an authenticated endpoint, which is specific to your account and setup.

What’s the most important security setting for a trading bot?

Disable withdrawal permissions on the API key. Trading needs read and trade access only. Set that way, even a fully compromised server cannot move funds off the exchange.

Should I use IP allowlisting on exchange API keys?

Yes. Every major exchange supports it, and it makes a stolen key useless from any other address. It takes two minutes.

How much RAM does a trading bot need?

2GB for a bot polling REST endpoints, 4GB if it holds WebSocket feeds and local state. Running out means the kernel kills the process with nothing in your bot’s log.

What happens to my bot if the provider migrates my VM?

Live migration can pause a VM briefly, which may drop a WebSocket connection. Your bot must reconnect and re-query open orders and positions rather than resuming from local state.

How do I stop my bot dying silently overnight?

Run it under systemd with Restart=always or Docker with restart: always, reboot the server once deliberately to confirm it recovers, and alert on missing heartbeats rather than only on errors.

Founder & Software Review Editor
Axel Grubba is the founder of Findstack, a B2B software comparison platform, with his background spanning management consulting and venture capital where he invested in software. Recently, Axel has developed a passion for coding and enjoys traveling when he is not building and improving Findstack.
Business Software Reviews SaaS Product Evaluation CRM Software
Subscribe, get software deals straight to your inbox.
Join 8,500+ other entrepreneurs staying up-to-date on all the latest deals.
Zero spam. Unsubscribe at any time.