nordisk/holger

holger — complete overview

The real README: the full pitch, quickstart, design and measured numbers. The repo-root README.md is the slim face; this chapter is the heavy detail, and it is also folded into the manual docs/manual.pdf by nornir docs book.

A secure, airgap-first artifact server: it speaks every package manager's native protocol (Maven · PyPI · cargo · npm · NuGet · Go · Gem · Deb · Helm · Docker) yet serves them from an immutable, content-addressed znippy store — so an entire registry can cross an airgap on a USB stick. Built to replace Nexus/Artifactory where auditability and airgap compliance matter more than a polished UI.

Why holger — airgap-first, a single Rust binary, an immutable znippy store and mTLS+OIDC built in — trading the mature UI / HA-replication surface Nexus & Artifactory ship:

Full numbers below — generated by nornir bench run holger.

What it does

• Impersonates every tool's registry — point unmodified pip / cargo / docker / helm / npm / go / … at holger and each thinks it's talking to PyPI / crates.io / Docker Hub / … (real protocols: RubyGems compact-index, Conda repodata.json, Deb Packages/Release, npm, NuGet, …).
• Airgap by design — the agent (internet side) downloads + packs into an immutable .znippy; you carry it across the gap; the server (secure side) serves it. No cable crosses.
• Immutable, content-addressed storage — one znippy archive per repo version, blake3-checksummed, O(1) random file pull (no full unpack).
• Real auth — mTLS or OIDC (not just basic user/pass), RBAC (reader/writer/admin), append-only audit log.
• gRPC control plane + direct in-process Rust — holger.fetch("repo", &id) with no serialization for embedded callers.

Quickstart

# secure side: bring up the registry pair nornir embeds (writes config + /cache + /sparring archives)
holger-server dev-pair --data ./holger-data

# point cargo at it — holger speaks the sparse-registry protocol, fetches with no internet:
#   ~/.cargo/config.toml
#   [registries.holger]
#   index = "sparse+http://127.0.0.1:<port>/cache/index/"
# pip / docker / helm / npm point the same way — each tool thinks holger IS its registry.

# …or run a fully configured server from a RON graph:
holger-server start --config holger.ron

Build-space — holger presses nornir's build-thing

holger is the first real consumer of nornir-build-thing (nornir task #36), the dependency-light core that turns declarative cargo build variants + a content-addressed build-provenance attestation into reusable data. holger declares its build-space — one product built three ways — and drives build-thing end to end without pulling nornir's iceberg / arrow / eframe stack.

The three deployment tiers, declared as data (.nornir/build-variants.toml, embedded byte-for-byte in the holger-build-space crate so the file and the code can never drift):

Each tier is a typed (package × bin × features × profile × target) point in a nornir_build_thing::BuildVariantSet, grounded in holger's actual workspace crates and Cargo features (sign, testmatrix, served, gui) — nothing invented. Three distinctly-named executables from one source tree, the mode features mutually exclusive via compile_error! guards in server/cli/src/main.rs; the legacy default holger-server bin stays for the systemd service spec. nornir build --list-variants reflects all three; nornir build --variant full --attest --seal validates, materializes + runs the right cargo build, then captures and znippy-seals a build-provenance attestation.

holger drives the same seam first-party via its own xtask: cargo run -p xtask build --list (describe all tiers + materialized commands), build --variant <tier> (assemble one), and build --all (assemble all three deployment tiers, one functional_status row each plus an aggregate). See .nornir/holger-tiers.md — including the open fat/thin (holger / holger-thin) duplication question.

How holger consumes the crate (build-space/src/lib.rs):

// DESCRIBE — reflect the build-space onto the data-driven surface a UI/CLI renders.
let surface = holger_build_space::build_surface()?;          // three tier rows
for v in &surface.variants {
    println!("{}: {}", v.name, v.command_line);               // materialized cargo argv
}

// PRESS — validate a tier + capture a content-addressed build-provenance attestation.
let att = holger_build_space::press_tier("full", repo_root, Outcome::Success, &artifacts)?;
assert!(att.digest_matches_record()?);                        // stable SHA-256 over the record

The provenance record binds the verbatim tier descriptor, the resolved inputs (cargo argv, features, profile, VCS rev + working-tree freshness), the toolchain, the host (cores + memory), the outcome, and the SHA-256 of every produced artifact — folded to a stable digest. The attestation is unsealed; holger never fabricates a signature (the real seal is znippy's detached-CMS signer, wired behind nornir's build-provenance feature).

The worked example — cargo run -p holger-build-space --example press_build_thing — describes holger's build-space and then presses the full tier: it captures the attestation, persists it to a dep-light JsonFileSink ledger, reloads it, and proves the digest still verifies. The round-trip is asserted by the holger-build-space test suite (press_full_tier_captures_and_ round_trips_provenance, pressed_record_persists_to_a_reloadable_ledger, tampering_a_pressed_record_breaks_the_digest).

Benchmarks

holger vs Nexus vs Artifactory, head-to-head on the same cached corpus (crates / jars / wheels), served over HTTP on both sides — a true like-for-like, over-the-wire comparison. Each row is one comparison scenario run against a real backend container. holger_served_mbs is holger fetched over its native HTTP door (handle_http2_request, the path stock cargo/pip/npm hit); nexus_served_mbs / artifactory_served_mbs are the rival fetched over its HTTP API. The faster backend is bolded per row; ops_per_sec is the served HTTP GET rate and p50/p99/p999/mean_ms are the per-request latency percentiles — every one measured identically on all three systems (the same pure-Rust concurrent GET pool over loopback), so they are the honest like-for-like latency head-to-head. The tight top-of-README mashup transposes these into a systems-as-rows table across six contested columns. (The old in-process get_file() figure is kept only as an internal holger_inprocess_read_ceiling_mbs regression ceiling — a Holger-vs-Holger number, deliberately NOT shown beside the competitor.) Numbers are generated from the latest nornir bench run holger — never hand-edited; an empty rival cell means that backend's container was not available on the bench host.

Fair hardware — every system at full machine. There is no throttled variant: FairResources::detect() reads whatever host it runs on and hands each JVM rival container every core (--cpus) + 75 % of RAM (--memory, swap pinned to the cap) + a fair JVM heap at 50 % of that container cap (-Xmx). Holger runs in-process on the same cores. The fight is fair at the top; holger still wins every contested column. The host and core count are stamped on each table below — they are a property of the run, not of this paragraph, and two hosts are never one trend line.

v0.1.0 · oden · 32 cores · 2026-07-23

Tests

Every Rust test in the workspace (incl. #[tokio::test] async tests), grouped by the standard categories. Run with cargo test --workspace.

Unit tests (550)

Integration tests (133)

Doc tests (2)

Dependency graph