Reference architectures

Whole systems, drawn to the mechanism.

A capability page explains one mechanism. A reference architecture shows how a dozen of them sit inside somebody else’s product — which process runs where, who holds which key, what happens when a user clicks “Add drone” and when a hub dies. Every architecture here has the same ten parts, and every feature it relies on carries its badge.

Status per featureBoundaries in the same font size

The template

Ten parts, in the same order, every time.

A reader who has read one architecture knows where to find the answer in the next. Each part is one question an integrating engineer asks; each architecture answers all ten, and the last part lists what is shipped, what is on the roadmap and where the boundaries are.

Part	The question it answers
1 · The problem	What the platform cannot solve on its own, stated before any mechanism.
2 · Topology	Which daemon runs on which machine, who dials whom, and what survives the loss of each piece.
3 · Tenancy and trust boundaries	Who shares keys, addresses and membership with whom — and what a captured device exposes.
4 · Link plan per platform	Which links each platform carries and how each is declared: bind, port, capacity, budget.
5 · Data flows and classes	Which traffic rides which class, and what each class buys on these links.
6 · Registration	How a new device becomes known to the network, with which address and which permissions.
7 · Lifecycle	Removal, key rotation, defaults for new devices, replacing infrastructure.
8 · Operations and observability	What the integrating product reads, from where, with which credentials.
9 · Security properties	Each property with its mechanism, and the open items stated plainly.
10 · Feature status and boundaries	Every feature the architecture relies on with its badge, and the limits beside the strengths.

Architecture 01 below fills the template for web-based ground control. Each later architecture takes its own anchor on this page and keeps the same ten parts.

Architecture 01

A cellular fleet behind a web ground station.

Written for web-based ground control providers and the airframe makers who ship their software. The aircraft carry two or three cellular modems and nothing else; users and aircraft live in the provider’s relational database; the ground station is a web application. Atlas runs on every aircraft and on two hubs in front of the provider’s backend. Registration options C and D and the approval queue are opt-in; the only two items still on the roadmap are the scheduled rotation windows and hardware-backed keys.

1 · The problem

Four things the flight stack cannot solve on its own.

One modem is one point of failure

A handoff, a congested cell or a dead SIM takes the command link with it. Two modems help only if something decides, packet by packet, which one carries what — and duplicates the packets that matter.

Carrier NAT

Modems get private addresses, so the ground station cannot connect to the aircraft. Everything must be aircraft-initiated and kept alive, and the ground station must still be able to send a command at any moment.

Video starves commands

On a shared uplink a 4 Mbit/s stream fills the modem’s queue, and a 2 kbit/s command stream waits behind it.

Identity

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 — without an engineer editing files on a server.

2 · Topology

Two hubs on public addresses. Every modem dials both.

AIRCRAFTEach customer is its own network. Every aircraft dials out over every modem to both hubs.

HUBS A AND BPublic addresses, one daemon per tenant and one backend-side daemon on each, joined at loopback seams.

GROUND STATION BACKENDOne node with an Atlas link to each hub, beside the database that maps users to aircraft.

THE SEAMAdverts, gossip and topology never cross it — only mapped, exported addresses.

Dial-out

Why the aircraft dials out

Every Atlas link has its own UDP socket bound to its modem (bind_device). The aircraft sends its handshake from each socket to the hub’s public address; the carrier’s NAT creates a mapping per socket, and persistent_keepalive keeps each mapping warm through silence. The hub learns the aircraft’s current public address from the handshake and follows it when a modem re-attaches (endpoint_roaming, on by default). No inbound port is ever needed on the aircraft. On the hub, each tenant daemon has one link per modem slot, each on its own UDP port, with hole punching on ([traversal]): an aircraft admitted at handshake time gets a real address on the link its handshake arrived on, and punching fills the other slots, so the hub reaches the aircraft over every modem, not only the first. Hole punching

Two hubs

No single hub to lose

Each aircraft lists both hubs as peers and runs mesh routing, so its routing table holds a path to the backend through each. The link monitor probes every 250 ms by default and declares a link dead after five missed probes; the aircraft’s routes then move to the surviving hub. The two hubs’ tenant daemons also peer with each other, so adverts and the fleet list flood across both. How links die and recover

