Where to Run a Trading Bot in Europe

A trading bot has an unusual set of requirements. It is small, it is always on, it cares about the clock, and the cost of it being down for ten minutes is not measured in lost page views. Choosing where to run one is mostly a question of which venue you talk to, and then a question of how you survive the reboot you did not plan.

This is a practical walkthrough for retail and semi professional setups: strategies that place orders through a broker or exchange API, on timeframes from a second upward. It is not a guide to competing at microsecond level, and the section on latency explains why that distinction matters more than the marketing usually admits.

How much does latency really matter

It depends entirely on what your strategy is racing against.

• Strategies on one minute candles and slower. Network latency is irrelevant inside a wide margin. 10 ms or 40 ms to your broker changes nothing about a decision you take once a minute. Reliability and clock accuracy matter far more.
• Strategies reacting to a tick or a book update. Here the round trip starts to show. Shaving 20 ms off an order path can change fill quality on a fast market, and being on the same continent as the matching engine is the first order effect.
• Strategies competing on speed with other machines. This is a colocation problem, not a hosting problem. Firms that play that game rent space in the same building as the exchange and cross connect to it. We do not offer that, and any host that implies a virtual machine in a nearby city is equivalent is selling you a story.

So the honest ordering is: put the bot on the same continent as the venue, then in the closest of our cities to it, then stop optimising the network and start optimising the strategy.

Our five cities, and what they are near

Virtual machines run in five sites. The round trip figures are from our Frankfurt hub and are published on the locations page.

City	From Frankfurt	Sensible when your venue or data feed is
Frankfurt	1 ms	In Germany or reachable well from DE CIX, which covers most European venues and most global brokers with an EU presence
Amsterdam	3 ms	In the Netherlands, the United Kingdom or across the Atlantic, where Dutch transit and AMS IX help
Vienna	4 ms	In Austria or Central Europe, or when the account holder needs the machine inside Austria
Warsaw	7 ms	In Poland or the Baltics
Bucharest	10 ms	In the Balkans, or when the priority is cost and mitigation capacity rather than the last few milliseconds

The way to settle this properly takes five minutes and costs almost nothing. Take the smallest plan by the hour in two candidate cities, run a few thousand pings and a traceroute against your broker endpoint from each, keep the better one and delete the other. An Ion is €0.0063 an hour in Bucharest and €0.0084 in Frankfurt or Vienna, so a two hour bake off across two cities is under three cents of compute.

Sizing the machine

Most bots are small. What makes them grow is everything they carry alongside the strategy: a tick database, a backtesting harness, a dashboard, a message queue.

Plan	RAM	vCPU	SSD	Typical fit
Ion	2 GB	1	20 GB	One bot, a handful of instruments, logs to disk
Pulse	4 GB	2	40 GB	Several bots, or one bot plus a small database
Core	8 GB	2	60 GB	Live trading plus a local tick store and a dashboard
Forge	16 GB	4	80 GB	Live trading on one machine and backtests on the same box
Apex or Titan	24 to 32 GB	6 to 8	100 to 120 GB	Research workloads, many instruments, heavy history

One firm recommendation: do not run heavy backtests on the machine that is trading. A backtest that eats the CPU for twenty minutes is the reason a live order went in late. Rent a Forge or a Titan by the hour for research runs and delete it when the run finishes. That is the pattern hourly billing is genuinely good for, and it costs a couple of euro a month in practice.

Always on means monthly, not hourly

The bot itself should sit on a monthly, quarterly or annual cycle. Our hourly rate is the monthly price divided by 720, so a machine that never switches off costs the same as the month at 720 hours and slightly more across a 31 day month, which is 744 hours. There is no cap on hourly plans, so the arithmetic is the whole story.

The other reason is operational. Hourly servers draw from prepaid credit, and if the credit runs out the server is suspended an hour later. For a machine holding open positions, an invoice you pay once a month is a safer failure mode than a balance you have to remember. If you do keep hourly machines around for research, switch on automatic top up so the balance never decides your trading day.

Surviving the things that will go wrong

Uptime on a single virtual machine is good but it is not perfect, and a strategy that assumes it is will eventually trade on stale state. Design for the interruption instead.

• Make the bot restart safe. State on disk, positions reconciled from the broker on startup, no in memory assumptions that cannot be rebuilt. This is worth more than any hosting decision on this page.
• Watch the clock. Run a time daemon and check it. Signed and timestamped orders fail in confusing ways when the clock drifts.
• Alert on silence, not only on errors. A bot that has stopped placing orders looks healthy to a process monitor.
• Keep a second city ready. A standby in a different site, with the strategy deployed and switched off, turns a site problem into a five minute failover. Our piece on pairing two locations covers how to arrange that pair sensibly.
• Know what you are exposing. The bot needs outbound access to the venue and nothing inbound except your own SSH. The steps in setting up a firewall apply exactly as written, and API keys with withdrawal rights should never sit on a trading box.

What is included

Every plan is a full KVM virtual machine with root access, one IPv4 address, unmetered traffic and a choice of images covering Debian, Ubuntu LTS, AlmaLinux, Rocky and FreeBSD. Extra IPv4 addresses are €1.50 each per month if you want to separate accounts by address, and extra disk is available in 50 GB units at €4 per unit per month for history heavy setups. Power control, a console, a reinstall and a password reset all live in the client panel, so a wedged machine does not need a support ticket.

Getting started

Pick the city closest to your venue, take the smallest plan that fits your memory needs, and measure before you upgrade. Plans and prices are on the VPS page, the per city figures are in our price by location breakdown, and the trading workload page has the summary. If your strategy is latency sensitive enough that the choice between two cities actually matters, tell us which venue you trade and we will tell you honestly whether we are the right shape for it.