Choosing a jurisdiction: twenty-one locations, four continents

Speech posture, retention, peering and latency, then pay the same crypto invoice from any of the twenty-one datacenters.

Published 2026-08-30 · Updated 2026-10-21 · BitCloudVPS Editorial

Pick the threat model first

Latency-sensitive users in Europe usually want Amsterdam. Content that attracts copyright mail belongs in a country that will not treat a US DMCA notice as an order. Banking-grade privacy narratives often land on Switzerland. Cheap electricity and a 2014 retention ruling pull some workloads to Bucharest. The SKU price and the crypto checkout do not change with the flag: you still pay for the VPS or dedicated server with Bitcoin or USDT after you set a password.

Iceland

Reykjavik: geothermal power, a strong speech tradition, no mandatory data retention. Slightly longer path to the continent, useful transatlantic stories. A default for publishing, Tor, and operators who want the rack outside the EU.

Netherlands

Amsterdam is a peering capital (AMS-IX). Fast, dense, EU law. Fine for SaaS, VPN egress close to users, and anything that cares about milliseconds. Not the most aggressive ignore-the-letter story in the set. Crypto checkout still skips card processors and KYC; GDPR still applies to what you put on the VM.

Romania

EU member, no mandatory retention after the Constitutional Court struck it down in 2014, competitive power. A practical middle: EU transit without a German-style takedown reflex. Good for Bitcoin nodes, seedboxes of legal content, and operators who want EU peering without NL density pricing of transit.

Switzerland

Outside the EU, FADP, judicial overlay on data requests, hydro. Use it when the buyer cares about Swiss process more than AMS-IX density. Dedicated servers in Zurich with IPMI are a common pairing for mail and Matrix.

Company vs rack

The contracting company is in Saint Kitts and Nevis. The RAM is in IS, NL, RO or CH. Do not confuse domicile with datacenter. A US DMCA form letter is not a court order in either layer.

Short answer: the five-minute version of this guide

If you only want the procedure: write down who you need distance from, match that against the rack's legal system rather than the marketing flag, then spend what is left of your decision budget on latency and price. Distance from mass surveillance points at racks outside intelligence-sharing members - Reykjavik (IS-RKV), Zurich (CH-ZRH), Almaty (KZ-ALA) are the usual shortlist. Distance from copyright enforcement is mostly a host-policy question, so any of the 21 sites works and you should choose on RTT. Distance from a specific civil adversary is about entity and payment layers, which for us means Harborline Node Ltd. in Saint Kitts and Nevis and a 19-asset crypto checkout with token-only signup.

The second half of the short answer is what you do not need to weigh. Price does not vary by site - Nano starts at $5.49/mo list ($36/yr flat on annual) in every one of the 21 locations, and the coin list does not change by country either. That removes the two trade-offs that make jurisdiction picking exhausting elsewhere. What remains is one question with legal content - whose courts can reach the machine - and one with only engineering content - how many milliseconds your users will feel. Separate them and the choice usually takes five minutes; the sections below are the worked version of each step, with the verification and troubleshooting you should run after deploy.

Prerequisites: four inputs to write down before comparing flags

Jurisdiction comparisons go wrong when people compare countries instead of comparing their own requirements. Before opening any location list, produce four lines of notes. First, the adversary: a rights holder filing notices, a state conducting surveillance, a business counterparty in a dispute, or a platform that might ban your linked accounts. Each is answered by a different layer, and a flag that is strong against one is neutral against the others. Second, the data type: static data (databases, wallets, archives) only answers to the rack's courts, while interactive traffic exposes who talks to the box along every transit path.

Third, the latency budget, because it eliminates candidates faster than any legal analysis: an interactive service needs the sub-20 ms-to-Europe tier, a batch service tolerates 200 ms without complaint. Fourth, the operational reality of who administers the box and from where - a server you SSH into daily from a member country leaks the pattern of your sessions regardless of where it sits, which is an opsec problem no flag fixes. Write the four lines down, then score each candidate rack against them.

Step by step: screening 21 locations down to two candidates

The full catalog is too long to reason about one rack at a time, so screen in passes. Pass one, legal: remove every rack whose country is a party to your threat model's legal process - if your adversary acts through a specific member state's courts, that member's racks are out regardless of price, and there are no prices to weigh because ours are identical everywhere. Pass two, latency: from the survivors, keep only racks whose measured RTT to your user base fits the workload - roughly under 20 ms to Amsterdam for interactive European services, which leaves Zurich at ~9 ms, Reykjavik at ~18 ms and the German and Dutch sites in the single digits to low twenties.