Hosted relays Opt-in

A fallback for a carrier that blocks the port

The hubs have public addresses, so relays are not part of this design. Where a carrier blocks the hub’s port, a relay link is an ordinary link that rides encrypted envelopes through Nexus Atlas’s hosted relays in Los Angeles, New York, Zurich, Hong Kong and Sydney, and those relays refuse revoked keys. Hosted relays

Where the backend sits — two shapes

Either way the backend speaks plain IP to tunnel addresses. The difference is who sees what.

	Backend as a node in each tenant network	Backend behind Interconnect seams Opt-in
Daemons on the backend host	One per tenant	One, in a backend network
The hub forwards aircraft ⇄ backend traffic	As a mesh relay (`relay = true` on the hub’s record)	As a seam: rewrites addresses and forwards
End-to-end sealing (`[crypto] e2e`, opt-in)	Aircraft ⇄ backend payloads are sealed end to end; the hub forwards them sealed. Without it each hop decrypts and re-encrypts, and the hub host is trusted	Opened and re-sealed at the seam — the hub host sees the payload
Topology	The backend sees each tenant’s full topology	Neither side learns the other’s topology; only exported addresses are reachable
Complete-footage backfill	End to end — the backend is the stream’s destination	Video terminates on a collector node inside the tenant network, on the hub host
Address plan	One backend address per tenant	One mapped address per exported aircraft inside the backend network
Fits	A few tenants	Many tenants; the provider’s own network stays private

Seams are explained on Mesh & routing → Interconnect; the trust model of each hop type on Security → Hop honesty.

3 · Tenancy and trust boundaries

One Atlas network per customer.

Separate keys, mesh secret and address space per customer. The hub host runs one atlasd per tenant; the provider’s own fleet is one more tenant.

	One shared network for every customer	One network per customer
Keys, mesh secret, address space	Shared across customers	Separate per customer
A captured aircraft exposes	The one mesh secret and the whole fleet’s membership gossip	Its own tenant only
Fleet list	One list for everyone	One list per tenant
Address space	One /24 by default for everyone	One /24 per tenant; a larger prefix is a configuration choice
Hub cost	One daemon per hub	One daemon per tenant per hub — a UDP port per modem slot, one TUN and one web port each
Removing a customer	Revoke every record one by one	Stop the tenant’s daemons

A star

Point to multipoint inside a tenant

Within a tenant the hubs are the centre of a star. Aircraft records carry relay = false, so no aircraft forwards another’s traffic and no route ever runs through an aircraft; the record’s classes flag limits which classes each aircraft may originate. What a member may do

Boundary

About a hundred records per fleet list

A fleet list travels as one datagram and carries about a hundred records. A tenant larger than that is two networks. Nothing in the ground station changes: an aircraft is a tunnel address either way.

4 · Link plan per platform

One Atlas link per modem.

SOURCESFlight controller, camera, log writer — unchanged.

CLASSIFIERDSCP first, then ports: 14550/14551 Control, RTP Video, CS1 and TCP Bulk.

CLASSESControl copied on the two best modems; Position on the single best; Telemetry striped; Video paced onto the unmetered modem; Bulk only when nothing live waits.

MODEMSThree links, two metered SIMs with quotas, every one dialling both hubs.

aircraft.toml — one node per aircraft

[interface]
name        = "atlas0"
address     = "10.1.0.17/24"       # the tenant's space; this aircraft is .17
private_key = "…"                  # generated on the aircraft, never copied off it

[[link]]
name        = "wwan0"
bind_device = "wwan0"
listen_port = 51820
capacity    = "20 Mbps"
quota       = "20 GB"              # metered SIM, monthly by default

[[link]]
name        = "wwan1"
bind_device = "wwan1"
listen_port = 51821
capacity    = "20 Mbps"
quota       = "20 GB"

