Skip to main content

Connections & relays

Connect directly.
Have another path.

Your devices prefer a direct encrypted connection. When a firewall or network prevents that, a relay can carry the same encrypted traffic.

Where the traffic goes

Direct first. Relay when needed.

The controller coordinates identity, policies and connection information. It is not normally the application data path. Permitted devices connect to each other directly where possible; a relay is the fallback.

Direct connection first, encrypted relay fallback Twelve employee computers are enrolled. The highlighted example connects PC04 directly to an authorized company service. If direct connection is unavailable, the alternative path passes through one regional relay. A separate controller exchanges coordination messages with devices; it is not the illustrated application data path. Enrollment does not permit every computer to communicate with every other computer. 12 enrolled computers PC01PC02PC03PC04PC05PC06PC07PC08PC09PC10PC11PC12 Company controllerIdentity, policy and coordination Direct encrypted path Company serviceAuthorized by policy Regional relayForwards encrypted packets Fallback when a direct path is unavailable
One connection, two possible paths. The highlighted PC04 example shows alternatives, not two copies of every packet. Other computers are context, not an automatic all-to-all permission. Dotted lines are controller coordination. On a small screen, scroll the diagram to inspect it.
01 / Direct

Device to device

Two permitted peers exchange encrypted traffic without sending it through a central VPN concentrator.

02 / Relayed

A reachable common point

Both devices reach a relay when a direct path is unavailable. Their traffic remains encrypted end to end.

03 / Controlled

Permission still matters

Enrollment is not permission to reach everyone. Your company’s access policies determine which connections are allowed.

Relay deployment locations

Plan around your people.

Choose locations near your users, offices and services. Multiple regional relay addresses can provide more paths to try when a connection cannot go direct.

33city & metro options
World map showing 33 possible relay deployment locations across six continents. The complete accessible city list follows.
Deployment option, available on request. Approximate metro centers, not facility addresses. Read the city list.
Confirm availability before making plans. Locations verified October 26, 2026. Regional capacity and service availability can change. Alpha deployment and failover testing are agreed with us; this map does not promise an active relay, reserved capacity or an SLA.

North America11

  • AtlantaUnited States
  • ChicagoUnited States
  • DallasUnited States
  • HonoluluUnited States
  • Los AngelesUnited States
  • Mexico CityMexico
  • MiamiUnited States
  • New JerseyUnited States
  • SeattleUnited States
  • Silicon ValleyUnited States
  • TorontoCanada

South America2

  • SantiagoChile
  • São PauloBrazil

Europe9

  • AmsterdamNetherlands
  • FrankfurtGermany
  • LondonUnited Kingdom
  • MadridSpain
  • ManchesterUnited Kingdom
  • MilanItaly
  • ParisFrance
  • StockholmSweden
  • WarsawPoland

Africa & Middle East2

  • JohannesburgSouth Africa
  • Tel AvivIsrael

Asia7

  • BangaloreIndia
  • Delhi NCRIndia
  • MumbaiIndia
  • OsakaJapan
  • SeoulSouth Korea
  • SingaporeSingapore
  • TokyoJapan

Oceania2

  • MelbourneAustralia
  • SydneyAustralia

Map outline: Natural Earth, public domain. Markers show approximate city or metro centers. New Jersey represents the New York metropolitan area; Silicon Valley is a metro area.

More regions, a clear purpose

Relays are one part of the network.

Useful fallback choices

Separate regional relay addresses give clients alternatives when a relay is unreachable. Selection and recovery depend on the client, network and configured addresses; they are not a seamless-failover guarantee.

Capacity follows the path

Direct traffic uses the devices’ own connections. Relayed traffic also uses relay capacity and hosting transfer. We scope location and capacity around the expected workload.

Exit gateways are different

A customer-owned gateway can route configured internet traffic or reach a local network. It needs separate routing and filtering policies. A relay does not automatically provide those functions.

See Alpha scope and planned service options →

A little more detail

Relay questions, answered.

How does a device choose a relay?

It tries the relay addresses offered to it in parallel, up to seven at a time, and keeps the first successful connection. Handshake time can reflect distance, network conditions and server load. It is a practical reachability race, not a guarantee of the lowest latency or fastest end-to-end transfer.

Does it keep checking for a faster relay?

A working home-relay connection is retained. The pinned client does not continuously benchmark every region or move an established connection just because another relay might be faster. On failure, it first tries its previous relay when still available, then selects again with retry backoff.

What if two devices choose different home relays?

They agree on one common relay for their connection using a deterministic peer rule. One device can connect to the other device’s selected relay. The path is not device → Seattle relay → Atlanta relay → device. “Home relay” describes a device’s maintained relay connection, not a requirement to use two relays for every conversation.

Is QUIC versus WebSocket the same choice as relay location?

No. Relay location and transport are separate choices. In the pinned client’s default automatic mode, QUIC and WebSocket connection attempts race. Network restrictions and transport settings can affect which succeeds.

Can the relay read my files or act as an internet exit?

The relay forwards the encrypted peer traffic; it does not decrypt the WireGuard tunnel or become a content filter. An exit gateway is a separately configured device that routes selected internet traffic. Firewall or DNS filtering needs its own configuration. Relay operators can still observe connection metadata and traffic volume.

Do additional relays make the controller highly available?

No. Relays provide additional data-path options. Controller availability, backups and disaster recovery are separate designs and service options. Adding relays does not make the controller redundant, and a relay outage is not the same as a controller outage.

Are all these locations running VPNnet relays now?

No. These are locations where a relay deployment can be requested. VPNnet is in controlled Alpha. We confirm regional capacity, service availability, configuration and evaluation scope before deployment. The map is not a live-status or coverage map, and no relay is created by visiting this page.

Selection details describe the pinned NetBird 0.81.4 client used for this Alpha. Actual deployed versions and network conditions must be checked for each evaluation.

Start with your locations

Where does your team need to connect?

Tell us where your users and resources are. We will discuss direct connections, relay options and a practical early-access evaluation.

Explore home and business examples

Request early access