Branch
Office to office
Connect private subnets through Atlas without exposing each branch through inbound NAT or firewall rules.
Use case · Remote sites
Connect sites without waiting for public IPs or firewall changes.
Branches, industrial assets, temporary field sites, and remote infrastructure can establish outbound Atlas connectivity over whatever access is available, then use direct or relayed paths automatically.
Deployment patterns
Permanent or temporary, public or private.
The same traversal workflow supports sites on consumer broadband, cellular routers, satellite access, upstream firewalls, or networks managed by another organization.
Field site
Deploy before fixed service arrives
Use cellular and satellite access immediately, then add wired connectivity later as another measured bearer.
Industrial edge
Reach equipment behind managed access
Place the Atlas node at the site boundary and keep downstream systems unaware of relay selection and roaming.
Run Atlas at both network boundaries.
The node provides the stable Layer-3 interface while the underlying links remain ordinary internet or radio connections.
Bring up outbound relay sessions first.
The site becomes reachable without requiring a public address, inbound forwarding rule, or server rented by the customer.
Add direct paths and bearer diversity where available.
A direct route can reduce latency; a second carrier, fixed circuit, or satellite link protects against loss of the original access.
Inspect identities, reachability, and relay use in the console.
Operators can enroll nodes and see connectivity metadata without the hosted traversal service collecting application payloads.
Relay placement
Use the public network—or keep infrastructure within your boundary.
Organizations with sovereignty, latency, isolation, or procurement constraints can combine organization-only relays with direct paths and public geographic redundancy.