Pass three, peering quality: among the finalists, prefer the rack whose exchange membership matches your traffic. DE-CIX and AMS-IX membership (Frankfurt ~8 ms, Amsterdam under 1 ms) means dense European transit; HKIX and SGIX matter for China-facing and Southeast Asian routes; IX.br matters if your users are Brazilian, where Sao Paulo (~140 ms to AMS) is unbeatable for a Brazilian audience despite looking far on a world map. Pass four, redundancy: pick two finalists rather than one, ideally in different legal systems, and decide which is primary. Our deploy flow prices both at the same list price, so the comparison costs nothing: ../deploy/?kind=vps&plan=starter&location=zurich versus the same URL with reykjavik or almaty is a real A/B you can run for a month at Starter money ($8.50/mo, $7.65 quarterly-effective, $6.80 annual-effective).

Latency and peering budget by region, with the numbers

The table below compresses the location cards into the figures that actually move a jurisdiction decision: measured RTT to Amsterdam as the reference point, the port speed, and the exchange or peering LAN each route rides. Values are from our own cards, checked October 2026.

Two readings of the table. For a European audience, everything in the first two rows is perceptually identical - a user in Paris cannot tell ~9 ms from ~18 ms - so the legal properties of Zurich versus Reykjavik should decide, not speed. For regional audiences, the intra-Asia column matters more than the AMS column: Tokyo to Hong Kong is ~30 ms regardless of what the transcontinental figure says, which is why a China-facing service picks HKG or SHA and not the nominally closer-to-Europe racks. The Americas and Africa rows follow the same rule one region down: Johannesburg (~160 ms to AMS, NAPAfrica peering) is the South African answer even though Cape Town sits on the same list at ~170 ms.

How to verify it worked: proving the rack is where the order page said

A jurisdiction decision is only as good as the deployment behind it, so spend ten minutes after the first boot proving the geography. Check one, latency: from a fixed reference endpoint in a known city, measure RTT and compare against the location card - Zurich should answer near 9 ms from Amsterdam's direction, Almaty near 80 ms, and an "Iceland" box answering in 3 ms from Frankfurt is not in Reykjavik because physics does not negotiate. Use ping and mtr to a fixed IP, never to a CDN anycast name, which measures the CDN's nearest edge instead of your rack.

Check two, registration: whois <your-ip> and read the country field and netname. Check three, routing origin: confirm the announcing ASN on a public looking glass matches the provider's own ASN rather than a reseller's transit. Check four, path landmarks: a traceroute into CH-ZRH should terminate on SwissIX or DE-CIX peers, into NL-AMS on AMS-IX, into BR-SAO on IX.br members - the hop names should match the peering column of the table above. Save the outputs of all four checks with a timestamp. They are your baseline: if a provider ever migrates your VM between sites silently, the delta between the saved traceroute and a fresh one is the evidence, and it takes effect before you need it rather than after.

Troubleshooting: when the jurisdiction you picked misbehaves

Symptom: RTT is far worse than the location card promises. Work the causes in order of likelihood: you are measuring against an anycast endpoint (re-test against a fixed IP); your local ISP is routing the long way (re-test from a second vantage point); or the VM genuinely sits elsewhere, which the whois and BGP checks from the verification section will show - that last case justifies a ticket, and a provider confident in its cards will move or re-provision rather than argue. Symptom: latency is right but a single-stream transfer is a fraction of the port speed. On any transcontinental route, one TCP stream across 100+ ms of RTT caps well below a 10 Gbps wire; parallel streams or an in-region test separate path physics from throttling.

Symptom: the flag is right but your exposure is not what you expected. This is the most common jurisdiction failure and it is not a routing problem: the rack is where you ordered, but your DNS, your payment trail or your daily admin login re-attaches the identity you tried to separate. The fixes live outside this guide's scope - endpoint encryption, separated admin paths, coin choice in the checkout - but recognize the symptom for what it is, because no change of flag will cure it. Symptom: a legal request arrives for a rack you chose for its legal system. Then the honest limits section of this page applies: the rack's courts have the final word over the machine, which is exactly why you screened for them first. What none of these fixes is a regret about the second finalist you did not deploy - which is why the screening procedure ends with two candidates, not one.

Asia on the map: Tokyo and Singapore, and the peering math

The two Asia sites earn their slots through exchanges, not slogans: Singapore peers at SGIX and Tokyo sits on HKIX-adjacent routes, the same real-peering standard as AMS-IX and DE-CIX in Europe. Choose by who reaches the server: Singapore for Southeast Asia and Oceania routes, Tokyo for Japan and Korea. Almaty covers Central Asia without a detour through Frankfurt, and Dubai covers the Gulf. Latency is the honest deciding metric: from Singapore, European sites sit 150-250 ms away no matter which European rack you pick, so the only fix is locating in Asia. Everything except geography is constant across the map: the SKU prices do not change by location - Starter $8.50/mo, Business $30 list or $24/mo billed yearly - and the checkout is the same 19 crypto assets with no KYC and optional email. One caveat worth stating plainly: jurisdiction follows the rack, so an Asia location means that country's process applies to the server, for better or worse depending on your workload. Pick the flag for the law and the latency, and know which one you are choosing for.

