The 14-Eyes alliance, for hosting buyers

Five/Nine/Fourteen Eyes is an intelligence-sharing club, not a hosting statute. It still changes where you incorporate.

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

Who

Five Eyes: US, UK, Canada, Australia, New Zealand. Nine and Fourteen add several European states. It is about signals intelligence sharing, not a single hosting law. Buyers use it as a shorthand when they compare offshore VPS catalogs.

Why hosts mention it

The question is: will a local agency casually share subscriber data with a US process? Corporate domicile outside the club is one design choice. Datacenter country is another. They are not the same. Netherlands is in Fourteen Eyes and we still rack there for AMS-IX. You can pick Iceland or Switzerland instead and still pay the VPS in crypto.

What it does not do

It does not void GDPR, FADP, or local criminal procedure. It does not make a Bitcoin payment invisible. Rank Eyes-membership after AUP, KYC, and coin list, not before.

Prerequisites: deciding whether the alliance list matters for your threat model

The short answer: the 14 Eyes list matters to you only if one specific party can act on your traffic - the government of the country where your server physically sits, working through its own legal process. If your threat model is copyright notices, the question is the host's notice policy, not the alliance. If it is mass surveillance of content in transit, the alliance map is a real filter. If it is a civil lawsuit from a counterparty, retention law and the host's own logging answer more than alliance membership does. So before comparing Reykjavik against Zurich, write down who you are actually keeping distance from.

Three inputs decide the outcome. First, where the data lives: a rack in a non-member country does not help traffic that transits a member backbone, but static data - a database, an archive, a wallet - only answers to the rack's jurisdiction. Second, what the provider itself keeps: no-KYC checkout, token-only signup and an optional email field mean the provider holds little that a foreign request could extract in the first place. Third, which law reaches the operator: BitCloudVPS is operated by Harborline Node Ltd., registered in Saint Kitts and Nevis, so the corporate layer sits outside all 21 alliance countries as well.

Worked down to a decision: if none of the 14 members has jurisdiction over what you host, pick your rack on latency and price - the alliance list is noise. If one does, move the data out of that member's territory, because no provider promise overrides a local court order. Every plan from Nano at $5.49/mo to Max at $60/mo is deployable in Reykjavik, Zurich and Almaty at the same list price, so jurisdiction is a free variable in the choice, not a surcharge.

Auditing a host's jurisdiction claim before you pay

A jurisdiction claim is checkable in about ten minutes, and you should run the check on us too. Start with the legal entity: a host that names a company in a non-alliance country - Harborline Node Ltd. in Saint Kitts and Nevis in our case - publishes it in the terms of service. If you cannot find a legal entity at all, the rack's flag is marketing, because contracts and payment flows follow the entity, not the sign on the building.

Second, separate three layers that sales pages deliberately merge. The entity layer is where the company is incorporated and where invoices originate. The rack layer is the datacenter address, which decides whose police can physically reach the machine. The payment layer is what the checkout records about you. A host can be strong on one and weak on another: an entity in a privacy jurisdiction with racks in London still leaves machines under UK process, and a non-aligned rack paired with a card checkout re-attaches your name at the payment layer. Our setup puts the entity in SKN, offers 21 racks including non-member sites such as Iceland, Switzerland and Kazakhstan, and takes 19 crypto assets with token-only signup, so all three layers can be pulled out of the alliance at once.

Third, read what the provider says it keeps. If the answer to "what do you log" is a paragraph about payment records and abuse tickets, that is a normal, honest host. If the answer is nothing at all, distrust the rest of the page. Finally, test support before the invoice: ask which datacenter code your deployment would carry - for us that is a concrete label like IS-RKV or CH-ZRH - and see whether the answer names a facility or dodges to a country. A host that answers in facility codes has nothing to hide about the rack layer; the dodge is the tell.

How to verify your server physically sits where the order page says

After deployment, spend five minutes confirming the rack. The point is not paranoia: resellers occasionally map one country's IP ranges to another's sales page, and a jurisdiction argument is worthless if the machine is actually in a member state. Four checks, in order of how hard they are to fake.

First, latency. Each of our location cards states a measured RTT - Zurich is about 9 ms to Amsterdam, Reykjavik about 18 ms, Almaty about 80 ms. Run ping ams-peer or traceroute to a known Amsterdam endpoint and compare against the card. An "Iceland" box that answers in 2 ms from Frankfurt is not in Reykjavik; physics does not negotiate.

