Artifact Management: Registries, Promotion, and Retention Policies

Build artifacts — the things produced by your CI that go to production — deserve more attention than most teams give them. They are the literal bits that run in production. Where they live, how they are named, who can read them, and how long you keep them are not afterthoughts.

This post is the artifact decisions that show up in real production systems: registries, promotion patterns, retention, and the operational details that matter when artifacts become incidents.

What Counts as an Artifact

The set is broader than just Docker images:

• Container images. The most common production artifact.
• Compiled binaries. Go, Rust, Java JARs, native executables.
• Packaged dependencies. Composer packages, npm packages, Maven artifacts.
• Frontend bundles. Compiled JS/CSS uploaded to a CDN.
• Database migrations as artifacts. Some teams treat compiled migrations as deployable units.
• Static configuration packages. Generated from templates, deployed alongside code.

Each has slightly different lifecycle requirements, but the broad strokes — store, version, promote, retain, eventually delete — apply to all.

Where Artifacts Live

The registry options have consolidated.

Container images:

• AWS ECR, GCP Artifact Registry, Azure Container Registry — cloud-native, IAM-integrated, fast within the same cloud.
• GitHub Container Registry (ghcr.io) — convenient if you already use GitHub.
• Docker Hub — public-friendly, less common for private prod images.
• Self-hosted Harbor — control and compliance at the cost of operating it.

Generic artifacts (binaries, archives):

• Cloud object storage (S3, GCS, Azure Blob) — cheap, durable, simple. The default for everything that does not have a specific registry.
• Specialized: Artifactory, Cloudsmith, Nexus — multi-format registries for teams with many artifact types.

For most teams: cloud-native container registry + S3 for everything else covers 95% of needs.

Naming and Versioning

The artifact's name and version determine whether you can reason about what is running where. The patterns that hold up:

Semantic version + commit SHA.

myservice:1.4.0-abc1234
myservice:1.4.0
myservice:latest

The full version includes the SHA for traceability. Tags for the semantic version and latest move as new builds come in. Production deploys reference the full SHA-tagged version.

Date + commit SHA.

myservice:2026-05-12-abc1234

Common when there is no real semantic versioning (continuous deployment, no release ceremony). The date sorts naturally; the SHA disambiguates.

Never deploy latest to production. It is ambiguous. A rollback cannot reference a specific version because the tag has moved. Even if you tag latest, deploy by the full SHA-suffixed version.

Promotion Across Environments

A single artifact should travel from staging to production unchanged. Re-building per environment is the most common artifact anti-pattern; it introduces drift and defeats the point of testing.

The promotion pattern:

1. CI builds the artifact on merge to main.
2. Artifact is tagged with the commit SHA, pushed to the registry.
3. Staging deploy references the SHA-tagged artifact.
4. After verification, production deploy references the same SHA-tagged artifact.

# Staging deploy
spec:
  containers:
    - name: app
      image: myregistry.example.com/myservice:abc1234

# Production deploy — same image
spec:
  containers:
    - name: app
      image: myregistry.example.com/myservice:abc1234

No rebuild. No different image. The bytes deployed to staging are the bytes deployed to production.

Some setups use environment-specific tags (myservice:staging, myservice:production) that point to the SHA-tagged versions. The tags are aliases; the underlying artifact is shared.

Retention Policies

Artifacts accumulate. A multi-service company with daily builds can produce thousands of images per month. Without a retention policy, storage costs grow forever and the registry slows to a crawl.

Typical retention rules:

• Production-deployed versions: keep indefinitely, or at least until clearly superseded.
• Staging-only versions: keep 30–90 days.
• PR/feature branch builds: keep 7–14 days.
• latest and version aliases: these are pointers, not separately retained.

Most registries support retention rules. ECR has lifecycle policies. Harbor has tag retention. Configure them deliberately, or your registry becomes the largest storage line item in your cloud bill.

Signing and Provenance

In 2026, signed artifacts have moved from "nice to have" to "expected."

Sigstore / cosign is the dominant pattern. The CI signs the image at build time; deployment verifies the signature.

# Sign
cosign sign --keyless myregistry.com/myservice:abc1234

# Verify at deploy time
cosign verify --certificate-identity ci@yourcompany.com \
              --certificate-oidc-issuer https://github.com/login/oauth \
              myregistry.com/myservice:abc1234

Keyless signing uses OIDC tokens — no long-lived private keys to manage. The signature attests "this image was built by this CI pipeline on this commit."

Pair signing with provenance attestations (the SLSA framework). The provenance describes how the artifact was built — the source repo, the build environment, the inputs. Verifiable supply chain.

Most production systems will require some flavor of this in the next few years. Adopting early is cheap; retrofitting after a supply chain incident is not.

Access Control

Who can read and write to the registry is a real security boundary.

• CI writes; humans rarely write. Direct human pushes to production registries are mostly an outdated pattern. CI service accounts should be the only writers.
• Read access is broader. Anyone who needs to debug, including humans on the team.
• Cross-account access is per-environment. Staging artifacts in a staging account, production artifacts in production. No cross-account pulls unless explicitly designed.

ECR, GCP Artifact Registry, and the others support fine-grained IAM. Use it.

Immutability

Once published, an artifact should not change. The tag myservice:1.4.0-abc1234 should always refer to the same bytes.

Tag mutability is a setting in most registries. Turn it off for production tags. Allow it only for moving aliases like latest (which should not be deployed anyway).

A mutable production tag is a credential and disaster waiting to happen. Someone pushes a new build to the same tag; production now runs different code than what is reflected in the git SHA.

Cleanup of Failed Builds

A failed CI run sometimes pushes an incomplete artifact before failing. The registry now has a tag that looks like a real build but is not deployable.

Two approaches:

1. Push only on success. The artifact push is the last step of the pipeline. If anything before it failed, no push.
2. Tombstone failed builds. Tag with a failed label or move to a separate namespace.

Option 1 is cleaner. Option 2 is useful when you want to capture the artifact for debugging without confusing the deployable list.

Multi-Region

For multi-region deployments, the registry should be reachable from every region where deploys happen. The options:

• Replicated registry. ECR pull-through caches, Harbor replication. The artifact is pushed once and replicated.
• Region-local mirrors. Push to one primary, pull through caches at the edge.
• Per-region pushes. CI pushes to multiple regions explicitly. Bandwidth-heavy, simpler than replication.

For multi-region production, the replicated registry is the cleanest pattern. Otherwise, region failover is a problem the day the primary registry has an outage.

The Practical Outcome

A mature artifact management setup:

• Container images tagged with version-sha and version aliases
• Same artifact promoted across environments (no rebuild)
• Retention policies tuned per environment
• Signed artifacts with provenance attestations
• Immutable production tags
• IAM-restricted writes
• Multi-region replication if relevant

Done right, artifact management is boring. Done wrong, it is the source of "why is staging different from production" debugging sessions and supply chain anxiety.

Reviewing how artifacts move through your delivery pipeline and noticing rebuilds, drift, or unclear retention? We help teams formalize artifact handling without slowing the deploy cadence. scopeforged.com