Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket depends on several artifact classes:
- Talos installer and upgrade images
- VM base images
- container images
- provider and recovery artifacts used during provisioning
Harbor is only one piece of this. The platform still needs a coherent lifecycle for how artifacts are created, promoted, replicated, trusted, and retired.
Decision
Dataverket treats images and deployment artifacts as a first-class lifecycle domain.
The platform must define lifecycle rules for:
- creation or ingestion
- validation and trust
- promotion between environments or stages
- replication between datacenters
- retention and retirement
Artifact classes
The first architecture must account for at least:
- Talos images
- VM base images
- container images
- provisioning artifacts such as boot assets and machine configs
Different artifact classes may use different storage backends, but they should still follow a common lifecycle philosophy.
Ownership model
Ownership should be split pragmatically:
- Register or registry-related capability for container image distribution
- Maskin for VM and provisioning artifact consumption
- Plattform for cluster and Talos artifact consumption
- Sentral for metadata, promotion state, and audit visibility where needed
Promotion model
Artifacts should not move directly from “found somewhere” to “production use”.
The lifecycle should support:
- staging or validation
- approved promotion
- site-aware replication
- retirement of superseded artifacts
The exact pipeline can vary, but the architecture should assume promotion is explicit.
Multi-datacenter implications
Because Dataverket is multi-datacenter, artifact lifecycle must support:
- replication between sites
- operator visibility into artifact availability per site
- degraded-mode behavior when one site lacks a needed artifact
- clear trust and provenance across replication paths
Trust and security
Artifact lifecycle must align with the platform security model.
That means:
- provenance matters
- trusted artifacts should be distinguishable from unverified ones
- promotion should be auditable
This ADR does not define the full signing model, but it requires the platform to treat artifact trust seriously.
Operational visibility
Operators should be able to inspect:
- what artifact version is in use
- where it is available
- what was promoted or retired recently
- which workloads depend on a given artifact class
Explicit non-decisions for now
This ADR intentionally does not yet choose:
- exact registry implementation beyond current Harbor direction
- exact VM image build pipeline
- exact artifact signing technology
- exact replication tooling
Those require later implementation decisions.
Consequences
- artifact handling becomes a coherent architecture concern rather than a set of ad hoc scripts
- Dataverket can reason about promotion, rollback, and cross-site availability more clearly
- image trust and availability become explicit operator concerns
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- Platform security expectations must align with 024-platform-security-strategy.md.
- Storage and availability assumptions must align with 015-storage-platform-and-persistence-strategy.md.
- Multi-datacenter behavior must align with 012-inter-datacenter-topology-and-failover.md.
More Information
- artifact promotion workflow
- artifact trust and signing model
- VM image build and publication model
- cross-site artifact replication strategy
Audit
- 2026-03-14: ADR proposed.