Golden Container Build Platform 3.0: Secure Enterprise Delivery and Deployment Governance

Golden Container Build Platform 3.0

Enterprise-Grade Artifact Build, Promotion, Deployment, and Governance Platform

1. Executive Summary

Golden Container Build Platform 3.0 is a standardized enterprise delivery platform for building, signing, scanning, promoting, and deploying containerized applications across environments.

The platform should not simply be a reusable GitHub Actions workflow. It should become a governed software delivery layer that provides:

• Build once, promote many
• Immutable artifact identity
• Release-based production promotion
• Manual operational recovery
• GitOps-based deployment
• OIDC-based cloud authentication
• Supply chain security
• Policy-as-code enforcement
• Deployment observability
• Self-service developer experience

The key principle:

Source code merge creates a trusted artifact. Release approval promotes that artifact. GitOps deploys that artifact. Manual workflows recover or rollback that artifact.

This separates build, release, promotion, and deployment into clear enterprise-grade responsibilities.

---

2. Platform Goals

2.1 Business Goals

• Reduce application team CI/CD maintenance burden
• Standardize container delivery across all teams
• Improve release confidence and auditability
• Reduce deployment risk
• Enable faster rollback and incident recovery
• Provide centralized governance without blocking team autonomy

2.2 Engineering Goals

• Build every artifact once
• Never rebuild the same commit for different environments
• Use immutable image tags
• Promote artifacts instead of rebuilding artifacts
• Support controlled production gates
• Support manual recovery paths
• Provide strong identity isolation
• Provide end-to-end traceability from commit to production

2.3 Security Goals

• Use OIDC instead of long-lived cloud secrets
• Enforce least-privilege access
• Sign images
• Generate SBOM
• Scan images before promotion
• Enforce deployment policies before GitOps PR merge
• Provide audit logs for every artifact movement

---

3. Core Design Philosophy

3.1 Build Once, Promote Many

The platform should produce one immutable container image per source commit.

Commit SHA
   ↓
Build Image
   ↓
Push to Build Registry
   ↓
Scan + Sign + Attest
   ↓
Promote Same Image Through Environments

The same image should flow through:

dev → test → staging → prod

No environment should rebuild the image.

This avoids the classic problem:

dev image != test image != prod image

Instead, the platform should guarantee:

prod image == tested image

3.2 Merge Is Not Release

A merge to main means the code has been integrated.

It does not automatically mean:

• The feature is ready for production
• Product has approved the release
• QA has completed validation
• Business timing is correct
• Incident risk has been reviewed

So Platform 3.0 should separate:

Event	Meaning
Pull Request	Validate candidate change
Merge to main	Create trusted integration artifact
Release approval	Promote artifact to production registry
GitOps PR merge	Deploy artifact to environment
Manual dispatch	Recover, rollback, or exceptional promote

Production registry promotion should happen only on:

Release event

or:

Explicit manual promotion

not on every merge to main.

3.3 Deployment Is GitOps, Not CI

CI should not directly deploy to runtime clusters.

CI should produce and promote artifacts. GitOps should deploy them.

CI/CD Platform
   ↓
Creates GitOps PR
   ↓
GitOps Repo
   ↓
Approval / Merge
   ↓
ArgoCD / Flux
   ↓
Cluster Deployment

This keeps deployment state declarative and auditable.

---

4. Proposed Platform 3.0 Architecture

Developer Repository
────────────────────────────────────────────
Source Code
Dockerfile
platform.yaml


Golden Platform Control Plane
────────────────────────────────────────────
Config Validation
Build Orchestration
Artifact Promotion
Policy Evaluation
Release Validation
GitOps PR Generation
Audit Logging
Notification
Developer Portal API


Artifact Layer
────────────────────────────────────────────
Build ACR
NonProd ACR
Prod ACR
Image Signatures
SBOM
Provenance Attestations


Deployment Layer
────────────────────────────────────────────
GitOps Repositories
ArgoCD / Flux
Environment Approval Gates
Runtime Clusters


Security / Governance Layer
────────────────────────────────────────────
OIDC
Managed Identities
RBAC
Policy-as-Code
Vulnerability Gates
Audit Logs

---

5. Registry Strategy

5.1 Recommended Registry Layers

A top enterprise design should avoid treating one lower registry and one prod registry as enough for all cases.

A cleaner model is:

Build Registry
NonProd Registry
Prod Registry

5.2 Registry Responsibilities

Build Registry

Used for raw CI build outputs.

build-acr.company.com/applications/my-app:sha-abc1234

