Where to Host Your Pinnacle Arbitrage Bot (Short Answer: Dublin)

Short answer: Dublin (AWS eu-west-1 or Azure North Europe). Why the region decides your bot's latency, and what hosting across an ocean costs in milliseconds.

Where to Host Your Pinnacle Arbitrage Bot (Short Answer: Dublin)

If you want the answer without the reasoning: host the bot in Dublin, which in practice means AWS eu-west-1 or Azure North Europe, and consume the feed over a push transport. The rest of this post is why that one deployment decision is worth more than most code optimizations you could make. It is the companion to our Python arbitrage bot walkthrough: that post is how to build the bot, this one is where to run it. Scope note as always: pinnapi is a data feed, not a sportsbook, and a bot built on it is consuming prices, not placing bets through us.

Why milliseconds decide an arb bot

An arbitrage or value strategy on Pinnacle data is a race with a simple shape: the sharp price moves (a steam move, an injury repricing), soft books adjust seconds to minutes later, and the edge lives in between. Your bot's job is to see the move the moment it happens, compute fair value, and act before the window shuts. Every millisecond of delivery delay shortens the usable window, and a polling loop typically trails the price by half a second or more before your code even starts, which is why the bot walkthrough insists on the stream. Push delivery gets a price change to your handler in tens of milliseconds.

What decides whether those tens of milliseconds actually materialize is geography, because below all software, latency has a physical floor: light in fiber takes time, a transatlantic round trip typically costs 70–80 ms on its own, and reaching Asia from Europe can add 200 ms or more. You cannot optimize your way across an ocean. You can only decide not to put one in your signal path.

Why we built in Dublin

pinnapi's ingestion runs in Dublin, and we did not pick it for the scenery; we measured. When we traced where Pinnacle's odds actually enter the network, the trail ended in Dublin, so that is where we put our racks. To be precise about what that claim is and is not: it is our own network verification, not public record. Pinnacle's public edge sits behind a CDN, so nobody outside can point at a building, and we make no claims about their company, offices, or headquarters. What we observed is where the data enters the network, and it enters close to us.

You do not have to trust our tracing, because the arithmetic checks it independently. Our published end-to-end figure is a median of 22 ms with a p99 of 41 ms, frame to a nearby client, methodology open at the latency benchmark. Set that against the physics above: if our ingestion sat on the US East Coast, the transatlantic round trip alone (typically 70–80 ms) would exceed the entire median before a byte was processed. A 22 ms end-to-end number is only physically possible when the whole path, from the book to our rack to the client, stays inside one region. The benchmark proves the proximity whether or not you believe a word about the tracing.

The chain: book to feed to bot

An arb bot's signal path is a chain with three legs: book to feed, feed to bot, bot to decision. Every leg adds distance, and distance adds delay. Host the bot in Dublin and all three legs sit inside one metro area. Our published 15–40 ms band is measured to a nearby European client; a bot inside the metro sits at the floor of that band, because the network leg drops to a millisecond or two and what remains is mostly our processing and fan-out.

The practical menu:

• Dublin is number one: AWS eu-west-1 or Azure North Europe. Both regions run in Dublin (public, documented facts of those platforms), and either puts your bot in the same metro as our racks, at the floor of the band. Expect figures around our 22 ms median or better; nothing else on this list beats it.
• London is the near-second if the rest of your stack already lives there. The extra hop adds roughly a 10 ms round trip on top of the end-to-end band, so budget roughly 25–50 ms rather than 15–40.
• The US East Coast adds a typical 70–80 ms transatlantic round trip to every price before your logic starts. Asia, materially more.
• If the team or the dashboards live elsewhere, split the deployment: run the decision logic in Dublin and ship conclusions home, not raw prices. A verdict crossing the ocean costs your strategy nothing; every price update crossing it costs the window.

The honest nuance: your other data leg

An arbitrage bot has a second data leg we do not control: the soft books it compares against, and their endpoints are scattered across providers and regions. Two things keep Dublin the right call anyway. First, western Europe remains central for European-facing books, so the scattered leg tends to stay short from there too. Second, and more important: the sharp reference line is the latency-critical leg, because the Pinnacle move is the signal. The soft-book side is where you act, and those windows are seconds, not milliseconds (how fast books follow). Whether you are arbing or simply following the line, the race is won or lost on the reference leg.

Two more practicals. Use the push transports, SSE or WebSocket, because a polling loop reintroduces the interval delay and throws away the location advantage regardless of region. And do not over-buy hardware: an arb bot's work is parsing and arithmetic, so a modest instance in the right region outruns a large one in the wrong region. Network position matters far more than CPU.

The ritual that closes every latency discussion on this blog: every number above, ours included, is a hypothesis until you measure it from your own box. Spin up the smallest instance eu-west-1 offers and check.

Takeaway

Where you host is a strategy decision disguised as an ops detail. The signal path is book to feed to bot; we shortened the first two legs by building where the data enters the network, and the third leg is yours. Put it in Dublin (AWS eu-west-1 or Azure North Europe), consume the stream pushed, and the whole chain fits inside the published 15–40 ms band. Then measure it, because that is the house rule.