How we picked our 31 cities (and why we are still not in some you might want)
The filtering funnel for new pops: jurisdiction, network topology, peering, datacenter quality, legal counsel cost, demand. Cities we considered and rejected, cities coming in 2026, and the ones we will probably never enter.
We get the same email a few times a month: "why no Reykjavík?" or "Dubai is huge for our community, when?" or "any plan for Lagos?" The answer is rarely simple. Adding a city is not a checkout step on a cloud provider. It is a six-filter funnel and most candidate cities die at one of the filters. This post is the funnel, in the order we apply it, with the cities that died and why.
Filter 1 — Jurisdiction
The first question we ask of any candidate city is "what does the law of this country require us to keep?" Mandatory data retention is a hard no. We will not run a pop in a country where the law requires us to log session metadata or content, full stop. There is no version of "we run RAM-only servers but in a jurisdiction that compels logging" that we are willing to ship.
We also weight the country's membership in intelligence-sharing alliances. Five Eyes, Nine Eyes, and Fourteen Eyes countries are not automatic disqualifications — most of our existing cities are in them — but they raise the bar on the next filters. We want our distribution of jurisdictional risk to be diversified. A fleet that is 90% in Five Eyes is not a privacy posture.
This filter alone kills several frequently-requested cities.
- Beijing — the legal regime requires real-name registration and content compliance that is incompatible with our architecture. Not a close call.
- Moscow — geopolitically and legally untenable since 2022; the regulatory environment for VPN providers is openly hostile.
- Dubai — the UAE has aggressive data retention requirements for telecommunications providers; even with a local entity we could not run the architecture honestly.
- Riyadh, Tehran, Hanoi — same general reason, varying details.
Filter 2 — Network topology and peering
A pop is only useful if the path to it is resilient. We look at transit cable diversity: how many independent submarine and terrestrial paths reach the city, and how many distinct providers operate them. A city served by one cable, no matter how big the cable, is a city one fishing trawler away from being unreachable.
This is where Reykjavík fell off our list, painfully. Iceland has excellent jurisdictional properties — we would love to be there. But Iceland is currently served by three submarine cables, and during planning we modeled the impact of any single one going down (which has happened) and concluded we could not commit to an SLA we believed in. Cape Verde and several Pacific island nations failed the same filter for the same reason.
Topology is only half the story. A pop must also be reachable from the major regional internet exchanges with low latency. If our Frankfurt members hit a London pop with 80ms because the chosen datacenter is downstream of two upstreams and not directly peered at LINX, the pop is functionally a worse Frankfurt pop. We require direct presence at the dominant IXP for the region, or peering with the providers who are. In practice this means our shortlist of datacenters is a small set: Equinix in many cities, Interxion in Europe, NTT in parts of Asia, a handful of regional players. We have walked away from cities where the only available datacenter was a tier behind the IXP.
Filter 3 — Datacenter quality
We require ISO 27001 and SOC 2 at the facility level, and we require operational support for our diskless-boot rig. The second one is the hard one. Many otherwise-fine datacenters do not let tenants run PXE on the rack VLAN, do not let us bring our own management network, or charge punitive cross-connect fees that make our architecture uneconomical.
Filters 4 and 5 — Legal counsel cost and demand
For every jurisdiction we operate in, we retain local counsel. This is not a one-time setup; it is a monthly fixed cost. A lawyer in Zurich is roughly four times the cost of a lawyer in Lisbon, and the cost is not optional — when a local court sends a request, we need someone on the ground who speaks the language and the procedure to respond competently within the legal deadline.
This filter is why we have multiple cities in some countries (Germany, the US) and zero in others. The fixed cost of legal presence in a country amortizes across the cities we operate there. Adding a second German city is cheap from a legal standpoint. Adding a first Norwegian city would cost us roughly thirty thousand dollars a year before we serve a single member.
The last filter is the simplest: do enough of our members live in or want to use this region? We track requested-but-unavailable connections in aggregate (no PII, just region counters in memory). Cities surface organically through that signal. Demand is the only filter we will compromise on, and we compromise on it for what we call signal regions — places where we want to have presence even if it is not yet economically justified, because the privacy posture matters to the brand. Panama City, our home, is one of these. Bogotá is another.
Cities coming in 2026
Three cities are in active onboarding for the second half of 2026. They each cleared all six filters and we are working through the procurement and burn-in stages.
- Cape Town — opens up reasonable latency for sub-Saharan members, who have been routing through Frankfurt for too long. Cleared on jurisdiction, peering at NAPAfrica, datacenter quality at Teraco. Counsel retained.
- São Paulo — long-overdue South American expansion. We were waiting on data protection rules to settle and on a hardware vendor that supports our boot path. Both resolved in late 2025.
- Helsinki — replaces Reykjavík in our Nordic-privacy slot. Better topology, comparable jurisdiction. We will lose a little of the symbolic value Iceland would have had, and gain an SLA we trust.
Cities we will probably never enter
Anywhere with mandatory data retention for telecommunications or VPN providers. We get this question about Russia, China, the UAE, India under the 2022 CERT-In directive, and Vietnam roughly weekly. The answer is the same in each case: we cannot run our architecture honestly under those laws, and we are not going to launch a degraded version of ourselves to fit them. Members who want a pop in those regions are better served by a different provider — one with a different threat model.
We would rather have 31 cities we can defend in court and in public than 60 cities with footnotes.
When the answer changes, you will hear it here
Filters move. Cable maps change. Cross-connect prices stabilize. Laws change in both directions. If a city we said no to becomes a yes, we will write about why. If a city we operate in becomes a no — if local law shifts and we can no longer run the architecture honestly — we will say so on the transparency report, in the blog, and on the home page, and we will exit cleanly. The pop list is not a marketing artifact; it is a privacy posture, and we maintain it as one.
Frequently asked
Why not just rent a VPS in every country and figure it out later?+
Because the architecture we run will not survive a non-cooperating datacenter, a single-cable region, or a country with mandatory retention. The filters exist to protect a property — RAM-only, audit-clean exits — that does not survive shortcuts. A VPS pop in a retention country would be a different product wearing our logo.
Can I request a city?+
Yes. The fastest way is to email support and tell us where you are and what you would use the pop for. We aggregate these signals (no PII) and they feed the demand filter. We read every one. We do not respond to every one — usually because the answer is "yes, on the list, no committed date."
Do you operate in any Five Eyes countries?+
Yes — the US, UK, Canada, Australia, and New Zealand all have pops. Five Eyes membership is not a disqualification, because our architecture (RAM-only exits, Panama-domiciled corporate entity, no logs to compel) does not depend on the local jurisdiction being privacy-friendly. Local law cannot compel us to produce records that do not exist. We diversify the fleet across jurisdictions anyway as defense in depth.
What happens to a pop if local law changes mid-operation?+
We have a documented exit playbook. Step one is legal review by local counsel. If the determination is that we can no longer operate the architecture honestly, we drain the pop, decommission the hardware, and announce the exit with a date. The architecture being RAM-only means there is nothing for the new regime to seize when we leave — the chassis is empty.
Run PlanetProxy for seven days, on us.
Same purple tile cards you see on this page, plus the green lock and a 50 ms hop to wherever you want to be.
Start the trial →More from the dispatch
Inside Planet ProxyPP · DispatchWhy we are domiciled in Panama (it is not the cliché)Inside Planet Proxy · 5 minWhy we are domiciled in Panama (it is not the cliché)
Privacy companies always seem to be from Switzerland, the British Virgin Islands, or Panama. Here is the actually-substantive reason we picked Panama, and the trade-offs that came with it.
Inside Planet ProxyPP · DispatchWe rebuilt our mobile app this spring. Here's what changed.Inside Planet Proxy · 6 minWe rebuilt our mobile app this spring. Here's what changed.
A note from inside the design team. Why we threw out two years of UI, what we replaced it with, and the hard choices we made about what to leave on the cutting room floor.
- Inside Planet ProxyPP · DispatchWhy we run our servers from RAM (and what that bought us)Inside Planet Proxy · 7 min
Why we run our servers from RAM (and what that bought us)
Diskless boot, tmpfs everything, every reboot wipes the box. The structural reason we can tell auditors there is nothing to log to — and the operational tax we pay for that property.