Region beats plan size, and it is not close
Your order travels from your server to the exchange's matching engine and back. That round trip is set by distance and routing, and no amount of RAM shortens it.
Exchange infrastructure clusters in a handful of places: Tokyo and Singapore for much of the Asian order flow, Frankfurt and London for European venues, and the New York and Virginia corridor for US ones. Putting a bot in the wrong hemisphere costs more milliseconds than every other optimisation combined will ever give back.
Two rules that survive contact with reality:
- Pick the region by where your exchange's API terminates, not by where you live. You will connect over SSH a few times a day; your bot connects thousands of times an hour.
- Measure, do not assume. From a candidate server, time the actual endpoint you will trade against before you commit a month to it.
# round-trip to the API host you actually use
ping -c 20 api.exchange.example
curl -w "connect %{time_connect}s total %{time_total}s\n" -o /dev/null -s https://api.exchange.example/timeRun that from a server in two regions for an hour. The difference will be obvious and it will not match your guess.
Why a cheap VPS quietly loses money here
The $2-a-month tier is not a scam, but it is oversold by design: many virtual CPUs share a physical one, and the bet is that most of them idle. A bot that wakes on every price tick is the customer that bet is wrong about.
The symptom is steal time — your process is ready to run and the physical CPU is busy with a neighbour. On a web server that is a slower page. On a bot it is a missed fill, and it will not appear in any log as an error.
vmstat 1 5The st column is the percentage of time your vCPU wanted the processor and could not have it. A few percent under load is normal. Double digits while idle means your compute is a rumour.
Second failure mode, more common than latency: the box runs out of memory during a volatility spike, the OOM killer picks your Python process, and the bot is simply gone. It does not crash loudly. It stops existing, and you find out from your balance.
What to actually run it on
For a single bot on one or two pairs, the constraint is memory headroom, not cores. Our tiers, for reference:
| Plan | vCPU / RAM / disk | Price |
|---|---|---|
| Starter | 1 / 2 GB / 55 GB | $18/mo |
| Standard | 2 / 4 GB / 80 GB | $34/mo |
| Pro | 4 / 8 GB / 160 GB | $62/mo |
Starter is enough for one bot with a modest state. Standard is the honest default once you are running a database, a dashboard and the bot together. Pro starts to make sense when you are backtesting on the same machine that trades — and at that point, consider not doing that: a backtest that pins the CPU is competing with the thing making your money.
Everything is billed by the hour, so a strategy you run only during a session costs only those hours. Destroy it when the session ends and you stop paying; the redeploy takes about a minute.
Keeping it awake
A bot that dies at 3 a.m. and stays dead until morning has cost you more than any hosting decision.
- Run it under a supervisor — systemd or Docker with a restart policy — never under
nohupand hope. - Have it emit a heartbeat, and alert on the absence of the heartbeat rather than on errors. The failure that hurts is silence, not an exception.
- Keep the exchange API keys out of the repository and off your laptop. Environment file on the server, permissions 600, withdrawal rights disabled on the key.
- Log your fills somewhere off the box. When you need them, the box is usually the thing that is broken.
Signing up without a card
The practical reason people rent bot servers with crypto is not ideology, it is that a trading setup and a personal credit card are two things many people would rather keep apart.
On NoctHost the account is an email address. You top up with crypto, the balance pays by the hour, and there is no identity check, no card and no phone number. If you want to automate the infrastructure itself — spin a server up for a session, tear it down after — there are personal API tokens for exactly that, so your deployment script never handles your password.