A release receipt is a file, and files are read by whoever has the CLI. nimbus assurance serves the whole receipt set as a console — every release, its checks, its signatures, its trail — for the people who approve releases, review them, or get paged about them, and never open a terminal. Self-hosted, read-only, on your own network.
It shows the receipts, and nothing it made up. The console reads what is already in .nimbus/releases/ and renders it: per release, who validated it, who deployed it, whether the checks passed, whether the org drifted, its change reference, and — verified live in the browser — whether the bundle and the signatures are intact.
Verification is not a stored flag being echoed back. The console runs the same check nimbus release verify runs, so a tampered bundle or a signature by an untrusted key reads identically in the browser and on the command line. There is no view of a release that is truer than another view of it.
What it is not: it never contacts a Salesforce org, never deploys, and has no write path. It is a reading surface over evidence that already exists.
# Serve the console for this project
nimbus assurance
# → Assurance console for AcmeSalesCloud
# http://127.0.0.1:8090
# read-only · your evidence stays on this machine
# Share it with the team on your network.
# Beyond loopback, the evidence requires a token.
nimbus assurance --addr 0.0.0.0:8090
# A stable token survives restarts, so bookmarks
# keep working
export NIMBUS_ASSURANCE_TOKEN=...
nimbus assurance --addr 0.0.0.0:8090 --no-openTiles across the top count the whole filtered set: total releases, production deploys, signed, counter-signed, anything that failed verification, failed releases, and drift overrides. That is the first question an outsider asks — how many production changes, and how many of them are provable.
Narrow by lifecycle status, org kind (production, sandbox, developer, scratch), signed versus unsigned, and change reference. The dashboard recounts against the same filter, so "all production releases carrying ticket REL-4127" is one view, not a spreadsheet exercise.
Release ID, status, target org, when it was created, who validated it, who deployed it, the checks that ran, and the change reference. The org shows as its local alias where the machine knows it and as the org kind otherwise — the receipt itself carries only a one-way fingerprint.
Open a release and the receipt reads as prose: status, org, created and expiry timestamps, change reference, bundle digest; tests run and failed, coverage, mutation score, static-analysis findings broken out by severity with whether they blocked.
Bundle integrity, the validating signer, and the deploying counter-signer are their own section — verified live in the browser, on the same path release verify runs. A deploy with no counter-signature is labelled self-reported, never dressed up as attested.
Every recorded transition with its timestamp, actor, and note. Plus the things a reviewer specifically looks for: a drift override and who granted it, a promotion and the release it was chained from, a rollback and what it reversed.
localhost the console is open — it is your machine. The moment you bind beyond loopback it requires an access token: pass --token, set NIMBUS_ASSURANCE_TOKEN, or let the network bind generate a per-session token and print a ready-to-open URL. An evidence server reachable on the network is never wide open by accident.The engineer who shipped the release already knows what happened. Everyone else is reconstructing it: the tech lead approving Friday’s change, the auditor asking which production deploys in the quarter were signed, the teammate on call at 2am deciding whether the release ninety minutes ago is the reason. Today they ask the engineer, and the answer is a person’s memory of a terminal.
The receipt already answers all three questions — it just answers them to whoever holds the CLI. The console removes that condition. Nobody has to learn nimbus release get, install a licence, or be trusted to read a JSON file correctly. They open a URL and read the same verified record, with the verification re-run in front of them.
That changes what the evidence is worth. Proof only one role can read is documentation; proof the reviewer can open themselves is evidence. The console is deliberately the boring half of that — no dashboards Nimbus invented, no scores, no interpretation layered on top of what the receipt says.
A console is only as honest as the record beneath it. Four layers produce that record, and each one is a shipped command you can run yourself.
Tests, coverage, mutation score, static analysis, and permission-seam policy run against a content-addressed bundle — locally, in seconds, with no org involved. This layer is Free: nimbus deploy runs it as part of a one-shot gated deployment.
A real check-only validation of the same bytes in the target org. Neither half is a claim about a worktree: both read the identical staged bundle, which is what makes the two results comparable at all.
nimbus release validate writes an immutable JSON record — bundle digest, git revision, org fingerprint, gate results, the validation job and its expiry — signed, so it is tamper-evident rather than merely written down. It travels as a file between machines and jobs.
nimbus assurance serves that receipt set as a web view for the people who never run the commands above. It reads the local receipts, verifies signatures and bundle integrity live, and shows what each release actually proves.
A console you have to trust is worth very little to a reviewer. This one is a view over files that verify on their own. nimbus release verify re-hashes the bundle and checks the signature offline, on any machine, with no org and no network — the same result the browser showed.
For retention, the console offers an export evidence download of exactly what nimbus release export writes: the verified receipt set plus the signer roster in one self-verifying JSON document. It carries no source, no org aliases, and no credentials — it is evidence, not payload — so it archives to your own immutable store without leaking anything.
nimbus release verify-export re-checks every signature and counter-signature years later, fully offline, and needs no Nimbus licence. An auditor holding the file can verify it with no vendor relationship. Pin an external trust anchor with --roster or --expect-signer and the answer becomes authenticity rather than internal consistency.
The console keeps one distinction that flatters nobody: a validation signature covers what was validated, not the deploy that followed. So a succeeded release without a deploy counter-signature is labelled self-reported — a real claim, not an attested one. Turn on requireCountersigned to make the deploy attestable and, on production, enforce a second identity.
# Offline: re-hash the bundle, check the signature
nimbus release verify rel_20260720T141342_0397df68b0
# Archive the evidence set — the same document the
# console offers as "export evidence"
nimbus release export --org-kind production \
--since 2026-07-01 --output evidence-2026Q3.json
# Re-verify it years later, offline, no licence
nimbus release verify-export evidence-2026Q3.json
# As a gate: fail unless every receipt is signed
nimbus release verify-export --require-signed \
evidence-2026Q3.json
# Prove authenticity against a trusted roster
nimbus release verify-export \
--roster .nimbus/release-signers.json \
evidence-2026Q3.jsonnimbus assurance is Pro — currently free, no card required. It needs receipts to read, so start with the release workflow that writes them.