Connect outward
Each node opens an authenticated outbound session to selected Atlas relays. CGNAT normally permits it; no inbound rule is required.
Let drones, vehicles, ground stations, and remote sites find and reach one another across 4G, 5G, and CGNAT—through a direct path when the network allows it, through authenticated relays when it does not, or through both for added resilience. No servers to rent, no port forwarding, and no networking degree required.
A modem can reach the internet without being reachable from another vehicle.
Cellular providers share public addresses across many subscribers. Your node can send traffic out, but another endpoint cannot simply dial back in.
Cell changes, reconnects and carrier policy can replace an endpoint without warning. Static address assumptions do not survive mobile operations.
A classic tunnel normally commits to direct or relay. Nexus Atlas keeps every usable path measurable and available to the same scheduler.
Traversal happens inside the Nexus Atlas data plane, so a change from relay to direct—or back again—does not rebuild the encrypted tunnel.
See the complete connection sequenceEach node opens an authenticated outbound session to selected Atlas relays. CGNAT normally permits it; no inbound rule is required.
The relay provides a working rendezvous path at once and lets the two endpoints exchange candidates safely.
The peers test the real network path together. If traversal succeeds, direct connectivity becomes another measured Atlas path.
Direct and multiple relay routes can stay available beside cellular, satellite, radio, Wi-Fi, mesh, or wired bearers.
The physical connection supplied by a cellular modem.
Second carrier, satellite, tactical radio, Wi-Fi, mesh or wired.
Applications see a normal Layer-3 connection while Atlas chooses how packets travel.
A direct connection and several relay paths can coexist over a single modem. That cellular path set then sits beside every other physical bearer in the secure Atlas tunnel.
The same path inventory can optimize for latency, throughput, predictable failover or delivery confidence.
Send on the path with the lowest predicted delivery time and keep alternatives ready.
Distribute traffic across usable paths according to capacity and operator weights.
Replicate selected traffic across several paths when delivery confidence matters most.
Follow a strict operator-defined order for deterministic primary and fallback paths.
Seven screens tell the whole story — the live fleet, enrollment, alerts, teams, the audit trail and the way in. Every screen is the real product, in your choice of light or dark.
The traversal layer is useful wherever Atlas nodes must communicate through access networks they do not own or control.
Drones, UGVs and ground stations using cellular beside dedicated radio, mesh or satellite links.
Explore scenarioVehicle-to-vehicle and vehicle-to-command connectivity as towers, networks and addresses change.
Explore scenarioOffice-to-office and field infrastructure where fixed public IPs or inbound firewall changes are unavailable.
Explore scenarioAtlas measures public relay candidates from both endpoints and selects the shared set that performs best—not simply the one with the nearest city label.
View live networkTwo observation addresses
Signed relay identity
Two observation addresses
Signed relay identity
Tell us what you need, where you need it, and why the location matters. Demand and operational constraints help us prioritize new relay capacity.
We can deploy dedicated nodes in an organization’s cloud, data centre, edge sites, or sovereign environment. Their addresses and identities can be pinned in customer configuration and kept entirely outside the public nexusatlas.net relay map.
Explore private deploymentHosted relays forward encrypted Atlas frames. Trust comes from cryptographic identities and a signed relay inventory—not from an IP address or an operator promise.
Read the security modelInner IP packets, application payloads, video, telemetry, and command traffic remain encrypted between Atlas endpoints.
Every relay must prove the static identity published in the signed map. Redirecting its address is not enough to impersonate it.
The relay inventory is Ed25519-signed with an offline key, so a compromised serving control plane cannot forge trusted membership.
Relay sessions are disposable forwarding state. The hosted relay does not terminate or persist the encrypted Atlas tunnel payload.
Relays can observe outer addresses, authenticated identities, timing, liveness, and byte counts. We state that boundary plainly.
Each property answers a different question without asking one page to serve engineers, buyers and operators at once.
Deployment, procurement and partnership case.
nexusatlas.ioEngineeringArchitecture, product depth and technical evidence.
nexusatlas.devDevelopersQuickstart, configuration and API reference, evaluation access.
nexusatlas.netTraversalManaged CGNAT traversal and relay network.
console.nexusatlas.netOperationsEnroll nodes and inspect connectivity.
nexusatlas.appDownloadDownload Nexus Atlas for your platform.
Apply as a pilot partner if you have a deployment ready to test, or start evaluating Nexus Atlas Traversal as a future customer. Tell us enough to understand the endpoints, carriers, regions, and operational constraints involved.
Run an early deployment with direct engineering contact and help shape priorities through real-world feedback.
Research architecture, security, deployment options, and commercial fit before committing to a pilot.