Everything the platform does, in plain language.

Multi-link bonding

Each link is an independent, isolated path with its own queue and watchdog — a wedged link never blocks the rest. Six dissimilar link types have been bonded on one field node.

Heterogeneous bearers

Any IP-capable transport joins the bond: satellite, cellular, microwave, Wi-Fi, 802.11s mesh, Bluetooth, serial telemetry radios via PPP, wired — each with a declared capacity — from a few kbps to multi-gigabit links — that the scheduler respects.

Transparent to applications

Applications see a normal Linux network interface. Command links, video, SCADA and voice run unmodified — no SDK, no integration project.

Smart fragmentation

Large packets are fragmented and reassembled across MTU boundaries, so a full-size frame still crosses a narrow serial-radio link. Out-of-order arrival is handled; applications never know. When a link cannot take every piece of a packet, the rest of that packet is withdrawn from it, pieces already queued included, so no airtime goes to a packet that could never be put back together.

Endpoint roaming

A link whose public address changes mid-mission — a cellular modem crossing carriers, a moving vehicle — keeps its tunnel without a reconnect. Only cryptographically verified traffic can move an endpoint.

IPv6 underlay

Links and peer endpoints may be IPv6; radios on IPv6-only carrier networks bond without translation layers. The inner tunnel is IPv4 today — a stated boundary, not a footnote.

USB resilience

A re-enumerated modem or radio — an unplugged USB hub, a power blip — is detected and rebound automatically. No daemon restart, no operator action.

Eight scheduling strategies

Best delivery time, weighted distribution, strict priority order, broadcast, hop-count — and three adaptive modes that escalate redundancy from one to two to three simultaneous paths as loss or latency worsens, then scale back when conditions clear. The interference-adaptive mode is the live demonstration mode.

Redundancy arithmetic

Three independent links each losing 2% of packets yield 0.0008% effective loss in broadcast mode. In the scripted demonstration, three links forced to 30% loss delivered roughly 2.7% effective loss end-to-end.

Gradual, non-binary failover

Load shifts in proportion to measured quality, on a cadence typically configured between 0.1 and 0.75 seconds. A response cadence, not a universal recovery guarantee — and by the time a link actually dies, the traffic has usually already left.

Bonding tax, measured

The daemon measures its own added latency continuously and publishes it: p50 0.18 ms, p95 0.42 ms added in the reference measurement. A reproducible number, not a slogan.

Aggregation, measured the strategies ↗

When the mission needs throughput, the weighted-distribution strategy adds links together: two 100 Mbit links carry about 181 Mbit/s — twice one link, 95% of their combined capacity. The default strategy sends each packet over the best single link instead, because most fleets bond for continuity first; aggregation is a one-line choice of strategy.

Near real-time, end to end

The whole control loop runs at sub-second cadence: every link measured four times a second, traffic reweighted on a cadence typically configured between 0.1 and 0.75 seconds as quality changes, mesh routes recomputed the moment a change is detected (≈1.5–1.75 s at default probe settings for a lost node) — while the bonding pipeline itself adds about 0.18 ms (p50, self-measured). Decisions are made per packet, on current evidence — never on last minute’s averages. A response cadence, not a universal recovery guarantee.

Metered-link budgets

A satellite or cellular link can be given a monthly allowance. Once it is spent the scheduler stops preferring that link while anything else is usable — but still uses it when it is the last path left, because running out of budget is not the same as running out of connectivity.

Self-healing mesh

Nodes flood a shared topology view — costs, liveness, prefixes, positions. When a node joins, moves or is lost, the topology refloods and every node recomputes independently — within whatever detection costs, ≈1.5–1.75 s at default probe settings. No controller anywhere.

Multi-hop relay

Traffic routes through other nodes — not just across the links on one node — eight hops by default, re-encrypted at every hop. The limit is a setting, not a ceiling — a long relay ladder or convoy raises it — and the count is Atlas’s own: hops inside a MANET or 802.11s mesh underneath are not counted. Relay nodes are trusted, authenticated members of your fleet — stated plainly, because your security review will ask.

Disjoint-path delivery

