> Source: https://nexusatlas.dev/docs — Nexus Atlas developer documentation (Getting started). Converted from the HTML page; the page is canonical.

# 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 →](https://nexusatlas.dev/docs/concepts/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 →](https://nexusatlas.dev/docs/concepts/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 →](https://nexusatlas.dev/docs/concepts/mesh)

- **Names the fleet.** Opt-in Mesh DNS answers `<node>.atlas` on 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 →](https://nexusatlas.dev/docs/concepts/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 →](https://nexusatlas.dev/docs/concepts/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 →](https://nexusatlas.dev/docs/concepts/qos)

## 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

1. **Bench proof** — the [quickstart](https://nexusatlas.dev/quickstart): two nodes, two links, kill one.

2. **Your bearers** — model each real link with [per-link capacity, probe cadence and quotas](https://nexusatlas.dev/docs/config#cfg-link); pick a [scheduler strategy](https://nexusatlas.dev/docs/concepts/scheduling) that matches how your links fail.

3. **Your topology** — direct peers, a [multi-hop chain](https://nexusatlas.dev/docs/concepts/mesh) through relays you own, or [relay-assisted traversal](https://nexusatlas.dev/docs/concepts/traversal) where addressing breaks down.

4. **Your operations** — the [hardened systemd deployment](https://nexusatlas.dev/guides/systemd), [Prometheus and syslog integration](https://nexusatlas.dev/guides/monitoring), and [peer authentication](https://nexusatlas.dev/guides/auth) that scales past hand-edited peer lists.

> **Where the edges are:** Atlas is honest about its boundaries — the inner tunnel is IPv4-only today, mesh relaying is hop-by-hop encrypted rather than end-to-end, and several subsystems are deliberately opt-in and default-off. The [known limitations](https://nexusatlas.dev/limitations) page states all of it plainly; read it before you design around an assumption.