Clipper 8
- vCPU
- 4 × dedicated
- RAM
- 8 GB
- Storage
- 200 GB NVMe Gen4 SSD
- Transfer
- 20 TB
- IPv4 / IPv6
- 1 / /64 routed
Solution
Crypto exchanges concentrate their matching engines in AWS Tokyo (Binance), AWS Ashburn (Coinbase) and a handful of European regions. A trading bot wants two dedicated high-frequency cores, 4–8 GB of RAM, and placement in the same metro as the exchange. Bandwidth is trivial; websocket jitter is not, which is why dedicated cores beat larger shared instances.
| Resource | What you actually need |
|---|---|
| CPU | 2–4 dedicated high-frequency cores |
| RAM | 4 GB for one strategy, 8–16 GB for a multi-pair market maker |
| Disk | NVMe Gen4 — orderbook snapshots are write-heavy |
| Network | Consistent jitter matters more than raw throughput |
Location is usually the decision that matters most for this workload — either because latency dominates, or because jurisdiction does.
Binance and Bybit sit in Tokyo, Coinbase and Kraken in US East, Bitstamp and Bitfinex in Europe.
Four dedicated cores is enough for most single-venue strategies.
taskset plus the performance governor removes a surprising amount of jitter.
systemd with Restart=always, plus a dead-man alert if no order is placed within N minutes.
Use IP-whitelisted, withdrawal-disabled API keys so a compromised instance cannot drain the account.
In the same metro as the exchange's matching engine. Tokyo for Binance, US East for Coinbase and Kraken, Frankfurt or London for European venues. Distance is latency, and latency is slippage.
For cross-exchange and funding-rate arbitrage, yes. For sub-millisecond latency arbitrage you need colocation, not a VPS — and that is true of every provider.
Yes, without restriction. Automated trading is a normal workload here, not an exception that needs approval.