NNyalmaCerberus website, downloads, docs, and portal

Download docs

Download Cerberus through a public flow that records legal acceptance before the artifact redirect.

The public download route is designed to capture acceptance of the Nyalma terms and privacy baseline on the server before redirecting to the published installer or checksum artifact for the latest stable release.

Latest stable release

v0.1.0

  • cerberus-installer-v0.1.0.tar.gz
  • cerberus-installer-v0.1.0.tar.gz.sha256
  • 7d641e4db657763f77489f9ec0f7c9f89b8b73c91346b3fe8d4f16bca5b8a662
  • Advisory: Monitoring
  • Rollout is clear for staged deployment while Nyalma monitors early customer feedback and upgrade edge cases.
  • Detached signature: cerberus-installer-v0.1.0.minisig
  • Signature format: minisign
  • Signature key ID: cerberus-release-2026q2
  • SBOM: cerberus-sbom-v0.1.0.spdx.json
  • SBOM format: SPDX JSON

What the acceptance gate does

  • requires explicit agreement to the public terms, privacy policy, and cookie policy
  • records the acceptance on the server with release version, artifact type, and request metadata
  • can mint a one-time portal download grant instead of sending customers to a durable public object URL

Trust center metadata

  • release advisories are published with each version so operators can judge urgency before rollout
  • detached signatures and SBOMs can be shipped alongside the bundle when your release process has them ready
  • verification instructions are versioned release metadata, not copy pasted docs text

Why checksums matter

  • verify the bundle you received before rollout or internal redistribution
  • tie deployment approval to a specific version and digest
  • treat checksum validation as part of normal change review for self-hosted software

Verification guidance

## Verification steps
1. Download the installer bundle, checksum, release notes, and any additional trust artifacts for this version.
2. Verify that `cerberus-installer-v0.1.0.tar.gz.sha256` matches the approved digest for `cerberus-installer-v0.1.0.tar.gz`.
3. Confirm the expected SHA-256 for `cerberus-installer-v0.1.0.tar.gz` is `7d641e4db657763f77489f9ec0f7c9f89b8b73c91346b3fe8d4f16bca5b8a662`.
4. Verify the detached signature `cerberus-installer-v0.1.0.minisig` with your minisign trust root.
5. Confirm the signature was produced by key `cerberus-release-2026q2`.
6. Review `cerberus-sbom-v0.1.0.spdx.json` (SPDX JSON) so your internal approval record includes the shipped component inventory.
7. Read the release notes and capture any known issues, upgrade constraints, and rollback requirements in your own change record.
8. Approve rollout only after your team has validated backups, maintenance windows, and rollback ownership.

Release notes before deployment

  • read the release notes before production rollout
  • stage high-impact changes where feasible
  • keep backups, exports, and rollback plans under your own operational control

What this gate does not replace

  • one-time grants reduce sharing, but a short-lived object-store URL can still be forwarded while it is valid
  • for the strongest boundary, keep the backing object storage private and keep TTLs short
  • portal-side logging and token expiry complement, but do not replace, your own release governance