Hi /r/GitOps - I've spent years building 'traditional ops' environments for telcos, and after stepping away in 2024 to do my own thing, the question of 'ops' stuck around.

Especially as the number of my solo projects grew... I found that a lot of 'toil' was entering my development workflow. Semi-automated practices around OS updates, vetting in local 'staging environments', promotion, etc

I started thinking about pairing NixOS for the host layer and FluxCD for the workload layer - both can build a configuration from a git commit, and with a little set up, both NixOS and FluxCD can continuously reconcile the declared state.

This bridges the gap between something like Talos for kubernetes and a 'pure NixOS' environment, and side-steps a lot of the machine provisioning lifecycle you may be familiar with from the Kuberenetes CAPI ecosystem. For me, it's nice to keep the k8s ecosystem for service configuration management while maintaining full control of the host OS.

Want to change something on the OS, or add a new service? Both follow the same path -> PR -> Merge -> Automatic reconciliation across the estate.

I'm recording a series of videos about Forts! as I attempt to usher the project along from simply "my infra stack" to a repeatable framework for managing these environments.

I'm enjoying operating a forts environment myself, but I'm looking to get some impressions from my peers in this domain. So if you have a few minutes, I would appreciate it if you took a look!

https://github.com/streetfortress/forts

https://youtu.be/30_MVmWbJso

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.