What Atlas is
Nexus Atlas is a userspace daemon — atlasd, a single static Rust binary — that owns a Linux TUN interface and carries its traffic across one to six underlay links at once, encrypted, with continuous per-link measurement deciding where every packet rides. Applications see a normal network interface that keeps working while the paths beneath it fail, degrade and return.
The shape of the system
One config file, one daemon instance, one TUN device. Everything else is a view of that daemon's state:
| Piece | What it is | Where it's documented |
|---|---|---|
atlasd run | The daemon: TUN, Noise IK encryption, link probing, packet scheduling, mesh routing. | Architecture |
/etc/atlas/config.toml | The single configuration file — identity, links, peers, behavior. Validated by atlasd config check. | Configuration reference |
atlasd subcommands | The control surface: keygen, status, stats, live monitor, journal, support bundles, token management. | CLI reference |
atlasd web on :9800 | REST API + browser dashboard. Also Prometheus metrics at /metrics. | REST API |
/tmp/atlas/<iface>.json | The stats snapshot, rewritten every second — the integration point every other tool reads. | Telemetry |
/run/atlas/telemetry.sock | Where radio adapters push RSSI, noise floor and buffer state the OS can't see. | Telemetry |
What it does, in six sentences
- Bonds links. Each
[[link]]is a UDP socket pinned to a physical device; the scheduler places every packet on the best link — or several at once — based on live RTT, jitter, loss and capacity. Scheduling → - Encrypts everything. Noise IK per peer — X25519, ChaCha20-Poly1305, BLAKE2s — with make-before-break rekeying measured at zero packet loss across key changes. Architecture →
- Routes multi-hop. Nodes flood link-state advertisements and compute shortest paths, so a fleet relays through itself — no controller, no cloud, at most eight hops. Mesh →
- Names the fleet. Opt-in Mesh DNS answers
<node>.atlason every node from that same link-state database — a local resolver per node, no DNS server anywhere in the mesh, and never a lookup in the tunnel's own path. Mesh DNS → - Crosses NATs. Opt-in STUN classification, relay links and hole punching bring up connections between peers that cannot address each other, then upgrade them to direct paths when the network allows. Traversal →
- Prioritises when starved. Opt-in transport classes keep command traffic ahead of video on narrow bearers, add forward error correction, and hold bulk traffic for peers that are temporarily unreachable. Transport classes →
What it runs on
Linux, as an unprivileged service with a single capability (CAP_NET_ADMIN) — x86_64 and aarch64, from servers to single-board computers. There is an Android port of the same engine running inside a VpnService app, in active development. The daemon has no runtime dependencies, phones home to nothing by default, and works fully offline; connecting a node to the hosted customer console is an explicit enrolment step, never an assumption.
What integrating usually looks like
- Bench proof — the quickstart: two nodes, two links, kill one.
- Your bearers — model each real link with per-link capacity, probe cadence and quotas; pick a scheduler strategy that matches how your links fail.
- Your topology — direct peers, a multi-hop chain through relays you own, or relay-assisted traversal where addressing breaks down.
- Your operations — the hardened systemd deployment, Prometheus and syslog integration, and peer authentication that scales past hand-edited peer lists.