Two or more disjoint routes per destination; critical traffic rides all of them with receive-side deduplication. The demonstration shows zero-loss relay failover at twice the backbone cost.

One stream, many watchers

When several stations watch the same drone feed across the mesh, the scarce hops carry it once — not once per viewer. The network computes where the watchers’ paths diverge from the topology it already floods and duplicates the video only there; a feed nobody subscribes to costs nothing at all, and the tree re-forms as the fleet moves — no controller, no multicast infrastructure to stand up. Measured on an eight-node verification rig — an ISR aircraft, two layers of drone relays, three subscribed ground stations: five minutes of video at full-HD rate — 6 megabits per second, 187,500 packets — crossed the mesh with at least 187,454 of the 187,500 packets arriving at every station. The scarce first hop carried exactly 187,500 copies — one per packet — where sending each station its own copy would have tripled that, and the copies tripled only at the junction where the stations’ paths separate. However many stations watch, the scarce hops carry the stream once — the cost of the trunk does not grow with the audience. Opt-in; delivery stays video-shaped — losses repaired by forward error correction, never by retransmission storms. How the tree is computed — nexusatlas.io

Operator-pinned paths

For rehearsed operations, routes can be pinned statically — fully deterministic behavior when predictability matters more than adaptation.

Control takes the path with room the second shortest path ↗

A relay that is busy carrying video is not where a command should wait in line. Every node tells the fleet how loaded each of its links is — how full it runs and how long packets queue on it — and command traffic takes the path with room, even when a shorter one exists, while video and bulk data keep the shortest. Every node works from the same shared figures, so the two paths never hand traffic back and forth, and no capacity is set aside in advance.

Gossip configuration

Push a configuration change at any node — it reaches every node over the encrypted tunnels themselves. A new node joins with a bootstrap peer and a shared secret, not a hand-edit on every box.

Live positions

Three position sources — static configuration, a live GPS feed, or operator entry on the dashboard. Park a relay vehicle, type its coordinates, and every peer’s map updates.

Roles across the fleet

Each node can declare what it is — ground station, UAV, UGV, USV, dismount, relay — and a fleet-wide policy change can target roles, so one push tightens the drones without touching the ground stations. The topology views use the same roles to draw the right symbol.

Mesh DNS no name server ↗

Type ssh isr02.narva instead of reading an address off a laminated card. Nodes already share who they are and where they are reachable, so every node answers name lookups locally, from its own copy of the fleet — there is no name server anywhere in the mesh to lose. Names keep resolving when reachback is gone, and when a network partitions, each half keeps resolving its own half. Split-horizon overrides keep existing corporate hostnames working over the tunnel, and a mesh-only mode fits EMCON postures: no query ever leaves on an uplink. Opt-in, and honest about its boundary: names resolve only inside the tunnel — and the tunnel itself never depends on a name lookup.

Control traffic that fits the bearer

Membership updates are paged, and a page fits a single UDP datagram by construction — losing one costs a page, never the roster. Measured to fit a 250 kbit tactical bearer.

Join networks you do not run the seam ↗

A partner runs one network and an agency another; your job is to connect them. Your node joins each as an ordinary member, under that owner’s rules, and bridges the two: hosts on one side reach the chosen hosts on the other at addresses of their own network, with nothing installed, configured or renumbered on any of their devices. Neither network learns the other’s topology or keys, each owner decides which of its hosts take part, and each can revoke you like any other member. Where every node is yours, the answer is simpler still: one network.

Modern authenticated encryption

Noise IK handshake; X25519 key agreement, ChaCha20-Poly1305 authenticated encryption, BLAKE2s — the cryptographic family of WireGuard and Signal. Always on; there is no unencrypted production mode.

The suite is the default, not a lock-in. The security subsystem is built so the primitives behind the handshake can be exchanged without changing the protocol — the engineering basis of the FIPS and post-quantum tracks — and Atlas composes freely with the encryption you already trust: end-to-end tools inside the tunnel, or an outer layer such as IPsec or MACsec around it.

Zero-loss key rotation

