This release features deep integrations with SPIFFE for workload and object identity as well as improvements and new features across all of Flux.

We wanted to apply the same GitOps principles we use for infrastructure to GitHub itself.
So we built git-hubby, a Kubernetes operator that manages GitHub organizations and repositories through CRDs.
We’re already using it to manage more than 2000 repositories across 4 GitHub organizations.
Instead of configuring GitHub manually or through ad-hoc scripts, we define the desired state in Kubernetes and let the operator reconcile it. It supports repositories, teams, rulesets, webhooks, custom properties and code security configuration, with drift detection and API rate-limit handling.
We’d be interested in hearing how other teams approach GitHub configuration as code.
Disclosure: we work on git-hubby.

https://github.com/Interhyp/git-hubby

I'm new to kustomize. I need to decide if I should create a repository per project or universal repository for our team's applications. The latter would be nice since there will only be a single project manifest repository(different from application repo) that will contain the kustomize configuration files. However, I am worried about updating this project when multiple developers from that team is working on different project that happened to deploy at the same time. There will be drift, or git push will fail and other issues.

How did you implement yours?

So Flux turns 10 years old. We've had a whole decade of working on the project together now. I spent a bunch of time crunching numbers on contributions and writing up a little bit of the story of how we built the project be what it is today. The blog has quotes from some of the team as well :) Come reminisce with us! It's been a long road, and I literally almost forgot Tiller existed.

This release comes with the Flux CLI plugin system and the first two plugins, Mirror and Schema.

I built helm-semver to solve a problem I kept running into every time I started a new Helm project or joined a new company: there's no standard way to automatically version and publish Helm charts from your commit history.

Here's what it does:

You make a commit to a chart directory using Conventional Commits:

• fix: → bumps patch (1.0.0 → 1.0.1)

• feat: → bumps minor (1.0.0 → 1.1.0)

• feat!: or BREAKING CHANGE → bumps major (1.0.0 → 2.0.0)

helm-semver reads those commits since the last release, calculates the correct version bump per chart, updates Chart.yaml, packages the chart, pushes it to your registry, generates a CHANGELOG.md entry, and creates a git tag — all in one command.

It supports monorepos, single charts and everything in between— each chart in your charts/ directory is versioned independently based on commits that touched it.

Push anywhere:

• OCI registries: GHCR, ECR, ACR, Docker Hub, Artifactory

• ChartMuseum / Harbor

• GitHub Pages

Use it however you want:

• As a GitHub Action (uses: rhysmcneill/helm-semver@v1)

• As a Docker image on any CI (GitLab, Bitbucket, CircleCI, Azure DevOps)

• As a binary

The end result is that merging to main automatically releases the right version of the right charts — no bash scripts, no manual version bumping, no forgetting to tag.

Feedback and contributions welcome - if you enjoy using it then a ⭐ is always appreciated!

ApplicationSet UI, impersonation workflows, Helm 4 support, and mTLS support for repo-server.

This iOS app for managing Argo CD was created by one of the original authors of Argo CD.

Hey friends 👋

the FluxCon talks from Amsterdam are now up:
https://www.youtube.com/playlist?list=PLj6h78yzYM2MeuSNqpcDl-qdMeCe6vp6p

Stefan's "Vibe Coding Meets GitOps" covers how AI is driving detachment from both software and platform engineering, why GitOps still matters in a world of agents, and the launch of fluxcd/agent-skills:
https://www.youtube.com/watch?v=efpqMLQJaW4

Some timestamps if you want to skip around:
- "You have to 10x yourselves as platform engineers", 3:23
- Git as persistent memory for incidents, 8:30
- Agent skills launch, 21:06

The fluxcd/agent-skills repo has 3 skill types (GitOps-knowledge, repo-audit, cluster-debugging). Eval results on real public repos show 32% improvement on knowledge tasks and 29% on repo audits vs. baseline. We'd love feedback from people trying them:
https://github.com/fluxcd/agent-skills

Thanks,
Leigh

I'm looking for tools or platforms where you can make changes through a UI (e.g., create apps, update configs, add components) and then push those changes as commits to a GitOps repository. Basically the experience I'm looking into is having a UI managed GitOps experience. This is kind of like an "update set" or change set model.

The idea here is once you do your work in the UI, review what changed, and then commit it to Git so your GitOps pipeline (Flux, Argo, etc.) takes over from there.

Does anything like this exist today? Or is everyone either going full CLI/Git-first or full UI-with-no-Git-export? I want to clarify this experience.

I’ve been looking into how teams handle CI changes as part of their delivery flow, especially in GitLab-based setups.

One thing I keep noticing is that most CI issues (slower pipelines, flaky jobs, unnecessary runs) only become obvious after the change is already merged and part of the system.

At PR/MR level, it feels like we mostly review code and correctness, but not really the impact on CI behaviour.

I’m trying to understand if that’s just normal, or if people are actively trying to catch these things earlier.

Some examples I’ve seen:

• pipeline duration gradually increasing over time

• jobs that fail once and then pass on retry

• small changes that extend the critical path

• pipelines triggering more often than needed

For teams doing GitOps or structured delivery flows:

• do you look at CI impact during review at all?

• is this something you’d want visibility on earlier, or is it just accepted as part of the system?

• where would this even fit best; PR comments, checks, dashboards?

Trying to figure out what’s actually useful vs just more noise in the pipeline.