The Americas and Africa: Sao Paulo, Cape Town, Johannesburg

The western set exists for the same reason: local peering beats transatlantic detours. Sao Paulo hangs off IX.br - the Brazilian exchange fabric that is among the largest in the world by traffic - serving Brazil and the southern cone; Cape Town and Johannesburg cover southern Africa where European racks add 150+ ms per hop. For audiences in the Americas, these are the western-hemisphere options in the 21; there is no US rack, which is a deliberate consequence of the jurisdiction list rather than an oversight. Workload fit: latency-sensitive regional services belong near their users; legal workloads that want distance from US process get it structurally by not racking there. Prices and checkout are the same as everywhere else on the map - the flag changes the law and the route, not the sheet: storage plans $24-$56/mo for 1-5 TB, dedicated from Start $79.50 to Dedicated Ultra $449.50, VPS from $3/mo effective, all payable in crypto with no KYC. When in doubt between two sites, measure: ping both from your users' networks and let the milliseconds vote.

A decision order that actually works

Twenty-one flags overwhelm until you order the criteria. First, AUP fit: no location helps a workload the contract bans - read it before the map. Second, law: if your workload has a jurisdiction story - copyright mail, speech, retention - that filters to Reykjavik, Zurich, Bucharest or Almaty before latency is even discussed. Third, audience latency: pick the site whose exchange fabric your users' networks reach well - AMS-IX for northwest Europe, SGIX and HKIX for Asia, IX.br for Brazil. Fourth, operational reality: your own admin latency for SSH and maintenance. Fifth, price - deliberately last, because the sheet does not vary by location anyway; what varies is term: month at list, quarter at -10%, year at -20%. The failure mode this order prevents is picking by anecdote - 'Iceland for privacy' applied to a workload whose real constraint is 40 ms to Singapore users. Each criterion eliminates some flags; usually one or two sites survive all five. Deploy takes about 60 seconds wherever they land, and moving later is the migration playbook, not a re-purchase.

Read enough? Pick the flag and deploy

The comparison ends at a dropdown: 21 locations, one price sheet, 19 crypto assets, no KYC, optional email, ~60 seconds to a root shell. Whatever the jurisdiction decision was, the invoice is the same shape - from $3/mo effective on Nano's flat $36/yr. Deploy in 60 seconds

Reading the rack codes: what IS-RKV, CH-ZRH and the other labels tell you before you order

The direct answer: every location on this network carries a code like IS-RKV, CH-ZRH or NL-AMS, and the code is the fastest way to check what you are actually buying — country, city rack, and the facility tier attached to it. IS-RKV is Reykjavik, Iceland, a Tier IV / N+1 site on a 10 Gbps uplink with FICIX peering; CH-ZRH is Zurich, Switzerland, Tier IV with 2N+1 power and a 100 Gbps uplink; NL-AMS is Amsterdam on 40 Gbps with AMS-IX and DE-CIX on the route. The same reading works across all 21 sites, from RO-BUH in Bucharest to KZ-ALA in Almaty.

Use the codes as a pre-order checklist rather than decoration: the country prefix answers the jurisdiction question, the city tells you the latency expectation — under 10 ms to AMS from Frankfurt or Zurich, roughly 30 ms from Tokyo's neighbors in Hong Kong — and the tier note tells you how much power redundancy sits under the rack. Since all 21 locations share one catalog, one no-KYC checkout and the same plan prices, switching a pending order between codes is a dropdown change, not a re-quote — which makes it cheap to revise your jurisdiction choice at the last moment before the invoice, and even afterwards by deploying a second box elsewhere and comparing from the shell.

Where the limits are (October 2026)

Keep the threat model precise. Anonymous-adjacent hosting removes the host-side identity trail: token-only signup, optional email, no KYC review, crypto invoices that record a txid rather than a name. It does not blind the host to traffic it must carry, it does not make a logged-in panel session anonymous, and it does not protect workloads that identify themselves — an admin login from your home IP defeats the whole design. Exact limits of no-KYC anonymity. OPSEC guide. Full checklist. Payment-side note: chain analysis happens on public blockchains, not at the host. Coin choice and network choice are your OPSEC knobs, and the checkout keeps 19 of them open.