The Flux CLI now supports plugins and we have two official ones you can check out:
- Flux Mirror for syncing Helm charts, OCI artifacts and container images between registries.
- Flux Schema for validating Kubernetes manifests against JSON schemas and CEL rules, offline from clusters.
These plugins should be useful to anyone working with OCI and Kubernetes.
Notably flux-mirror uses a CNCF license which makes it a great replacement for bitnami/charts-syncer.
This release also adds:
- Field ignore rules that let server-side apply share ownership with other controllers.
- Git commit signing and verification using SSH keys.
- Kubernetes Workload Identity authentication for OpenBao/Vault and AWS CodeCommit.
- Post-Quantum SOPS decryption for secrets using compatible age ciphers.
In the ecosystem, the Flux Operator v0.53.0 web UI has a new Workloads Dashboard and can view logs for Pods.
hi friends, Flux maintainer here. Stefan gave this talk at FluxCon EU
He maps out some "levels of detachment" for software & platform engineering that we've all been watching happen. Copilot autocomplete -> chat interfaces -> spec-driven development -≥ agent teams -≥ fully autonomous dark factories. Same progression applies to ops: agents that go into your clusters, diagnose issues, and present resolution plans without human intervention.
GitOps still matters in this world of agents:
1. Git as the interface to production (agents open PRs instead of running kubectl directly)
2. Git as persistent memory (incident RCA gets committed so the next similar event resolves faster)
3. Desired state that includes agent definitions (recover your AI orchestration the same way you recover a cluster: point Flux at a repo)
He also announced fluxcd/agent-skills, which are OCI packaged, verifiable skills for Flux that should progressively discovery instead of loading everything into context. We've seen a 32% improvement on knowledge tasks and 29% on repo audits vs. baseline models running against real public repos.
Stefan's anecdotes on developing agent tooling are relevant beyond Flux.
Every harness defines agents differently (markdown, TOML, JSON), there's no portability, and reproducibility and measurement is expensive and time-consuming.
several nixy devtools do some process management now
something we're trying in Flox is per-project services run /w process-compose.
they automatically shutdown when all your activated shells exit, and it feels really cool
This is an awesome writeup of the tools and culture issues you run into maintaining dev environments.
From post, the problems that justified central dev boxes are roughly:
1. dependency / config mgmt / env drift on laptops
2. collaboration / debugging between engineers
3. compute scaling + optimization
4. supporting devs with updates and infra changes
The last one is particularly interesting to me, because supporting the dev env is separate engineering role/task that starts small and grows into teams of engineers supporting the environment.
I'm helping build Flox.
We're working on these pain points by making environments (deps, vars, services, and builds) workable across all kinds of Mac/Linux laptops and servers.
1) a. Virtualize the pkg manager per-project
b. Nix packages can install across OS/arch pretty well
2) Imperative actions like `flox install`/`upgrade` always edit a declarative env manifest.toml -- share it via git
3) less Docker VM's -- get more out of devteam Macbooks
4) reduce toil with a versioned, shareable envs
--> less sending ad-hoc config and brew commands to people (as mentioned in the post.)
Just `git pull && flox activate`.
I think on problem point #2, collab tools are advancing to where, pairing on features, bugs, and env issues can be done without central SSH. (ex: tmate, vscode liveshare, screensharing, etc) -- however, that does sort of fall apart on laptops for async debugging of env issues (ex: when devprod is in the US, and eng is in London).
Having universal telemetry on ephemeral cloud dev-boxes with a registry and all of the other DNS and SSH goodies could be the kind of infra to aspire to as your small teams run into more big-team problems.
In the Stripe anecdote, adopting the centralized infra created new challenges that their devprod teams were dedicated to supporting:
- international latency from central, US-based VM's
- syncing code to the dev boxes (https://facebook.github.io/watchman/)
- linting, formatting, generating configs (run it locally or serverside?)
- a dev workflow CLI tool dedicated to dev-box workflows and sync'ing with watchman's clock
- IaaS, registry, config, glue for all the servers
This is all very non-trivial work, but maybe there's a future where people can win some portability with Flox when they are small and grow into those new challenges when it's truly needed -- now their laptop environments just get a quick `flox activate` on some new, shiny servers or Cloud IDE's.
I really like the notes from the author on how useing Language Server Protocol across a high latency link has great optimizations that work along side the watchman sync for real-time code editing.