For companies that build or operate platforms — aircraft, vehicles, robots, radios, ground control software, connectivity services — and want their customers’ links to behave as one connection. Nexus Atlas is pure software: it is installed on the compute your product already carries and operated from the systems you already run. Your keys, your customers’ networks, your product.
Nexus Atlas is the common layer. Each kind of company below brings the environment in which that layer pays off — and each one maps to an integration pattern further down this page.
Your web application already knows every user and every aircraft. Atlas adds the aircraft’s links as one connection and takes its instructions from your database — add, remove, revoke — without your engineers touching a server.
Pattern 01Ship resilient communications inside aircraft, vehicles, vessels and robots, on the compute the platform already carries — no mandatory networking appliance and no redesign of the platform.
Patterns 02, 03 and 07Expose existing radios as Atlas paths and let them report their own signal and buffer state, so the connection steers by what the radio sees as well as by what the link delivers.
Pattern 04Combine cellular, satellite and private wireless services into one connection, with real diversity across carriers and failure domains.
Pattern 05Use Atlas as the common communications layer inside command, autonomy, sensing, public-safety and critical-infrastructure programmes — read and steered from the systems you already run.
Pattern 06Define the failure moment, the traffic priorities and the environmental constraints that a useful demonstration or pilot must reproduce.
The programmeCollaborate on multi-path transport, mesh coordination, resilient timing and mobility — including defence research institutes and test centres hosting structured evaluations.
Research directionsIf your product carries links, or runs the systems that depend on them, the conversation starts the same way.
Plan a briefingThe aircraft carry two or three cellular modems and nothing else; the ground station is a web application. Atlas runs on the aircraft and on two hubs with public addresses in front of your backend. Each aircraft dials out over every modem to both hubs, so the carrier’s network needs no configuration and losing a hub loses nothing. Commands ride on the two best modems at once; video is paced so it never sits in front of a command; logs wait for spare airtime and are held on the aircraft through an outage until a modem returns. Each customer is its own network with its own keys. Your application adds and removes aircraft through your own database; a removed aircraft is refused by every hub within seconds. The worked example
The companion image carries Atlas and a configuration fragment for the aircraft’s role. The aircraft generates its own key on first boot, and the private key never leaves it. Fleet-wide policy arrives as signed configuration pushes that undo themselves if they cost a node its connection, and a node keeps its identity — address, routes, dashboards — when its keys rotate. One binary on x86-64 and ARM64, with hardened service profiles and automated installation.
The autopilot and its router are not changed. Atlas recognises command traffic by its standard port and by the marks a router sets, puts it in the Control class, and keeps video, telemetry and uploads behind it in their own classes. One binary on the companion computer; configuration in one file.
A small adapter reads the radio’s own signal, noise and buffer state and hands it to the scheduler beside Atlas’s own measurements. Serial telemetry radios carry Atlas traffic directly; Wi-Fi, Ethernet and Bluetooth links report through the same contract, and a new radio family is one more adapter. The radio stays the vendor’s; Atlas only listens to it.
Two or three SIMs become one connection. The session holds when a modem re-attaches with a new address; a metered plan is a budget the scheduler stays inside, counted in the bytes the carrier bills; and a budget never takes away the last working modem. Atlas treats each carrier as a link; it does not need anything from the carrier’s core network.
Everything a node knows — its links, peers, routes, traffic classes and events — is readable from one REST API and an OpenMetrics endpoint, so your command or monitoring system draws it in its own interface. Configuration travels as signed pushes that undo themselves if they cost a node its connection, and the event journal feeds your security monitoring over syslog. No cloud controller sits between your system and the network. A partner who must only watch a mission gets a feed by link, from a gateway that sends outward and opens nothing. the feed gateway ↗
Robot middleware traffic is ordinary IP. Mark the control topics on the robot and the traffic classes keep them ahead of camera and map data; every vehicle relays for its neighbours, up to eight hops, so a vehicle in a radio shadow reaches the controller through another instead of stopping.
A cellular-only aircraft talking to a web ground station has four problems its flight stack cannot solve: one modem is one point of failure; the carrier’s private addressing means the ground station cannot connect to the aircraft; a video stream on a shared uplink starves the command stream; and the ground station must know which aircraft is on the other end, add one when a user clicks “Add drone”, and remove one for good when it is sold or lost.
Two hubs on public addresses in different regions. One Atlas network per customer, with separate keys and addresses, so a customer’s aircraft never learns another customer’s fleet. One Atlas link per modem. The ground station’s backend is a node of the network. Tenancy, drawn — nexusatlas.io
Aircraft are added and removed from the web application, not from a server. A removed aircraft is refused everywhere within seconds. Per-modem delay, loss and which modem carries commands are read from an API and drawn next to the map in the ground station’s own interface. How an aircraft is admitted How one is removed
The hubs’ hosting, the database that maps users to aircraft, the ground station, the flight stack and the video pipeline.
The software on every aircraft and hub, the written design, the configuration for each role, the admission that fits your product — a hook into your database, pairing codes or factory certificates — and the engineering through the pilot.
Your web application can admit an aircraft with a one-time pairing code it shows on screen, your own airframes join by a certificate signed at your factory, and an unknown aircraft can wait in a queue until an operator approves it. The ways in, drawn — nexusatlas.io Every feature’s status — nexusatlas.io
Bring the platform, its links, how your product knows its users and devices, the fleet sizes you expect, and where your customers’ data may travel. You leave with a fit assessment and the outline of the design.
A document your engineers can argue with: topology, tenancy, link plan per platform, registration and removal, lifecycle, what to measure, and a status for every feature it relies on. The worked example above is one of these, in public form.
Software only, on the compute your product already carries and the links it already has. Scope, measurements and success criteria are agreed in writing before it starts.
Nexus Atlas is proprietary software, licensed under a written agreement. Partner terms and support are defined there, not on a web page.
Every pattern on this page describes how Nexus Atlas fits a kind of product; none of them names a company. A partner is named on this site only with its written agreement, and the words are its own. Until then the depth of the design is the evidence.
Bring the platform, its links, how your product knows its users and devices, and where your customers’ data may travel. You leave with a fit assessment and the outline of the design.