Second, IP registration. whois the assigned IPv4 and read the netname, country field and the announcing ASN in the inetnum object. Third, BGP origin: dig +short your own IP against a route-views lookup, or check the prefix on a public looking glass, and confirm the origin ASN is the one the provider claims rather than a transit hop. Fourth, traceroute landmarks: from a European vantage point, a path to IS-RKV passes Icelandic or FARICE-adjacent infrastructure, a path to CH-ZRH terminates on SwissIX peers. The hops should be consistent with the peering listed on the location card - FICIX for Reykjavik, SwissIX and DE-CIX for Zurich, KazIX for Almaty.

None of these tests alone is proof, and all of them together are close to it. If your deployment fails the latency check, the honest providers will move you; the ones worth leaving will argue. Keep the traceroute and whois output from the first hour - it is your record of where the machine was when you started.

What each non-14-Eyes rack costs in latency from Europe and North America

Jurisdiction only survives contact with a latency budget, so price the RTT before you commit a flag. The table below uses the measured figures from our location cards, expressed to Amsterdam as the European reference point, with the peering LAN that carries each route.

Read the numbers against workload, not ideology. An interactive service - a VPN edge, a proxy, a chat bridge - wants the sub-20 ms tier, which is exactly where Zurich and Reykjavik sit; at those figures a European user cannot tell the rack from a Frankfurt one. Batch work - backups, sync targets, node services, mail queuing - tolerates Almaty's 80 ms without noticing, and buys the largest jurisdictional distance in the catalog for the same plan price.

One caution the table cannot show: a non-member rack reached through a member-state transit path still exposes metadata about who talks to the box, even if the content stays out of reach. If that distinction matters to your threat model, put the encryption at the endpoints and treat the rack as the place the plaintext lives, not the place it travels through. The list prices do not change with any of these choices - Nano starts at $5.49/mo everywhere, and the annual Nano price is a flat $36.

Troubleshooting a route that is not what you ordered

Symptom: you ordered a non-member rack and the RTT or traceroute says otherwise. The common causes are ordered by how often they turn out to be true. First, you are measuring to the wrong endpoint - a ping to a CDN anycast address measures the CDN, not your rack; re-test against a fixed IP in a known city. Second, your own path is the detour: run the traceroute from two different vantage points, because a saturated peering LAN or a home-ISP routing policy can add 40 ms that has nothing to do with the rack. Third, the IP mapping is genuinely wrong, which the whois country field plus BGP origin check from the verification section will expose - this is the case that justifies a ticket or a move.

Symptom: latency is right but throughput is a fraction of the port speed. On a 10 Gbps uplink such as Reykjavik's, a single TCP stream across 80 ms of RTT caps out well below the wire no matter what the provider does; parallel streams or a test inside the region distinguish path physics from a throttled port. Symptom: the IP is registered to a different country in whois. Registry objects lag re-allocations, so check the BGP origin ASN before concluding anything - a recently reassigned range can carry a stale country field for months.

What none of these fixes: a legal mismatch. If the entity, the contract or the abuse contact sits in an alliance country while the rack does not, no traceroute will help, because process reaches the operator, not the machine. That is why the audit sequence starts with the legal entity - Harborline Node Ltd., Saint Kitts and Nevis - and only then descends to network tests. Verify in that order and you will never troubleshoot the wrong layer.

Dual-homing: keeping a 14-Eyes app tier behind a non-Eyes edge

The pattern that most operators actually end up running is not one perfect rack but two racks with different jobs. The edge - a VPN endpoint, reverse proxy, Tor bridge or WireGuard guard - lives outside the alliance where connection metadata is hardest to subpoena, and the application tier lives wherever its dependencies are fastest, often inside a member state. The design goal is that a subpoena to the app tier yields an encrypted tunnel endpoint and nothing else.

Concretely on this network: a Reykjavik or Zurich edge at ~18 ms or ~9 ms to Amsterdam fronts an Amsterdam or Frankfurt application box over a WireGuard tunnel, with the app tier firewall admitting only the edge's tunnel address. Anything identifying - the domain, TLS certificates, mail - points at the edge; DNS records never name the app box. Backups flow from the app tier to the edge rack or to the storage line (1-5 TB NVMe at $24-$56/mo) rather than to any member-state cloud. Two VPS plans at $8.50 and $13.50/mo cover the pair for most solo operators, and quarterly or annual terms cut 10% or 20% off both invoices.

The limits deserve one honest paragraph. Dual-homing protects against the jurisdiction of the app tier being used to map your users; it does nothing if your own client devices are compromised, and it adds one hop of latency that interactive protocols will feel. It also multiplies the things you must keep alive - two renewals, two sets of SSH keys - which is why the checkout's token-only signup matters: losing the account token on either box is the failure mode ops people actually hit, not a raid.

