A dot on a network map can mean several different things. It might be somewhere you can deploy a VPS, a location in the core network, or an edge serving anycast traffic. Treating all of them as a VPS location would give you the wrong deployment plan.
GetVPS runs on AS52025, ParadoxNetworks, the network our team builds and operates. The network page brings those different kinds of presence into one view. Here is how to use it when evaluating a location or planning your own routed service.
Read the three location types
The globe assigns each city one primary marker. Where capabilities overlap, they share that marker rather than appearing as duplicate dots.
| Marker | What it tells you | How to use it |
|---|---|---|
| VPS available | The city is in the live VPS directory | Open the location and check its current plans |
| Core network | The city is part of the displayed core topology, without a live VPS offering | Understand network presence without assuming compute availability |
| Anycast edge | The city is an active anycast location outside those first two groups | Understand the anycast footprint |
Anycast remains a separate capability when a city also offers VPS or belongs to the core network. For example, Amsterdam combines VPS availability with core and anycast presence. Milan is shown as core network and has anycast presence, but it does not currently sell VPS. An anycast marker in Johannesburg does not mean there is a Johannesburg VPS plan.
Those are examples from the inventory at publication. Use the live network directory and location pages for current availability. Planned or inactive locations are excluded from the globe.
Core network is a routing role
The core maps show the links recorded in our network topology. They help explain how the listed locations relate to one another. A city does not need to host customer virtual machines to have a role in that topology.
The lines are schematic connections, not a fibre survey or a live traffic trace. Their shape and length do not establish latency, capacity, or the path your packets will take. The map also does not invent links between every pair of anycast locations.
Open View core network maps below the globe to inspect those relationships. Use the complete location list when you want to compare cities without rotating the globe or relying on marker colours.
VPS availability is a deployment decision
For a VPS, start with a city marked VPS available, then read its location page and available plans. That is where compute availability belongs.
Choose the location using the traffic you expect to serve. A London-based team may still want its application in Singapore if most of its users are there. A secondary DNS server or monitoring node may need a different location from the workload it protects.
Our location-selection guide covers that tradeoff. Test from the networks your users actually use before committing to a placement. Geographic distance is a useful starting point, but peering and routing policy influence the path.
Facility presence and exchange peering are also different facts. A location in an Equinix building does not by itself imply peering on an Equinix exchange. Use the exchange information on the individual location page when evaluating connectivity.
Anycast presence is not automatic application replication
Anycast announces the same service prefix from multiple places. Routing policy selects a path to one of those announcements. It does not promise the geographically nearest server, nor does it copy your application, database, or connection state between servers. The operational distinctions are covered in RFC 4786.
Our anycast footprint describes network presence. Deploying a VPS does not automatically place your application on every anycast edge. If you want to build your own anycast service, choose locations where you can deploy the service and arrange its routing, replication, and health checks explicitly.
The two-edge anycast guide walks through that design. For authoritative DNS, a primary and secondary in two VPS locations is another approach: separate nameserver addresses, without needing your own anycast prefix.
Bring your ASN through the self-service portal
If you hold an ASN and prefixes, BGP setup starts in VPS Control → BGP Sessions. Add your ASN, complete the WHOIS-contact email verification, provision the session for your service address, and use the generated neighbour configuration.
GetVPS operates AS52025, but your own announcement must use the origin ASN you have authorised for your prefixes. Do not substitute the upstream's ASN into your ROA merely because it carries the route.
Check RPKI and IRR authorisation before bringing up the session. Then follow the session walkthrough. The route modes offered in the portal depend on the location; the default-route versus full-table guide explains how to choose among the available options.
Verify the path that matters to you
Use the map to build a shortlist, then gather evidence for the workload:
- Select a live VPS location and identify a suitable test target from its page.
- Measure from representative user networks, separately over IPv4 and IPv6.
- Compare latency, loss, and the application response at more than one time of day.
- For a redundant service, test the second location independently and rehearse losing the first.
RIPE Atlas can add outside vantage points to that process. A network map describes presence; measurements tell you what a particular source can reach at a particular time.