Skip to content

Build1 publisher3 min readPublished

Flux moves GitOps' source of truth into registries you own, and mirroring becomes the prerequisite

Flux Mirror ships as a v2.9 CLI plugin that copies images, charts and desired-state artifacts from a config file. The Bitnami catalogue freeze is the argument for using it.

The Engineer · Build desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

Illustration accompanying Flux moves GitOps' source of truth into registries you own, and mirroring becomes the prerequisite
Generated illustration

What happened

  • Flux has introduced Flux Mirror, a CLI plugin that mirrors container images, Helm charts and OCI artifacts between registries from a declarative configuration.
  • The plugin is part of the Flux v2.9 CLI plugin system and is presented as a way to keep Kubernetes clusters reconciling only from registries that teams operate themselves.
  • Flux Mirror fits into the Flux project's move towards Gitless GitOps, in which OCI registries become the source of truth for desired state rather than Git repositories at runtime.
  • The announcement highlights Docker Hub rate limiting and Broadcom's decision in 2025 to freeze the popular free Bitnami catalogue as reminders that external registries' policies can become part of a production architecture overnight.
  • The Flux CD team is quoted: "Combining identity policies, attestations, and minimum artifact age turns your mirror into what we've been calling a supply-chain diode. Every Kubernetes user should have a deliberate answer for where these artifacts live, who can change them, and what happens when the upstream disappears."

Compiled by The EngineerSomething wrong?How this is made

Why it matters

Flux has released Flux Mirror, a CLI plugin that copies container images, Helm charts and OCI artifacts between registries from a declarative configuration file [1]. It is part of the Flux v2.9 CLI plugin system, and it is positioned as the way to get clusters reconciling only from registries the team itself operates [2].

The interesting part is not the copying. It is where the project says the truth now lives. Flux Mirror belongs to what the project calls Gitless GitOps, in which OCI registries, not Git repositories, are the source of desired state at runtime [3]. Git stays the place humans edit; the registry becomes the thing clusters actually read. Once that shift is made, the registry stops being a cache and becomes infrastructure, and the contents of that registry need to be described somewhere. Flux Mirror's config file is that description: what to mirror, from which sources, into which destinations, expressed as declarative state you can keep in version control [7].

The argument for bothering is recent history. The announcement points at Docker Hub rate limiting and Broadcom's 2025 decision to freeze the free Bitnami catalogue as evidence that an external registry's policy can become part of your production architecture overnight [4]. According to the Flux CD team, every Kubernetes user should have a deliberate answer for where these artifacts live, who can change them and what happens when the upstream disappears [5]. That is a reasonable test, and most shops fail it.

Mechanically, the scope is narrow and legible. Images are copied byte-for-byte, including multi-architecture manifest lists; HTTP Helm repositories are mirrored into OCI registries; and Flux's own desired-state artifacts can be relocated [6]. Charts served over HTTP are republished as deterministic OCI artifacts that Flux can consume without depending on an upstream chart index [17]. A selector pipeline of regular expressions, semantic version constraints, sorting and top-N limiting keeps you from mirroring the entire history of something you use three versions of [8].

The verification behaviour is where this stops being a copy tool. Flux Mirror can check that an artifact was signed by the expected person or build system before copying, using Cosign signatures and identity information, and it can carry SBOMs and build provenance across so the cluster can re-check that evidence [9]. It also enforces a minimum age on signatures, holding newly signed artifacts back until they have been public long enough [10]. The Flux team calls the combination of identity policy, attestations and minimum age a supply-chain diode [5]. The timing is not accidental: the announcement lands after the Shai Hulud worm and subsequent waves, and after the compromise of Aqua Security's Trivy GitHub Action left bad artifacts live for days [15]. A delay measured in days is the cheapest defence available against that specific failure.

Operationally it runs where you already have credentials: installed and synced from GitHub Actions via a setup action that verifies artifact attestations before first use, or as a Kubernetes CronJob sitting next to the clusters and registries [11]. Secrets, including short-lived cloud tokens, can be mirrored too and consumed through imagePullSecrets or secretRef [12].

None of this is unique. Guides from UnifyDrive and the Argo CD side already show regctl, Helm and ORAS stitched together to move charts and images and consume them through Argo CD's OCI support, though without integrated verification and drift detection [13], and helmper targets the same chart-and-image sync problem [14].

What to watch: whether teams actually narrow their allowed sources to their own registry, or just add a mirror and keep the upstream fallback. Also worth watching is coverage of the long tail, since Chainguard's data puts most container CVE instances in less popular images rather than the top twenty [16], and a top-N selector policy is exactly the kind of thing that mirrors the popular images well and the obscure ones badly.

Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories