Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Endpoints & DNS Load Balancing

Geographic routing, automatic failover, and location-specific endpoints.

Solana Vibe Station serves traffic from multiple geographic locations. By default, our endpoints use DNS-based geographic load balancing so your requests resolve to the nearest healthy location automatically — no configuration required on your end.

You can also bypass the geo-routing and pin directly to a specific location if you want maximum control over where your traffic lands. Both options are described below.

Available locations

Code
Location
Region

ATL1

Atlanta, USA

North America

AMS1

Amsterdam, Netherlands

Europe

How geographic routing works

Our default endpoints are fronted by Cloudflare Load Balancing running in DNS-only mode. We do not proxy your traffic — Cloudflare acts purely as an authoritative DNS responder, returning the IP address of the best location for each request. Once you have the IP, your connection goes directly to our origin servers. No SVS traffic is hair-pinned through a third-party proxy. This allows for the absolute lowest latency connection to our infrastructure.

Two mechanisms work together:

Proximity routing. When your DNS resolver queries one of our load-balanced hostnames, Cloudflare returns the IP of your closest healthy edge location. This happens at the DNS layer based on the location of your recursive resolver, so for the best geographic match we recommend using a resolver near you rather than a distant public resolver.

Automatic failover. Each location is continuously health-checked. If a location becomes unhealthy — during maintenance, an incident, or a network issue — it is automatically pulled from DNS responses and your traffic is routed to the next healthy location. When it recovers, it is added back automatically. This failover is bounded by the DNS record's TTL (currently 10s TTL), so clients may briefly cache a prior result before picking up the change.

Preferred (geo-routed) endpoints

For most users, the geo-routed hostnames are the right choice. Use the standard tier hostname and let DNS route you to the nearest healthy location with automatic failover:

https://<tier>.rpc.solanavibestation.com
https://<tier>.swqos.solanavibestation.com
https://<tier>.grpc.solanavibestation.com

RPC tiers: lite, basic, ultra, elite, epic SWQoS tiers: basic, ultra, elite gRPC tiers: basic, ultra, elite

Example:

These hostnames are the recommended default. You get nearest-location performance and transparent failover with no extra work.

Location-specific endpoints

If you need maximum control over which location serves your traffic — for example, to co-locate with infrastructure in a specific region, to benchmark a single location, or to meet a data-residency requirement — you can target a location directly using its location-specific hostname.

Trade-off: Location-pinned endpoints opt out of DNS failover. If the location you pin to goes down, your requests will fail rather than rerouting to a healthy location. Use these only when deterministic location control matters more than automatic failover, and consider implementing your own fallback logic on the client side.

The location-specific hostname format is:

Examples:

Which should I use?

Preferred (geo-routed)
Location-specific

Routing

Nearest healthy location

Fixed location you choose

Failover

Automatic

None — you opt out

Best for

Most users, lowest latency

Co-location, benchmarking, residency

Hostname

<tier>.rpc.solanavibestation.com

<tier>.rpc.<location>.solanavibestation.com

When in doubt, use the preferred geo-routed endpoints — they give you the best latency and resilience automatically.

PreviousRate Limits/Connection LimitsNextHealth Check API

Last updated