New keys are negotiated make-before-break every 2 minutes or 1 GiB, with the previous session kept warm for in-flight packets — measured at zero packet loss across rotations. Across a fleet, a node’s long-term keys and the shared secret change on the same principle, on a schedule no node has to be online for.

Nothing readable on the disk

Turn it on and every file a node keeps about its work — the event journal, carried data, dashboard accounts, configuration history, crash records — is encrypted under one key of the node’s own, which can live off the disk entirely: on removable media, or supplied at boot. Pull the disk without that key and it gives up none of the node’s traffic history, carried data or dashboard credentials. One command, atlasd zeroize, crypto-shreds the node: the key is destroyed, the node’s own keys are overwritten, and it stays inert until it is provisioned again.

Names, not keys the node record ↗

A node is known by its name, and a name can carry more than one key. A key is replaced, then retired, without the node leaving the fleet and without a single route changing. The records are signed and reach every node on their own. The keys can come from your own key-management process, while Atlas manages the names.

A sensor cannot become a relay what a member may do ↗

Each node’s record says what it may do: whether it may carry traffic for others, which kinds of traffic it may send, whether it may change the fleet’s settings, and how much of the fleet it may see. A new node gets the least. A captured sensor is still only a sensor: nothing is routed through it, its traffic cannot claim command priority, and it cannot sign a configuration.

Every hop enforces the record clamped at every hop ↗

A node’s record says which classes of traffic it may send and whether it may relay, and the fleet enforces that at every hop, not only at the first. A relay cannot raise a packet’s class or forge where it came from: the next hop clamps the class to what the sender’s record allows and counts what it clamped, and a packet forwarded by a node whose record forbids relaying is dropped. With end-to-end sealing the destination checks class and sender under the seal and refuses a packet whose class or origin changed on the way.

Replay protection

A 2048-entry sliding window per session rejects replayed traffic — the same mechanism deduplicates broadcast-mode copies.

Pluggable peer authorisation

A static allowlist, a hot-reloaded keyfile, an external command hook wired to your identity systems, or a signed list of node records. Nodes are added and removed without restarting anything: a node taken off the signed list loses its live connections on every node at once, and with the other methods a removed key gets no new connection and one command ends the ones it still holds. Every failure mode fails closed.

Four ways in, each one logged the modes ↗

A new node gets in one of four ways: a one-time pairing code that admits one device, once, with the least it needs; a certificate from your fleet authority, so units built at your factory join with nothing to edit on any hub; its key plus a second secret, so a stolen key alone opens nothing; or an operator approving each request from a queue that shows who knocked and from where. A hub that admits a device but cannot sign the fleet’s list hands it to one that can. Nothing gets in by accident, and every admission is recorded with who made it.

Join by code, addressed by the hub the code ↗

A pairing code is more than a secret. Under its signature it carries the keys the fleet’s list is signed with and both tunnel addresses — the new node’s and the hub’s. A node invited by a hub that cannot sign still knows whose list to trust, takes the signed list when it reaches it and is reachable at the address the code named, with nothing derived or guessed. A code for a pool of addresses hands out the next free one at admission, and the node runs on it from its first start — no restart in between.

The hub tells the fleet before it tells you forwarded to an author ↗

A hub that admits a node but cannot sign the fleet’s list does not keep the record to itself. It hands the record to a node that can sign — over the session to a neighbour, or sealed end to end across several hops, so the relays between cannot read it — and the author checks it under its own policy before signing it into the next list, which reaches the fleet about a second after the admission. No hub can hand out a right it does not hold itself. Where the author prefers, forwarded records wait in its queue for an operator to approve.

Removal that holds how removal works ↗

Pick the nodes to remove — one command, or one action on the dashboard — and they are out everywhere at once. Every node ends its connections with them and refuses them from then on, the hosted relays refuse them too, and the fleet’s shared secret is replaced, so what a removed node knew stops being useful. A removed node cannot come back under the same identity, and every removal is signed, numbered and recorded in each node’s log.

Signed routing how routes are signed ↗

