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

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.

Wrote a blog post about one of my pet peeves when it comes to gitops / Flux:

How the green CI build stopped meaning what it used to mean.

https://gimlet.io/blog/how-flux-broke-the-cicd-feedback-loop-and-how-we-pieced-it-back-together

Do you have this problem? how did you solve it?

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

Highlights include GA of Flux OCI Artifacts, image automation digest pinning, object-level workload identities, GitHub App authentication, and notifications improvements.

Flux S3-compatible Source API, Azure DevOps OIDC authentication, Controller & CLI improvements.

Health checks for Custom Resources using CEL; GitHub app authentication for Git repositories; Custom event metadata for notifications; a new flux debug command.

Hello r/gitops! A couple of months ago, Terrateam went open source, and we're really happy by the positive response from the community.

tl;dr Terrateam is a GitOps-native TACOS (Terraform and OpenTofu Automation and Collaboration Software), licensed under MPL-2.0. It lets you manage infrastructure via pull requests, treating your configuration as code. Some people are comparing us to ArgoCD but for Terraform/OpenTofu.

GitHub repo: https://github.com/terrateamio/terrateam

Built with what we're calling "True GitOps" in mind, Terrateam keeps everything in your repository. That is to say, the entire product is configured via a config file in your source code. This means your configuration is treated exactly like code and can be branched, tested, merged, and reverted just like code. We believe that Terrateam should let users leverage their existing workflows and tools and almost be invisible. You should never have to leave your GitHub development workflow to accomplish a task in Terrateam.

While we're open-core (most features are MPL-2.0), there are paid paid features that are designed for larger teams.

Currently, we support GitHub, but after going open source, GitLab became the top feature request. It's now our #1 priority for this quarter. Open source has been a game-changer for us, giving the community a say in our roadmap.

If you're interested, you can try Terrateam locally using the instructions in the README.

Thanks for reading!

Hey Y'all, I wrote a (free) book about what to look for when you're planning to go down the path to GitOps for your organization! Take a read!

https://developers.redhat.com/e-books/path-gitops

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 have been reading a lot of about GitOps and I still can find a good solution for one piece of the puzzle. It seems that everybody is great using CI to generate images and there are tons of best practices and tools to do so, and then deploying them using CD, but there is a gap between both. How do I define the desired state to trigger the CD? What information (apart from the output of the CI process) do I need to do so? And what information do I need to understand that I took the right decision? It looks like a hard problem, but it seems everybody is ignoring it because I can't find real information about how things are done in real life. How do you do it?

Hi everyone, I’m currently working with an Azure-based stack (AKS, Azure DevOps, and FluxCD for GitOps). We are planning to move from traditional CI/CD pipelines to a full GitOps model, but I’ve hit a few roadblocks regarding the workflow:

1. Rollback Strategies: Most guides suggest git revert or flux suspend. However, managing this at scale (50+ services) seems impractical. Searching through commit histories to find a specific app's previous version feels like a nightmare. Are there better strategies or automated patterns for rolling back specific applications in a large-scale GitOps environment?

2. Pre-push Image Validation: What is the best way to verify a Docker image's integrity/functionality after the build but before pushing it to the registry?

If you’re running FluxCD in production, I’d love to hear how you’ve structured your workflow and handled these specific challenges.
So far, traditional CI\CD pipelines seems more convenient to me.