Six nodes, mapped honestly
We're not going to show you a map with three hundred glowing dots — we run six edge nodes and we'd rather you could actually verify that. Hover or tap a node below.
| Node | City | Region | Status | Avg. latency |
|---|---|---|---|---|
| fra-edge-01 | Frankfurt, DE | EU-Central | Operational | 4 ms |
| ams-edge-01 | Amsterdam, NL | EU-West | Operational | 6 ms |
| vil-edge-01 | Vilnius, LT | EU-North | Operational | 7 ms |
| hel-edge-01 | Helsinki, FI | EU-North | Operational | 9 ms |
| sto-edge-01 | Stockholm, SE | EU-North | Operational | 8 ms |
| iad-edge-01 | Ashburn, US | NA-East | Operational | 2 ms |
How routing actually works
There's no fancy anycast magic pretending to be everywhere at once. DNS for edge.zipzy-cdn.net returns the two or three geographically closest healthy nodes, and your resolver picks one — usually whichever answers fastest, which in practice tracks distance pretty well.
Cache misses are pulled over a private link from edge to your origin, not over the public internet, so a slow or flaky origin connection doesn't leak latency into every uncached request.
"We deliberately keep the node count low. Six well-monitored machines beat six hundred we can't reason about during an incident." — from an internal postmortem, June 2026
Health checks every 10s
Each node is probed from two of its siblings, not just from a central monitor that can itself become a blind spot.
30s failover window
A node failing checks for 30 seconds straight is pulled from DNS rotation automatically.
Warm cache, not cold
Popular paths are refreshed on a rolling schedule instead of waiting for the next cache miss.
4x headroom per region
Every node is sized for roughly four times its average peak load.