Crossplane 2.0 matters for AI infrastructure because it gives platform teams a declarative way to expose governed, reusable services to agents and developers through one control plane instead of a maze of tickets, scripts, and cloud consoles.
Morgan Stanley’s multi-year Flux journey shows that GitOps at enterprise scale is not just about choosing a reconciler. It is about onboarding, tenancy boundaries, source-of-truth design, and relentless tuning once the cluster count and resource count get large.
Flux 2.8 ships Helm v4 support (including server-side apply) and pushes more deployments toward kstatus-style readiness. That combination changes the operational contract of GitOps: fewer false ‘healthy’ signals, better drift visibility, and sharper rollback decisions.
Flux 2.8 goes GA with Helm v4 support, server-side apply defaults, kstatus health checks, and new features aimed directly at reducing MTTR in GitOps workflows.
Flux 2.8 lands Helm v4 support (SSA + kstatus health checks), reduces MTTR by canceling health checks when new revisions appear, and expands GitOps feedback loops with PR/MR comment providers and a new Flux Operator Web UI.
EKS Capabilities package Argo CD, AWS Controllers for Kubernetes (ACK), and Kube Resource Orchestrator (kro) as managed, Kubernetes-native building blocks. Here’s what changes when platform teams can compose AWS resources and Kubernetes resources behind custom APIs — without running the controllers themselves.
Flux 2.8 GA ships with Helm v4 support, bringing server-side apply and kstatus-based health checking to Helm releases. Here’s why that’s bigger than it sounds—and how platform teams should approach the upgrade.
AWS is packaging common platform components (GitOps and infrastructure orchestration) as managed, Kubernetes-native ‘capabilities’ for Amazon EKS. Here’s what it changes for day-2 ops, how it compares to rolling your own controllers, and what to watch before you standardize on it.
Helm v4.1.1 is a patch release, but it’s a good excuse to revisit how chart supply chains, plugin sprawl, and CI-driven upgrades actually break production. Here’s a pragmatic operator playbook.
Backstage-style portals, GitOps controllers, and IaC engines (Terraform/OpenTofu/Pulumi) are converging into repeatable platform ‘golden paths.’ Here’s a 2026 blueprint that stays modular.
GitOps is great until you run a large Kubernetes fleet. Fastly describes the gaps they hit — orchestration, validation, blast-radius control — and how they layered a rollout system on top of Argo CD. Here’s what platform teams can steal.
OpenTofu’s CNCF home matters less for politics and more for operations: predictable releases, ecosystem trust, and a path to standardizing policy. Here’s a practical blueprint for running OpenTofu at scale with GitOps, drift control, and safe migration from Terraform.
Argo CD 3.3.0 ships new actions and upgrade considerations that matter most to self-managing installations—where the GitOps tool is also managed by GitOps.
Argo CD 3.3.0 sharpens the line between old apply behaviors and server-side apply. If Argo CD manages itself, upgrades can fail unless you adopt the right sync options—making this a good time to audit GitOps bootstrapping patterns.
