Releases
Atlas releases are versioned, signed and attested as a unit: one tag produces the binaries, checksums, signatures, provenance and SBOMs for every target, published together. This page describes the release discipline; the artifacts themselves live behind Downloads.
Current release
| Release line | Status | Notes |
|---|---|---|
| v0.2 | current | The release line this documentation describes. Supply-chain attestation (signatures, SLSA L3 provenance, SBOMs) is fully implemented in CI as of v0.2. |
Nexus Atlas is in active, rapid development ahead of a 1.0: expect substantive features per release line, and read release notes rather than assuming semantic stability before 1.0. Evaluation deployments are expected to track the current line.
What every release contains
- Static
atlasdbinaries per target (x86_64 and aarch64 Linux), each with an embedded dependency manifest. .sha256checksums, cosign keyless signatures with certificates, SLSA L3 provenance, and CycloneDX SBOMs — the full set the verification recipe consumes.- Release notes covering: features and changes, configuration keys added or changed, protocol version implications, any accepted dependency advisories with rationale, and known issues.
Compatibility rules you must plan around
- Protocol version is checked, not negotiated. Every packet carries a protocol version byte; mixed versions fail loudly at decode. Upgrade a deployment as a deployment — release notes flag every protocol-version bump prominently, and mixed-version operation across a bump is not a supported state.
- Configuration is stable-by-schema. The config surface is defined by the daemon's own generated schema (the reference regenerates from it). Deprecated keys keep working with warnings for at least one release line before removal;
atlasd config checkis the authority on any given binary. - Wire-compatible opt-ins stay opt-in. Features documented as default-off (traversal, transport classes) do not change the wire behavior of nodes that leave them off.
- Legacy paths linger deliberately. Pre-rename config, snapshot and socket paths remain honored via fallbacks so staged fleet upgrades never race a rename.
Release notes & notifications
Release notes are published with each release under Downloads. Organisations with approved access are notified of new releases and of any security-relevant advisory affecting a shipped release at the contact on their access request.
Verifying is not optional ceremony: run the verification recipe against every artifact you ingest, and pin the identity strings from the release page in your scripts. A release you didn't verify is a release you're trusting your download path with.