Network
Inside the Adios Edge Network: Ingress, Compute, and Failover
Fourteen current edge locations bring requests onto the Adios network. Here is what happens there—and what still happens in a compute region.
An edge node shortens the public path into Adios. It does not mean every application process and database runs in that same city.
Where a request enters
Adios currently lists edge locations in London, Paris, Amsterdam, Madrid, Frankfurt, Los Angeles, Miami, New Jersey, São Paulo, Tokyo, Singapore, Silicon Valley, Mumbai, and Chicago. Anycast routing lets those locations advertise the same public network addresses, so internet routing can bring a request into an edge.
At that boundary, the gateway handles TLS and looks up the route for the requested hostname and path. The route identifies the application, release, and traffic policy that should receive the request.
Edge and compute solve different problems
An edge location is the front door. A compute region is where a workload replica runs. Keeping those roles separate lets the routing layer accept traffic near a user while still choosing a healthy replica according to the application's placement and failover policy.
That distinction matters when reading a network map. A green edge marker means Adios can receive and route traffic there. It should not be read as a promise that every workload type or managed data service can be placed in that metro.
- —Edge location: accepts public traffic, terminates TLS, and resolves routes.
- —Compute region: runs application replicas and enforces workload resources.
- —Data region: keeps state close to the application and may have stricter placement limits.
- —Route policy: decides which healthy replica should receive a request.
Growing the useful parts of the map
Dallas, Oslo, Sydney, Hong Kong, Phoenix, Mexico City, Tel Aviv, Dubai, Dublin, Honolulu, Auckland, Kathmandu, and Istanbul are on the planned edge roadmap. They remain marked as planned until traffic is actually being accepted there, and their final metro codes will follow site selection.
The goal is not to collect dots. Each location needs routing, TLS, health checks, private reachability, observability, and a safe withdrawal path when it should stop serving traffic. The automatic health-driven BGP withdrawal loop is still being qualified; a configured BGP session alone does not prove it. A smaller honest network is more useful than a larger map built from promises.
- —Announce and withdraw the anycast route without leaving stale traffic behind.
- —Verify TLS issuance, renewal, and shared certificate state.
- —Measure reachability to every eligible compute region.
- —Confirm that unhealthy gateways leave rotation before users see repeated failures.
What happens when an edge is unhealthy
An edge failure should reduce capacity, not create a new application failure mode. The intended control is to stop advertising when a gateway cannot serve routes safely, then allow internet routing to carry new connections to another available edge. Automated health-driven withdrawal is not yet a completed beta control.
The qualification test is end to end: withdraw one edge in staging, verify that traffic moves, confirm that the replacement edge still reaches the intended workload, and then restore the location without creating a route flap. A healthy process alone is not enough if its private path or route state is stale.