Purpose:

• PR builds
• Main builds
• Early validation
• Shorter retention
• Not production trusted yet

NonProd Registry

Used for validated non-production deployments.

nonprod-acr.company.com/applications/my-app:sha-abc1234

Purpose:

• Dev
• Test
• QA
• Staging
• Performance testing

Prod Registry

Used only for production-approved artifacts.

prod-acr.company.com/applications/my-app:sha-abc1234

Purpose:

• Production deployments
• Production rollback images
• Long retention
• Stronger access control

5.3 Promotion Rule

Build Registry → NonProd Registry
    allowed after build validation

NonProd Registry → Prod Registry
    allowed only after release approval or emergency manual approval

This gives a much clearer artifact trust boundary.

---

6. Artifact Identity Model

Each artifact should have a complete identity.

artifact:
  application: payment-service
  git_repository: company/payment-service
  commit_sha: abc123456789
  source_branch: main
  build_run_id: 123456789
  image_digest: sha256:xxxx
  image_tags:
    - sha-abc1234
    - sha-abc123456789
    - build-123456789
  sbom: attached
  signature: verified
  provenance: verified

6.1 Prefer Digest for Production

GitOps manifests should ideally use image digest, not only tag.

Instead of:

image: prod-acr.company.com/applications/my-app:sha-abc1234

Prefer:

image: prod-acr.company.com/applications/my-app@sha256:abcdef...

Tags can technically be moved if registry policy allows it. Digests are content-addressable and immutable.

A practical enterprise pattern is:

Human-friendly tag for visibility
Digest for exact deployment identity

---

7. Workflow Model

7.1 Pull Request Workflow

Trigger

pull_request:
  types:
    - opened
    - synchronize
    - reopened

Purpose

Validate change before integration.

Flow

PR opened or updated
    ↓
Validate platform.yaml
    ↓
Build image
    ↓
Push to Build Registry
    ↓
Run tests
    ↓
Run vulnerability scan
    ↓
Create optional dev GitOps PR

Output

Build image exists
Quality checks completed
Security scan completed
Optional dev deployment PR created

7.2 Main Build Workflow

Trigger

push:
  branches:
    - main

Purpose

Create integration artifact.

Flow

Merge to main
    ↓
Build image if not already built
    ↓
Push to Build Registry
    ↓
Generate SBOM
    ↓
Sign image
    ↓
Generate provenance
    ↓
Promote to NonProd Registry
    ↓
Create GitOps PRs for configured non-prod environments

Important: This workflow should not automatically promote to Prod Registry.

7.3 Release Workflow

Trigger

release:
  types:
    - published

Purpose

Promote approved artifact to production registry.

Flow

GitHub Release published
    ↓
Resolve release commit
    ↓
Find matching artifact
    ↓
Verify artifact was built from main
    ↓
Verify image signature
    ↓
Verify SBOM exists
    ↓
Verify vulnerability policy
    ↓
Promote image to Prod Registry
    ↓
Create production GitOps PR

7.4 Manual Operations Workflow

Trigger

workflow_dispatch:

Purpose

Controlled operations path for exception handling.

Supported Actions

deploy_existing_image
promote_existing_image
rollback_to_previous_image
recreate_gitops_pr
validate_artifact
scan_artifact

Required Inputs

application:
  required: true

artifact:
  required: true
  description: "SHA tag or image digest"

target_environment:
  required: true

operation:
  required: true
  options:
    - deploy_existing_image
    - promote_existing_image
    - promote_and_deploy
    - rollback
    - recreate_gitops_pr
    - validate_only

change_reason:
  required: true

approval_ticket:
  required: false

This is critical because enterprise systems must assume the happy path will fail sometimes.

---

8. Platform Configuration Model

Instead of a minimal config.yaml, Platform 3.0 should use a richer but still readable platform.yaml.

apiVersion: platform.company.com/v3
kind: ContainerDelivery

metadata:
  application: payment-service
  owner: payments-platform
  serviceTier: tier-1
  dataClassification: confidential

build:
  dockerfile: ./Dockerfile
  context: .
  platforms:
    - linux/amd64
  buildArgs:
    JDK_VERSION: "25"
  cache: true

artifact:
  repositoryPath: applications/payment-service
  tags:
    - short_sha
    - full_sha
    - run_id
  sign: true
  sbom: true
  provenance: true

promotion:
  nonprod:
    autoPromoteFromMain: true
  prod:
    promoteOnRelease: true
    promoteOnMerge: false
    allowManualPromotion: true
    requireApproval: true

