Digest-First Versioning

Immutable Release Identity by Content Hash

A release is a bundle of OCI digests resolved at creation time. Tags are human-readable aliases; digests are cryptographic truth.

Why Digest-First?

Mutable tags create ambiguity. The same tag can point to different content over time. Digest-first versioning eliminates this uncertainty.

Immutable Identity

SHA-256 digests ensure the artifact promoted is byte-identical to the artifact scanned and approved.

Tamper Detection

Any modification to the artifact changes its digest. Pull-time mismatch = deployment failure. Tampering is impossible to hide.

Audit Trail

Know exactly which artifact was deployed where, when, and why — with cryptographic proof linking scan, approval, and deployment.

Meaningful Rollback

Rollback returns to exact known-good digests, not "whatever :latest points to now". Same bytes, guaranteed.

Release Structure

A release in Stella bundles multiple components, each identified by its OCI digest. The release itself has a semantic version for human readability.

Example Release Bundle

Release: myapp-v2.3.1

Components:

api: sha256:abc123...

worker: sha256:def456...

frontend: sha256:789ghi...

Create and manage releases from the CLI

Terminal
$ stella release create --name myapp-v2.3.1 --components api:v2.3.1,worker:v2.3.1
stella release list --environment production\nstella release show myapp-v2.3.1 --components

Tag-to-Digest Resolution

When you create a release, Stella immediately resolves all tags to their current digests. From that moment, the release is immutable.

  • Tags like :v2.3.1 are resolved to sha256:abc123... at creation time
  • If someone pushes a new image to the same tag, your release is unaffected
  • Registry queries always use @sha256:digest syntax — no tag re-resolution

Immutability Guarantee

Once a release is created, its digest set cannot change. The exact same bytes will be deployed to every environment, every time.

Generated Artifacts

Every deployment generates immutable artifacts that enable reproducibility, audit, and rollback.

compose.stella.lock.yml

Docker Compose file with all image references pinned to specific digests. Includes Stella metadata labels for traceability.

image: registry.example.com/myapp/api@sha256:abc123...

labels:

stella.release.id: "rel-uuid"

stella.digest: "sha256:abc123..."

stella.version.json

JSON metadata file placed on deployment targets indicating current release, components, deployment strategy, and previous version for rollback.

"release": { "name": "myapp-v2.3.1" }

"deployment": { "strategy": "rolling" }

"previous": { "digest": "sha256:789..." }

"signature": "base64-encoded-signature"

Evidence Binding

Every release binds security evidence to the exact digests being deployed. The evidence travels with the release through promotion.

Evidence FieldContent
sbomDigestSHA-256 of the SBOM generated for this digest
scanVerdictPass/fail result of policy evaluation with evidence refs
reachabilityProofCAS URI of signed reachability graph for this digest
policyHashHash of the policy version used for evaluation

Deterministic Replay: Given the same release and policy hash, re-evaluation produces bit-identical verdicts. Auditors can verify decisions months later.

Ready for immutable release identity?

Install Stella Ops and start versioning releases by content hash with full evidence binding.