Six locations, one price. The order form does not nudge you toward any of them, so the choice is yours, and the only input that should drive it is where your users are. These are the round-trip times we measure from each site to the places people usually ask about, and a rule of thumb for the cases where the users are everywhere.
What latency feels like
Round-trip time is the delay between a packet leaving a browser and its answer arriving. Under about 30 ms an interaction feels instant. Up to 100 ms is fine for web pages, APIs and most games. Between 100 and 200 ms, pages built from many sequential requests start to feel heavy, and real-time voice becomes noticeably laggy. Beyond 200 ms you want a CDN in front of static content and a server closer to the users for the rest.
A TLS handshake costs two round trips before the first byte, and a typical page makes a few dozen requests, so each millisecond of RTT is multiplied. That is why moving a server from the wrong continent to the right one is the cheapest performance work that exists.
The numbers
Median RTT in milliseconds, measured every hour over the last 90 days from our looking glass to public probes in each city. These are network paths, not application timings.
| To | FRA | AMS | HEL | NYC | LAX | SIN |
|---|---|---|---|---|---|---|
| London | 14 | 9 | 38 | 72 | 136 | 171 |
| Paris | 10 | 11 | 39 | 76 | 140 | 168 |
| Warsaw | 19 | 25 | 22 | 100 | 163 | 178 |
| Madrid | 27 | 28 | 52 | 85 | 151 | 184 |
| Istanbul | 38 | 44 | 55 | 118 | 182 | 190 |
| Dubai | 108 | 116 | 122 | 178 | 246 | 92 |
| Johannesburg | 158 | 165 | 180 | 222 | 280 | 212 |
| New York | 81 | 76 | 106 | 2 | 66 | 232 |
| Chicago | 100 | 96 | 124 | 19 | 52 | 208 |
| São Paulo | 196 | 192 | 226 | 112 | 158 | 320 |
| Los Angeles | 146 | 140 | 168 | 66 | 2 | 168 |
| Tokyo | 228 | 236 | 250 | 160 | 102 | 68 |
| Sydney | 282 | 278 | 300 | 202 | 146 | 92 |
| Mumbai | 118 | 126 | 138 | 196 | 236 | 54 |
| Jakarta | 190 | 198 | 210 | 240 | 184 | 16 |
The looking glass at /network/looking-glass lets you ping and traceroute from any site to your own address, which is a better test than any table.
A site per region
- Frankfurt is the default for Europe, the Middle East and most of Africa. It is our largest site, has every product line, and sits on the densest exchange point on the continent.
- Amsterdam is equivalent for Western Europe and marginally better for the UK and Ireland. Pick it when you want a second European site for redundancy.
- Helsinki wins for the Nordics, the Baltics and Russia-adjacent markets, and is where our storage plans live. Power there is cheap and green, which is part of why the plans exist.
- New York covers the US East Coast, Canada and, surprisingly often, Brazil; it is the best of our sites for South America.
- Los Angeles covers the US West Coast and is the least bad site for Oceania if you cannot use Singapore.
- Singapore covers South-East Asia, India, Australia and Japan. For inference endpoints serving APAC users it saves 150 to 250 ms per request compared with Europe, which is the difference between a chat that streams and one that stutters.
When users are everywhere
The wrong answer is one site “in the middle”; there is no middle of the internet. The right answer depends on what the server does:
- Mostly static content or an API with cacheable responses: one origin (usually Frankfurt or New York) behind a CDN. Users hit an edge near them; the origin's location only affects cache misses.
- Dynamic app with a database: one primary site where the database lives, chosen by where the largest share of users are, and read replicas or cached views in a second site if the second region is large. Do not split a single database across continents.
- Real-time: games, voice, trading, LLM streaming: a server per region, with DNS-based or client-side selection. Two sites (FRA and NYC) cover about 75% of global users under 100 ms; adding SIN covers most of the rest.
Prices being identical everywhere makes the multi-site option cheaper than people expect: two VPS-4 in two regions cost less than one VPS-8 in one, and serve most users faster.
Other things that differ between sites
| Site | VPS | High-frequency VPS | Dedicated | GPU | Storage plans |
|---|---|---|---|---|---|
| Frankfurt | yes | yes | yes | yes | yes |
| Amsterdam | yes | yes | yes | yes | no |
| Helsinki | yes | yes | yes | no | yes |
| New York | yes | yes | yes | yes | yes |
| Los Angeles | yes | no | yes | no | no |
| Singapore | yes | no | yes | yes | no |
The order form greys out sites that do not carry the plan you picked, and shows real stock for the ones that do. Legal considerations matter too: data that must stay in the EU belongs in Frankfurt, Amsterdam or Helsinki, and the site of the server is the jurisdiction the data physically sits in.
Moving later
Choosing wrong is not permanent. A snapshot can be restored into a new server in any site from the panel, and the old server can be cancelled once DNS has moved. The IP address changes, so plan for a short DNS TTL before the move. Most migrations between our sites take under an hour of wall-clock time, most of it waiting for DNS.