Skip to content
Back to

Supply chain

Production Fontana deployments consume pre-built OCI images and signed Helm charts from your registry (typically GHCR). One commit produces one release: every service image carries its application code, and the charts pin those images by digest. Your cluster pulls artifacts only. That boundary supports SOC 2-aligned change management and vulnerability management without running build toolchains on customer data planes.

Artifact flow

Section titled “Artifact flow”
CI (GitHub Actions, release branch only)
  → OCI images, application code included (immutable sha-<git> / content-hash tags)
  → OCI Helm charts, versioned per commit, image digests pinned in values
  → Deploy bundle (fontana CLI, SHA256SUMS)
  → Trivy CRITICAL gate + cosign signatures
  → CycloneDX release SBOM (release-sbom.cyclonedx.json, all platform images)
  → Auto-deploy to staging; production takes the same digests after approval

Release artifacts are built only from the protected release branch after pull-request review and required status checks pass; feature-branch pushes run tests without publishing images or bundles.

Integrity controls

Section titled “Integrity controls”
Control What you get
Immutable image tags Deploys reference sha-<git> tags; branch tags are convenience only
Bundle checksums SHA256SUMS in the CLI bundle; the installer verifies before activating a release
Pinned upgrades fontana apply reconciles every declared workspace to a pinned release tag; workloads that did not change are left running
Release SBOM (CycloneDX) Each production release publishes release-sbom.cyclonedx.json on the deploy bundle, listing components in every platform image
Rollback Pin the previous release tag and run fontana apply; releases are digest-addressed, so the earlier artifact is the one that ran before
Artifact-only production clusters Production clusters pull digest-pinned OCI images and charts; no git checkout or build toolchain on the data plane
Content-hashed image tags A service whose inputs did not change keeps its tag, so Helm leaves its pods alone and a small release touches few workloads
Promoted, never rebuilt Staging and production run the same digests; approval promotes an artifact rather than triggering a new build

Vulnerability management

Section titled “Vulnerability management”

CI runs Trivy against built images. CRITICAL findings fail the pipeline until remediated or explicitly waived under your change process. That gate is part of the SOC 2-aligned supply-chain control set documented for diligence.

Source dependencies are gated on the same pipeline:

  • pnpm audit fails the build on any high or critical advisory in the dependency tree
  • CodeQL static analysis runs on every push and pull request to the release branch
  • Dependabot keeps lockfile and GitHub Actions dependencies current
  • A public-function inventory diff fails the build when the backend API surface changes without a reviewed baseline update

Change control and audit trail

Section titled “Change control and audit trail”
  • Pinned releases in fontana.yaml reference immutable sha-<git> tags, so the file is the record of what runs
  • Approval before production: the release that reaches production is the one that was scanned, signed, and validated in staging
  • Terraform provisions clusters and cloud infrastructure; every Fontana workload reconciles through fontana apply

The pinned tag history in version control, plus immutable registry tags and Helm release history in the cluster, form the deploy audit trail alongside application security audit in ImmuDB.

Section titled “Related documentation”