security:
  vulnerabilityGate:
    enabled: true
    failOn:
      - critical
  secretScan:
    enabled: true
  policyValidation:
    enabled: true

environments:
  dev:
    registry: build
    gitops:
      repository: company/gitops-nonprod
      branch: dev
      file: apps/payment-service/deployment.yaml
      imagePath: spec.template.spec.containers[0].image
    triggers:
      pullRequest: true
    manualDeploy: true

  test:
    registry: nonprod
    gitops:
      repository: company/gitops-nonprod
      branch: test
      file: apps/payment-service/deployment.yaml
      imagePath: spec.template.spec.containers[0].image
    triggers:
      main: true
    manualDeploy: true

  staging:
    registry: nonprod
    gitops:
      repository: company/gitops-nonprod
      branch: staging
      file: apps/payment-service/deployment.yaml
      imagePath: spec.template.spec.containers[0].image
    triggers:
      releaseCandidate: true
    manualDeploy: true

  prod:
    registry: prod
    gitops:
      repository: company/gitops-prod
      branch: prod
      file: apps/payment-service/deployment.yaml
      imagePath: spec.template.spec.containers[0].image
    triggers:
      release: true
    manualDeploy: true
    approvals:
      required: true
      environment: prod

---

9. Identity and OIDC Model

9.1 Recommended Identity Layers

A strong enterprise model should not use one identity for everything.

Use separate identities by operation type:

build-identity
nonprod-promotion-identity
prod-promotion-identity
gitops-pr-identity
security-scan-identity

9.2 Identity Permission Model

Identity	Purpose	Permissions
Build identity	Build and push CI images	Push to Build Registry
NonProd promotion identity	Promote tested images	Pull Build Registry, Push NonProd Registry
Prod promotion identity	Promote approved release images	Pull NonProd Registry, Push Prod Registry
GitOps identity	Create GitOps PRs	Write PRs to GitOps repos
Security identity	Scan and attest artifacts	Read image metadata, write scan results

9.3 OIDC Trust Scope

OIDC federated credentials should be scoped tightly.

Examples:

repo:company/my-app:ref:refs/heads/main
repo:company/my-app:environment:prod
repo:company/my-app:ref:refs/tags/v*

Production promotion should preferably use GitHub Environments with approval gates.

---

10. Supply Chain Security

Platform 3.0 should include supply chain security as a first-class feature.

10.1 Required Controls

Every production artifact should have:

Image signature
SBOM
Provenance attestation
Vulnerability scan result
Policy evaluation result

10.2 Production Promotion Gate

Before promoting to Prod Registry:

Check artifact exists
Check artifact was built by trusted workflow
Check artifact came from main or approved release branch
Check image signature
Check SBOM exists
Check critical vulnerabilities
Check policy-as-code
Check approval status

If any check fails:

Do not promote to Prod Registry
Do not create production GitOps PR

---

11. Policy-as-Code

The platform should not rely only on documentation. It should enforce rules automatically.

11.1 Example Policies

Prod deployments must use Prod Registry
Prod artifacts must be signed
Prod artifacts must have SBOM
Prod deployments must use image digest
Critical vulnerabilities block production
Manual prod promotion requires approval reason
Tier-1 services require two approvers
Release tag must point to main

11.2 Policy Engine

The policy engine could be implemented using:

• OPA / Conftest
• Kyverno policies
• Custom platform validation scripts
• GitHub required checks

The important part is not the tool. The important part is:

Rules should be executable, not tribal knowledge.

---

12. Deployment Strategy

12.1 Supported Deployment Modes

Platform 3.0 should support multiple deployment strategies.

deployment:
  strategy: rolling

deployment:
  strategy: canary
  steps:
    - weight: 10
      duration: 10m
    - weight: 50
      duration: 20m
    - weight: 100

deployment:
  strategy: blue_green

12.2 Recommended Strategy by Environment

Environment	Recommended Strategy
Dev	Rolling
Test	Rolling
Staging	Canary or Blue/Green
Prod	Canary or Blue/Green for Tier-1 services

---

13. Rollback Model

Rollback should be a first-class workflow.

13.1 Rollback Flow

Incident detected
    ↓
Operator selects previous known-good artifact
    ↓
Platform validates artifact exists
    ↓
Platform verifies artifact was previously approved
    ↓
Platform creates rollback GitOps PR
    ↓
Approver merges PR
    ↓
GitOps controller deploys previous image

13.2 Rollback Input

