NNyalma Cerberus

Download docs

Use a Free account for evaluation and the portal for release artifacts.

Downloads are account-gated so Nyalma can keep accepted terms, entitlement state, release bundles, checksums, signatures, SBOMs, release history, and license material together in the portal.

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 Free account gate does

  • requires explicit agreement to the current account terms before portal access
  • records the acceptance on the server with the customer account and entitlement
  • keeps installer access behind login instead of sending evaluators to a durable public object URL

What belongs in the portal

  • customer-specific access to release bundles, checksums, signatures, and SBOMs
  • license retrieval through `license.json` and matching `cerb1:` strings
  • support context, entitlement history, documents, and release notes for the customer account

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

  • login-gated downloads reduce accidental sharing, but downloaded artifacts still need internal handling rules
  • for the strongest boundary, keep backing object storage private and keep issued URLs short-lived
  • portal-side logging complements, but does not replace, your own release governance