In a fleet of signed node records, every route a node learns was signed by the node that announced it, and every node checks that signature against the announcer’s record before the route counts. A device outside the fleet, or one just removed from it, cannot steer traffic, make a dead link look alive or speak in another member’s name: what it sends is dropped and counted. A flood of fake connection attempts is turned away before it costs a node real work.

Remove by area, or wipe on command the polygon and the wipe ↗

Draw an area on the map and the nodes last seen inside it come back as a list, each with the age of its position; the operator confirms, and exactly those nodes are removed everywhere at once. Each node can also carry a signed operating area: taken outside it for longer than a grace time, it cuts itself off or wipes its own keys, as the operator chose, and a node without a position fix never acts, because a jammed receiver proves nothing. One signed command wipes a node remotely and removes it from the fleet in the same step.

Hop honesty sealing ↗

Direct peer traffic is end-to-end encrypted. Mesh relays re-encrypt per hop and are trusted nodes of your own fleet. Hosted Traversal relays forward envelopes they cannot open. Three different boundaries, stated as three different facts.

Where a relay may be a captured vehicle, an unattended mast or a partner’s node, seal the payload end to end: the sender encrypts each packet for its destination alone, so every relay on the path forwards what it cannot read, with no handshake to carry across the mesh. Sealing covers traffic addressed to one destination — broadcast and multicast stay protected hop by hop — it is not combined with forward error correction, its key does not rotate the way session keys do, and it carries no replay check of its own, so a relay can resend a sealed packet it cannot open.

No controller, no cloud

Every node is autonomous and carries everything it needs: its full configuration, its own view of the topology, its own decisions. There is no orchestrator to stand up, no cloud that must be reachable, nothing that phones home. Autonomy is the architecture, not a fallback.

Works fully offline

Yes — completely, and by design rather than as a degraded mode. The data plane needs no internet at any point in its life: not to install, not to start, not to keep routing. Air-gapped networks, disconnected sites and denied environments are first-class operating conditions, and a partitioned network keeps operating on both sides of the split. The only components that touch the outside world are the optional hosted services — Traversal relays and the fleet console — and losing them costs visibility, never connectivity.

Web dashboard on every node

Links with live delay, jitter, loss, capacity and queue depth; live topology, as a graph or on a map; the scheduler’s actual decisions, explorable after the fact; a timeline that replays what every link, route and peer was doing at any moment, from the node’s own event journal; alerts when a link dies, a node goes quiet or a change reverts; traffic-policy editing; a position editor. Each node keeps its own accounts with hardware-key (FIDO2) sign-in, and can hold the whole dashboard behind a full-screen sign-in. A device that asks to join waits in an approval queue on the dashboard, with approve and deny one click away. Draw an area on the map to pick the nodes inside it for removal. A high-contrast theme stays readable in direct sun. A browser, not an SSH session.

Plain-text configuration

One human-readable TOML file that lives in your version control and ships through your existing automation. Traffic policy reloads live, and so do scheduler and link-measurement settings; the daemon validates configuration at load time and warns about field-known mistakes. For tooling that works in other formats, the atlas-config tool exports the configuration as JSON, YAML or XML, with keys withheld, and imports it back onto the TOML with your comments kept — the node itself reads only TOML.

Configuration wizard & mesh-wide rollout the live view ↗

A guided wizard builds a node’s configuration and rolls changes out across the fleet over the Atlas mesh itself — there is no central controller to do it for you — while tracking the rollout as it spreads: which nodes have received the change, which have applied it, and how far the propagation has reached. Watch the change reach every node on the network map, see at once who is holding it, and play any past rollout back from the start. The wizard also runs offline, serving the same interface on an air-gapped machine.

A push never strands an aircraft the release gate ↗

Mark the nodes a change must reach, and a release is not complete until each of them has confirmed it. If one of them is silent or has failed when the deadline comes, the change is withdrawn on its own — the previous settings go back out, signed, to everyone — and the operator is told which node held it. Nodes marked best-effort take the change when they are next seen and never hold anyone up; a node that must stay on a known build is left where it is, and shown as such.

Keys change without a flag day the three steps ↗

A node’s keys and the fleet’s shared secret change on a schedule every node acts on when it holds it: new keys are accepted before they are used, and the old ones are kept until every node that matters has moved. A vehicle out of contact for a week comes back on its old key, receives the new one over its first connection and switches by itself, with nobody doing anything; one that stays away past the end is refused everywhere and rejoins the way a new node does.

Changes that undo themselves commit-confirmed ↗

A configuration change goes in on probation: unless it is confirmed — by the operator, or by the node reaching its peers again — it reverts on its own, even across a crash, so a bad change cannot cut you off from a node you reach only through it. Fleet-wide changes travel signed, and a node applies only what an authorised key has signed; a change can go to a few canary nodes first and reach the rest once they have applied it. Tuning changes take effect without a restart, so the tunnel never drops.

CLI & structured logs

Status, statistics and a live terminal monitor for headless estates; structured logs with configurable verbosity to journald, syslog or any aggregator.

REST API

The same telemetry the daemon uses internally — links, topology, scheduler decisions, traffic policy, positions — exposed for your NOC and C2 integrations.

Hosted console

Enrolment by one-time code with cryptographic proof-of-possession, nodes on a live map, per-link telemetry, offline alerts with recovery notices, organisations and roles, an audit trail, hardware-key second factor.

A config that cannot start is refused before it runs the pipeline ↗

The configuration has a published schema, generated from the daemon’s own types and served by the node, so an editor completes and checks keys as you type and the dashboard’s form is built from the same source. config check runs the daemon’s exact load pipeline without starting it and lists every finding with the key it concerns, an exit code and JSON a pipeline can act on. The misconfigurations that bite in the field — two links sharing one port, a single-address NAT-test server list, mismatched address families, inert knobs — are caught at load time with a plain-language warning. A change that passes goes in on probation and reverts itself unless confirmed; export and import in JSON, YAML and XML happen outside the daemon.

Feeds your existing monitoring

The daemon speaks Prometheus/OpenMetrics on its own endpoint, so link quality, session state, traffic classes and the bonding overhead land in the monitoring system you already run. No exporter process and no second agent to keep alive on a remote node.

Feeds your existing SIEM

Operationally meaningful events — a link going down, a session tearing down — are exported as RFC 5424 syslog or ArcSight CEF to a collector of your choosing. A collector outage drops and counts events rather than slowing the node down.

A health check that means something

One endpoint answers whether the daemon is alive, whether its data path is actually being serviced, and whether anything is reachable — separately. A daemon whose data path has stalled reports unhealthy even though the process is still running — the case ordinary process checks miss. An idle-but-serviced tunnel stays healthy by design: a node whose peer is legitimately offline is a healthy node with nothing to talk to.

One-file escalation

A single command, or one button in the dashboard, packages configuration, statistics, health, the event journal, scheduler decisions and any crash reports into one archive for support. The configuration is filtered by an allowlist, so keys and credentials never leave the node — including keys a newer version might add.

Crashes that explain themselves

If the daemon ever dies, the failure is captured inside the dying process, stripped of keys and secrets as it is written, and stored on the node under a hard size limit. Sending it anywhere is a separate decision, off by default: a report can go attributed, anonymously, or be forwarded by a neighbouring node for a radio-only device with no route to the internet at all. Identical failures group together automatically, so a fleet-wide bug reads as one problem rather than fifty — and optional memory dumps are encrypted with your key or not written.

Fleet comparison from any node

There is no controller, so any node can pull every other member’s configuration over the tunnels and show where they differ. Policy that has drifted is flagged; node-local differences that are supposed to differ stay quiet. Each node redacts its own secrets before sending.

Cross-node consistency checks

Thirty-nine checks answer the question a single node cannot ask alone: not “do these configurations differ?” but “are they wrong about each other?” — a peer listed on one side only, a key that resolves to no node. Each finding names the nodes, the exact settings, and what will go wrong.

Fleet health in one request

One question — “is my fleet healthy?” — answered for every member, from whichever node you happen to have open.

Credentials for automation

Where a hardware security key protects human sign-in, scripts and monitoring use operator-issued API tokens instead. Any mesh member can also mint a read-only token that expires within minutes, for reading a locked-down node without holding a password.