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. This product 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.
Flux Mirror aims to solve long-standing operational problems with artefacts hosted in registries outside an organisation’s control. The announcement highlights familiar examples, including 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. In the announcement they argue that every Kubernetes user should be able to answer where their artefacts live, who can change them and what happens when an upstream source disappears, even if they are not using Flux itself.
Flux Mirror’s scope covers three main artefact categories and a small set of carefully defined features. It can copy container images byte-for-byte, including multi-architecture manifest lists, mirror Helm charts from HTTP repositories into OCI registries and relocate Flux's own desired state artefacts. A configuration file describes what should be mirrored, from which sources and into which destinations, allowing teams to encode registry content as declarative state in version control.
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.
- Flux CD team
Flux Mirror groups container images, Helm charts and Flux OCI desired state artefacts into a single relocation workflow, republishing HTTP-based Helm charts as deterministic OCI artefacts that Flux can consume without relying on upstream chart indices. It applies a selector pipeline of regular expressions, semantic version constraints, sorting and top N limiting so that teams mirror only the versions they use.
Flux Mirror can check that each artefact was signed by the right person or build system before it is copied, using Cosign signatures and identity information, and it can also carry over SBOMs and build provenance so that Flux can re check this evidence on the cluster. It also enforces a minimum age for signatures, so newly signed artefacts are held back and only mirrored after they have been public for long enough to be considered safe.
The announcement also shows how Flux Mirror fits operationally into Gitless GitOps pipelines built around Flux’s OCI support. Teams can install the plugin and run a sync from GitHub Actions using a dedicated setup action that verifies artefact attestations before first use, or as a Kubernetes CronJob colocated with clusters and registries. Secrets can also be mirrored, including short-lived tokens for cloud workloads, and used in imagePullSecrets or secretRef fields in Kubernetes clusters.
Flux Mirror does not exist in isolation, with other work happening to solve this problem. Guides from UnifyDrive and Argo CD show how regctl, Helm and ORAS can be combined to copy charts and images between registries and consume them through OCI support in Argo CD, albeit without the integrated verification and drift detection that Flux Mirror offers. Community tools like helmper similarly target Helm chart and image synchronisation, reinforcing that artefact relocation is now seen as its own operational concern.
The announcement discusses minimum artifact age, a significant issue right now with increasingly-fast supply chain attacks happening this year, such as the Shai Hulud worm and subsequent waves, and the compromise of Aqua Security’s Trivy GitHub Action which left bad artefacts live for days. InfoQ has also reported recently on coordinated defence in open-source ecosystems, and with Chainguard’s data driven view that most container CVE instances occur in the long tail of less popular images rather than the top twenty most widely used ones. Together they illustrate why policies that only allow signed, aged artefacts into a private registry can be seen as a form of one-way diode in the software supply chain.
Writing on X, Flux backers Control Plane concisely summarised the risks that Flux Mirror is trying to mitigate:
When you pull images directly from public registries in your Kubernetes Deployments, you make their uptime, rate limits, and retention policy part of your production architecture.
- Control Plane
In response to the LinkedIn announcement post, BIMP founder Hannah Foxwell accentuated the need for a registry to have all the artefacts devs require in one place:
Platform teams want dev teams using their private curated registry but to do that you have to make sure the registry has everything they need when they need it
- Hannah Foxwell
For teams already using Flux or considering Gitless GitOps, the plugin offers a way to relocate artefacts into private registries, enforce identity and minimum age policies and keep pull credentials rotated, without maintaining a large collection of bespoke scripts. For others, it serves as a detailed example of how to design declarative mirror pipelines that combine image, chart and configuration artefacts with verified provenance and controlled flow from public infrastructure into production clusters. A full run-through is available on Flux's website.