[[peer]]                              # Hub A
public_key  = "…"
allowed_ips = ["10.1.0.1/32"]
persistent_keepalive = 20
endpoint_per_link = { "wwan0" = "198.51.100.10:41001", "wwan1" = "198.51.100.10:41002" }

[[peer]]                              # Hub B
public_key  = "…"
allowed_ips = ["10.1.0.2/32"]
persistent_keepalive = 20
endpoint_per_link = { "wwan0" = "203.0.113.20:41001", "wwan1" = "203.0.113.20:41002" }

[mesh]
enabled = true                        # routes to the backend are learned from the hubs

[qos]
enabled = true

5 · Data flows and classes

The flight stack is unchanged. The classes do the sorting.

The classifier reads DSCP first, then ports: UDP 14550/14551 is Control, RTP ranges are Video, CS1 is Bulk, TCP falls to Bulk, anything else to Telemetry. Marking DSCP at the MAVLink router — CS6 for commands, AF41 for video, CS1 for logs — makes the classification explicit.

Class	Contract	Multipath	Budget	What rides here
Control	duplicated within budget	copy on the 2 best links	80 ms	MAVLink commands, heartbeats, mode changes
Voice	best effort	2 copies	180 ms	unused here, or an operator intercom
Position	latest value wins	single best link	—	GPS fixes, attitude
Telemetry	best effort	striped	250 ms	sensor and status streams
Video	deadline bounded	striped, paced	200 ms	live video
Bulk	store-carry-forward	striped	—	logs, uploads

Commands

Commands survive one modem dropping

Control is sent on the two best links at once; the receiver’s replay window drops the second copy. When the aircraft is down to one live modem, each Control packet is repeated in time instead — three copies, a third of the round trip apart, inside the packet’s deadline and within a fifth of the link’s capacity — so a single lossy bearer still delivers. Time-diversity repeats

Video

Video never sits in front of a command

Classes are served strictly by priority with per-class rate floors, so a 4 Mbit/s stream cannot crowd out a 2 kbit/s command stream in Atlas’s own queue. Below that, the low band — Video, Telemetry, Bulk — is handed to the modem only as fast as the modem’s queue drains, so a video fragment never sits in the device queue in front of the next command. The six classes

Logs

Logs cost nothing while flying

Bulk is sent only when no live class has anything queued. With every link down, the aircraft’s own Bulk traffic is held in a bundle store — 16 MB by default, configurable — and flushed when a link returns. Post-flight log upload needs no scheduler of its own: it starts when the aircraft has airtime to spare and pauses when it does not. Store-carry-forward

Budgets

Metered SIMs stay inside their plan

A link over its quota leaves the scheduler’s candidate set — nothing promotes it, not duplication, not QoS — but a quota never takes down the last usable path. Accounting is in wire bytes, so framing, probes and duplicate copies are charged as the carrier charges them. The scheduler

Link groups

Links dedicated per class

[[link_group]] names sets of links and [qos.group.<name>] says which classes may ride them: “Video only on the unmetered modem”, “Control on all”.

Footage Opt-in

Complete footage by backfill

Live video drops what arrives too late, which is right for the pilot and wrong for the archive. With retain = true on the Video class the aircraft journals every video packet to an encrypted on-disk ring; the destination tracks the holes and asks for the missing ranges on the control channel; the aircraft re-sends them on the Bulk lane, only when nothing live is waiting, during and after the flight. The destination writes a packet-complete capture. Boundary: the destination is a node of the tenant network, so with seams the video terminates on a collector inside it. Complete footage

Commands, the other way. Commands from the web ground station take the reverse path: the backend sends the MAVLink datagram to the aircraft’s tunnel address, through the hub, over the two best modems. The aircraft’s address never changes across modem re-attach, hub failover or key rotation, so the backend needs no connection state beyond “the address of aircraft N”. With every modem down, Control and Position are not queued for a dead peer; Bulk is. When a modem returns, the aircraft re-handshakes from that socket and the routes come back with no action on the ground station’s side.

6 · Registration

How an aircraft becomes known — and stops being known.

Four options, all shipped, and an approval queue that combines with any of them. Three properties hold in every one.

The key never leaves the aircraft

The key pair is generated on the aircraft (atlasd keygen, or atlasd keygen --identity for a whole node identity). Only the public key travels.

Your database stays the system of record

The provider’s database maps users to aircraft. Atlas holds aircraft records and their permissions — address, capability flags, keys — and never needs a user account.

Unknown keys are refused

An unknown key is never admitted silently. The default provider refuses it, and every failure in a provider — an unreadable file, a missing hook, a timeout — fails closed. Peer authorization

Option A

A hook into your database

The hub’s [auth] provider = "command" runs a script when a handshake arrives from a key with no [[peer]] entry. The script receives the key and the source address; exit 0 approves and every non-empty line it prints is an allowed-IP CIDR; any other exit, or exceeding command_timeout_ms, denies. Denials are cached for deny_cache_secs so a handshake flood cannot fork a process per packet, and the hook runs off the packet path. One table, one script, no new infrastructure. Limits: a grant carries addresses only, the hook is asked once per admission rather than per session, and the database (or a replica) must be reachable from both hubs.

hub — the tenant-1 daemon

[auth]
provider = "command"
command  = "/opt/gcs/atlas-authorize"
command_timeout_ms = 3000
deny_cache_secs = 30

/opt/gcs/atlas-authorize <base64-key> <source-addr>

#!/bin/sh
# One row per aircraft: public_key, tenant_id, tunnel_ip, status.
row=$(psql -qtA "$GCS_DB" -c "select tunnel_ip from drones
  where public_key = '$1' and tenant_id = $TENANT_ID and status = 'active'")
[ -n "$row" ] || exit 1
echo "$row/32"

1 · ADD DRONEThe backend inserts a row: the aircraft’s public key, tenant, address, status active.

2 · HANDSHAKEThe aircraft dials the hub over each modem; the hub runs the hook with the key and the source address.

3 · THE HOOK ASKS YOUR DATABASEIt finds the active row, exits 0 and prints 10.1.0.17/32.

4 · SESSION UPThe hub creates the peer with that address; MAVLink flows to the backend and commands flow back.

Option B

A signed fleet list per tenant

With [auth] provider = "fleet" an aircraft is a record: a stable id, a name, its allowed addresses, roles, capability flags and its transport and signing keys with validity windows. All records of a tenant travel as one fleet list, signed by an authoring key the hubs trust and sequence-numbered, so a node refuses any list older than the one it holds. The list is offered over every session that comes up, so a list signed on the authoring host reaches every hub and aircraft of the tenant without copying files. When a user adds an aircraft, the backend — or a small signing service holding the tenant’s authoring key — runs three commands. Names, not keys

on the tenant’s signing host

atlasd fleet add-node --name drone-17 --node-id <uuid> \
    --transport-key <pub> --signing-key <pub> --allowed-ip 10.1.0.17/32 --dashboard own
atlasd fleet sign
atlasd fleet push -c /etc/atlas/tenant-1.toml   # hand the list to the local hub daemon; it floods it

Option C

A pairing code from the web ground station

“Add drone” makes the backend call POST /api/admission/invites on a hub with its write token and shows the pairing code it gets back as a QR: a short-lived, single-use token that also binds the flags the aircraft will hold. The aircraft starts with the code in [auth] invite_token and presents it in its first handshake, with its record UUID, its signing key and a signature proving it holds both. The hub checks the token, spends its single use and mints a least-privilege record for the key the handshake proved; because the hub is a config author of the tenant, it signs that record into the next fleet list at once and floods it, so the second hub admits the aircraft on its next handshake. The same code from a second key gets no session. It fits third-party airframes: no factory step, and the aircraft is linked to a user at the moment of pairing. One-time invitations

backend — on “Add drone”

curl -X POST -H "Authorization: Bearer $HUB_TOKEN" -H "X-Atlas-CSRF: 1" \
     -d '{"name":"drone-17","allowed_ips":["10.1.0.17/32"],"ttl_secs":900}' \
     http://10.1.0.1:9800/api/admission/invites
# → {"id":…, "uri":"atlas:pair?v=2&k=…&n=drone-17&t=…", "expires_at":…, "can_sign":true}

aircraft — first start

[interface]
node_id     = "<uuid from atlasd keygen --identity>"
signing_key = "…"

[auth]
provider     = "fleet"
invite_token = "atlas:pair?v=2&k=…&n=drone-17&t=…"

1 · ADD DRONEThe backend asks hub A for an invitation and shows the pairing code as a QR: 15 minutes, one use.

2 · FIRST HANDSHAKEThe aircraft presents the code to hub A over each modem; hub A spends the use and mints drone-17 with least privilege.

3 · SIGNED AND FLOODEDHub A signs fleet list seq 3 with the record; hub B and the aircraft adopt it and sessions come up on every modem.

Option D

A factory certificate plus a claim code

For aircraft the provider builds. At the factory the aircraft generates its key pair and the provider’s fleet authority signs its record as a certificate — UUID, keys, address, flags, an optional expiry, at most 940 bytes. The aircraft presents it from [auth] cert_file in its handshakes, and a hub holding the authority’s public key admits it with the flags the certificate names, with nothing to edit on the hub. The hub offers the certificate on over its sessions, so the other hub and the backend learn the record and reach the aircraft. The claim code printed on the airframe is the provider’s own: the user types it into the web ground station, which links the aircraft to the account in the provider’s database. Revocation is the same list as option B. Fleet certificates

at the factory — on the provider’s signing host

atlasd fleet cert --name drone-17 --node-id <uuid> --transport-key <pub> --signing-key <pub> \
    --allowed-ip 10.1.0.17/32 --classes Control,Position,Telemetry,Video,Bulk --fleet tenant-1 \
    --key /secure/tenant-1-authority.key --out drone-17.cert
# on the aircraft: [auth] provider = "fleet", cert_file = "/etc/atlas/drone-17.cert"
# sold or lost: atlasd fleet revoke --cert drone-17.cert — refused everywhere, even from a factory-fresh start

	A — database hook	B — signed fleet list	C — pairing token	D — certificate + claim
Provider work	One table column, one script	Call the fleet CLI on add and remove	One API call; show a QR	A factory signing step; a claim-code form
Who admits	Your database, at handshake time	The signed list	The hub, from a one-time token	Any hub trusting the authority
Permissions on the aircraft	Address only	Full capability flags	Least privilege by default	What the certificate says
Revocation	New handshakes are refused; the live session ends with `atlasd peer evict` on each hub	Everywhere within seconds	Same as B	Same as B, with `fleet revoke --cert`
Hubs need the database reachable	Yes	No	No	No
Fits	Starting out	Backend-driven fleets	Third-party airframes	The provider’s own airframes

A pending-approval queue combines with any option: a knock from an unknown key is parked on the hub with its source and the name it gives, listed on the hub’s dashboard and over its API so the ground station can show it too, and approve mints the record — the aircraft’s next retry gets a session, with no restart — while deny blocks the key. A pre-shared secret per tenant adds a second factor to any option. The approval queue Option B is the storage and distribution layer under C and D, and a complete answer on its own for a backend that already knows every aircraft.

7 · Lifecycle

Removed for good, rotated without churn.

Removal

A lost or sold aircraft is out everywhere at once

atlasd fleet revoke drone-17 --reason "sold" on the signing host, pushed to a hub. Every node that adopts the list evicts the aircraft’s sessions in the same intake, the mesh secret is rotated and sealed to the remaining records, the hosted relays refuse the key, and no later list may carry that id or key. The aircraft’s retried handshakes are refused by every hub, the event journal carries security.revoked and security.peer_evicted, and a returned aircraft re-enrols as a new identity. Removal that holds

Under the hook

Removal with option A

Set the row inactive and the hook denies every new handshake. An admitted aircraft is a peer from then on, so its live session ends when atlasd peer evict runs on each hub: the peer is removed, and its next handshake asks the hook again and is refused.

Rotation

Key rotation with overlap

A record holds two transport keys and two signing keys at once, current and next, each with a validity window. The aircraft answers handshakes on either; when it switches, its peers rebind the same entry, so the node id, address, routes and dashboards do not move. Keys change only through the signed list — no message from a node can add, rotate or retire its own keys. Scheduled rotation with operator windows Roadmap uses the same fields.

Defaults

Every new aircraft starts with the least

Every unnamed flag on a new record is least privilege: relay = false, classes = [Telemetry, Position, Bulk], config_author = false, dashboard = "own". Every flying aircraft gets Control explicitly: atlasd fleet set-caps drone-17 --classes Control,Position,Telemetry,Video,Bulk. A Control-marked packet from a record without Control is clamped to the highest class it may send, and counted.

Hubs

Replacing a hub

A hub is a node like any other: the new hub gets a record, the aircraft’s peer entries are updated by a configuration push, and the old hub is revoked. With two hubs no aircraft loses contact during the swap.

8 · Operations and observability

Modem health, next to your map.

Every atlasd serves a REST API, a dashboard and an OpenMetrics endpoint. Nothing is instrumented in the data path; a scrape costs forwarding nothing.

Endpoint	What the ground station reads there
GET /api/stats	Per link: RTT, jitter, loss, quality, capacity, selected links, bytes, pacing state, quota. Per peer: session state, endpoints, bytes. Routes with their next hop, QoS counters, identity and security sections.
GET /api/fleet/health	A fan-out over the tenant’s members: per node up or down, links alive of total, sessions, version, the applied configuration epoch. Unreached nodes are absent, not zero.
GET /api/fleet	The verified fleet list: records, flags, key validity, revocations.
GET /api/qos	Per-class counters, the delay the transport adds, link groups, repeats, archive completeness per origin and stream.
GET /api/journal	The event journal: links up and down, quota crossings, admissions, evictions, revocations, configuration applies.
GET /metrics	OpenMetrics: `atlas_link_rtt_seconds`, `loss_ratio`, `quality_score`, `selected`, byte counters, `atlas_link_quota_*`, per-class QoS counters.

Per modem

Per aircraft, per modem

Each [[link]] on the aircraft is one modem, probed every 250 ms. Its RTT, loss, jitter, quality, selected-for state and quota usage are in the aircraft’s own snapshot. The hub reads them for the whole tenant through the fleet fan-out, or the ground station scrapes each aircraft’s /metrics over the tunnel. “Which modem carries what” is selected_links and the per-link byte counters. The API

Modem signal

Signal readings by adapter, on request

Atlas reads RTT, loss and jitter per modem itself, and those are the modem health signal. A modem-signal adapter — RSRP, RSRQ, SINR, cell, band — follows the adapter contract and is built per modem family on request.

Credentials

Three kinds of access

Node-bound read tokens, signed by a node’s own signing key and valid for minutes, reach as far as the record’s dashboard flag says — own, fleet or none; the backend’s record gets fleet, aircraft get own. Named API tokens for automation — atlasd web token add gcs --scope read — carry a scope and an expiry, and a revoked one fails on its next request. Write authority — configuration epochs and fleet lists — is Ed25519 signatures from an anchor key and is never granted by a read token.

Change

Configuration and software

Configuration pushes are signed epochs with a commit-confirmed window: a change that loses a node reverts itself. The whole fleet runs one protocol version by policy, and a node left behind is refused loudly and named. Syslog and CEF export and the event journal cover audit. Signed epochs

9 · Security properties

Each property, with its mechanism.

Property	Mechanism
Identity	Noise IK: a peer is its X25519 static key, proven in the handshake. In a record fleet the key maps to a record — no record, no session.
Confidentiality in transit	ChaCha20-Poly1305 per hop; optional end-to-end sealing between aircraft and backend (`[crypto] e2e`) so the hub forwards payloads sealed.
Private key custody	Generated on the aircraft and never exported; hub and backend keys the same.
Admission	Pluggable and fail-closed: static allowlist, key file, command hook, signed fleet list; single-use pairing codes, fleet certificates, a pre-shared second factor that answers a wrong secret with silence, and an approval queue — every admission journalled with who made it. Admission modes
Least privilege	Capability flags per record — `relay`, `classes`, `config_author`, `dashboard` — the least for new nodes, each enforced where its action happens.
Revocation	A signed, sequence-numbered list; eviction in the same intake; the mesh secret rotated per removal; relays refuse revoked keys; a revoked id never returns.
Routing integrity	Adverts carry the originator’s Ed25519 signature; probes, acks and keepalives are session-sealed; gossip is signed by its sender; adverts are accepted only off a live session, and a link counts only when both ends report it. Signed routing
Flood resistance	Per-source and node-wide handshake budgets before any Diffie-Hellman; a cookie challenge under load; the deny cache on the hook.
Data at rest Opt-in	`[storage] at_rest = "on"` encrypts every daemon-owned file — journal, bundle store, video journal and capture, tokens — under a per-node store key. The configuration file itself needs disk encryption or a boot-time secret.
Tenant isolation	Separate networks; seams export only listed addresses and never redistribute; adverts, gossip and control frames never cross a seam.
What a captured aircraft yields	Its own key and its tenant’s current mesh secret — both revoked and rotated by one command — and nothing about other tenants.

10 · Feature status and boundaries

What this architecture relies on, badge by badge.

Feature	Status
Multi-link scheduler, a link per modem, dial-out through carrier NAT, keepalives, endpoint roaming	Shipped
Six traffic classes: priority queue, deadlines, duplication, striping, erasure coding, link groups	Shipped
Metered-link quotas	Shipped
Command-hook, key-file and static admission (option A)	Shipped
REST API, dashboard, OpenMetrics, fleet health fan-out, API tokens	Shipped
Node records, fleet lists, capability flags, node-bound tokens (option B)	Shipped
Pairing tokens (option C), fleet certificates (option D), key plus secret, the pending-approval queue	Shipped
Revocation with immediate eviction, mesh-secret rotation, relays refusing revoked keys, `peer evict`	Shipped
Signed adverts and gossip, sealed probes and keepalives, handshake budgets	Shipped
Low-band pacing	Shipped
Time-diversity repeats for Control on a single bearer	Shipped
Store-carry-forward Bulk, a bundle store that survives a restart	Shipped
Atlas Interconnect seams	Opt-in
End-to-end payload sealing	Opt-in
Complete footage by backfill	Opt-in
Data at rest	Opt-in
Hosted relays and relay links	Opt-in
Modem-signal adapter (RSRP, RSRQ, SINR, cell, band)	Built per modem family on request
Scheduled key and secret rotation with operator windows	Roadmap
Hardware-backed node keys, an end-to-end replay window, a signed audit trail	Roadmap

What holds

Losing a modem loses no command: Control rides two modems, or repeats in time on the last one.
Losing a hub loses nothing: the aircraft’s routes move to the other hub.
A removed aircraft is refused by every hub within seconds and never returns under the same identity.
A customer’s aircraft never learns another customer’s fleet.

Boundaries, stated plainly

One fleet list carries about a hundred records; a larger tenant is two networks.
A pairing code minted on a hub that cannot sign the tenant’s list admits the aircraft at that hub only, until an operator signs its record into the list.
Seams carry IPv4 and are hop-by-hop: end-to-end payloads are opened and re-sealed there.
Video backfill terminates inside the tenant network; gap requests do not cross a seam.
The end-to-end layer has no per-sender replay window yet.
The whole fleet runs one protocol version by policy; hubs and aircraft move together.
The configuration file itself is protected by the platform — disk encryption or a boot-time secret.

Nexus Atlas is proprietary software, licensed under a written agreement.

Who this is for

Ground control, fleet software, airframes.

Ground control providers, fleet-software vendors and airframe makers who ship a companion image. The conversation starts with your platform, its links, how your product knows its users and devices, and the fleet sizes you expect; it ends with a written integration design in this shape.

The commands

Hub and aircraft configuration, the admission hook, removal and the metrics to draw, step by step on the developer portal.

The guide

The mechanisms

Every part above links to the page that explains it in depth: classes, seams, records, the API.

The engineers

The people who built it read the form and answer it.

Talk to the engineers