workflow_dispatch:
  inputs:
    application:
      required: true

    target_environment:
      required: true

    rollback_to:
      required: true
      description: "Previous image digest or SHA tag"

    incident_id:
      required: true

    reason:
      required: true

Rollback should not require rebuilding.

---

14. Observability and Auditability

14.1 Deployment Summary

Every workflow should generate a summary like:

Application: payment-service
Environment: prod
Commit SHA: abc123456789
Image Tag: sha-abc1234
Image Digest: sha256:xxxxx
Build Run: 123456789
SBOM: available
Signature: verified
Vulnerability Gate: passed
Promotion: nonprod → prod
GitOps PR: https://github.com/company/gitops-prod/pull/123
Approval Ticket: CHG123456
Triggered By: errong

14.2 Audit Events

The platform should emit audit events for:

image_built
image_promoted_to_nonprod
image_promoted_to_prod
gitops_pr_created
deployment_requested
manual_promotion_requested
rollback_requested
policy_failed
approval_required

These events can feed:

• Splunk
• Datadog
• Azure Monitor
• Internal developer portal
• Change management system

---

15. Developer Experience

A top enterprise platform must be self-service.

15.1 Developer Portal

Application teams should be able to view:

Current image per environment
Deployment history
Available artifacts
Security scan result
SBOM
Release candidates
Rollback candidates
GitOps PR status
Policy failures

15.2 CLI

Example:

platform artifacts list payment-service
platform deploy payment-service --env test --image sha-abc1234
platform promote payment-service --to prod --image sha-abc1234
platform rollback payment-service --env prod --to sha-def5678

15.3 ChatOps

Example:

/deploy payment-service sha-abc1234 to test
/promote payment-service sha-abc1234 to prod
/rollback payment-service prod to sha-def5678

This reduces friction during normal operations and production incidents.

---

16. Recommended Final 3.0 Flow

Pull Request
    ↓
Build image
    ↓
Push to Build Registry
    ↓
Run tests and scans
    ↓
Optional dev GitOps PR


Merge to Main
    ↓
Build or reuse image
    ↓
Generate SBOM
    ↓
Sign image
    ↓
Promote to NonProd Registry
    ↓
Create test/staging GitOps PR


Release Published
    ↓
Resolve release commit
    ↓
Verify artifact
    ↓
Promote to Prod Registry
    ↓
Create production GitOps PR


Manual Dispatch
    ↓
Deploy existing artifact
    ↓
Promote existing artifact
    ↓
Rollback existing artifact
    ↓
Recreate GitOps PR

---

17. What Makes 3.0 Better Than 2.0?

Area	2.0	3.0
Registry model	Source + Prod	Build + NonProd + Prod
Manual deploy	Added	First-class operations workflow
Rollback	Suggested	First-class workflow
Security scan	Optional	Promotion gate
SBOM	Nice-to-have	Required for production
Image signing	Not central	Required
Policy-as-code	Suggested	Core enforcement layer
GitOps	PR generation	Full deployment control plane integration
Identity	Team identity	Operation-scoped identities
Observability	Job summary	Audit event model
Developer UX	GitHub Actions UI	Portal + CLI + ChatOps

---

18. Recommended Position to Platform Team

A professional way to frame this proposal:

I think the current Golden Container Build is a strong foundation, but if we think about this as an enterprise platform capability, we may want to evolve it beyond a reusable workflow.

A stronger 3.0 model could separate build, promotion, release, and deployment more clearly. For example, merge to main should build and publish an immutable artifact, but production registry promotion should happen only through a release event or an explicit manual promotion.

Manual deploy, manual promote, and rollback workflows should be first-class platform features, not exceptions or forks. In real operations, we need a safe recovery path when the normal automation fails.

Longer term, the platform could also include artifact signing, SBOM generation, vulnerability gates, policy-as-code, and better deployment observability. That would make the Golden Container Build not just a CI/CD workflow, but a true enterprise delivery platform.

---

19. Short Version

If we simplify the whole 3.0 design into one sentence:

Golden Container Build 3.0 should build immutable artifacts once, verify and sign them, promote them through registry trust boundaries, deploy them through GitOps PRs, and provide manual recovery and rollback paths with full auditability.

This changes the conversation from:

Why do we have to follow this workflow?

to:

If we are building an enterprise golden path, should we separate build, promotion, release, and operations more cleanly?

❤️ Support This Blog

---

If this post helped you, you can support my writing with a small donation. Thank you for reading.

---

Coffee ☕ Thanks 🙏 Extra Support ❤️