The Three, Five, Nine and Fourteen, listed out

The lists are nested, and buyers mixing them up pick the wrong datacenter. Five Eyes: United States, United Kingdom, Canada, Australia, New Zealand. Nine Eyes adds Denmark, France, the Netherlands, Norway. Fourteen Eyes adds Belgium, Germany, Italy, Spain, Sweden. The alliance is a signals-intelligence sharing arrangement, not a data-hosting statute - there is no law called 14 Eyes that a host in Germany violates by storing your files. That is why the honest reading of the map is about two different coordinates: where the company is incorporated and where the rack stands. BitCloudVPS is incorporated as Harborline Node Ltd. in Saint Kitts and Nevis - outside every list - and racks servers in 21 locations, some inside Fourteen Eyes countries for peering reasons and some outside, such as Reykjavik, Zurich, Almaty and Sao Paulo. Neither coordinate is a cloak; each is one input to a decision that also involves KYC policy, coin list and AUP.

What locating outside the alliance actually changes

Outside-14-Eyes hosting changes whose legal process reaches the rack first, and how casually subscriber data can be shared. A datacenter in a non-alliance jurisdiction does not receive a domestic request from an alliance agency as a routine paperwork matter; a foreign request has to travel through that country's own legal channels, which takes time and specificity. What it does not change: your own country can still investigate you, payment chains still cluster publicly, and content that is criminal in your jurisdiction does not become legal by crossing a border. In the EU specifically, a 2014 Court of Justice judgment struck down blanket data-retention mandates, which matters for member-state racks regardless of Eyes membership. The practical ranking for a buyer stays: read the AUP first, confirm no-KYC and the coin list second, choose the jurisdiction third. Picking Iceland over Amsterdam moves one variable - treat it as one variable, not as an anonymity plan.

Read enough? Choose the flag, deploy the box

The list of 21 locations is the actionable part: Reykjavik and Zurich for non-EU process on European routes, Amsterdam for AMS-IX density, Almaty and Dubai eastward, Singapore and Tokyo for SGIX and HKIX peering. The SKU price and the checkout do not change with the flag - Starter is $8.50/mo everywhere, Business is $30 list or $24/mo billed yearly, and payment is one of 19 crypto assets with no KYC and an optional email. If the 14-Eyes question was the reason you read this far, the fastest honest test is to deploy in Reykjavik or Zurich and keep the same playbook you would run anywhere: keys-only SSH, default-deny firewall, your own logs policy. Get the $24 Business plan

Retention law versus alliance membership: two different maps

The 14-Eyes map and the data-retention map overlap imperfectly, and buyers who conflate them pick worse locations. Retention - how long a provider must keep traffic data and under what process - is domestic law, judge-shaped, and has moved independently of the alliances: the CJEU's 2014 Digital Rights Ireland judgment struck down blanket EU retention, Romania's constitutional court killed its national law the same year, while several non-alliance countries keep their own retention regimes. A host in a Nine Eyes country with no mandatory retention and strong judicial process can be a better practical bet than a host in a non-alliance country whose retention law nobody has read. How to use this: find the location's actual retention and disclosure framework before ranking it by Eyes membership, and treat 'outside 14 Eyes' as one filter among four or five, never as the answer itself. Within this catalog, the honest way to shop the variable is the location list itself - Reykjavik, Zurich, Almaty and the rest each carry their own legal posture, at identical prices and the same no-KYC checkout, so the comparison costs nothing but reading.

A worked example: Reykjavik, Zurich or Amsterdam for one workload

Concrete beats abstract, so take one workload - a legal publishing site with sources - and run it through three flags. Amsterdam: best latency and AMS-IX density, but EU member, Fourteen Eyes, GDPR regime, and the fastest formal route for European civil process; fine if audience speed dominates. Reykjavik: outside the EU and the alliances, geothermal power, no mandatory retention tradition, and a speech-positive legal culture - the flag people mean when they say offshore in Europe, at the cost of slightly longer paths to continental readers. Zurich: outside the EU but surrounded by it, FADP with judicial oversight on data requests, excellent central-European latency - the middle pick when process quality matters more than alliance membership alone. The exercise makes the method visible: same workload, same plan sheet - Starter at $8.50/mo in all three, $3/mo-effective Nano if the site is small - same 19-asset no-KYC checkout, and the only variable that moved was whose courts and whose sharing arrangements apply to the rack. That variable is worth one deliberate decision; it is not worth letting it make the whole decision.

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.