Meta's Cloud Foundation team has taken Kubernetes application rollouts out of its Terraform release process, and routine application deployments that took more than four hours now take minutes, according to the CNCF. The foundation named the team winner of its End User Case Study Contest at KubeCon + CloudNativeCon North America 2026 in Salt Lake City. The new platform runs on Argo CD and Kargo across approximately 100 Kubernetes clusters that support AI research and inference. Behind the speedup is a structural change other platform teams can copy. Meta stopped shipping applications and infrastructure through the same pipeline. One pipeline, two jobs The team has more than 15 engineers and runs those clusters across multiple cloud providers and accelerator families, per the announcement. Before the change, Terraform handled both infrastructure provisioning and Kubernetes application deployment. The full case study is titled "GitOps at Meta: How We Went From Terraform on Cron to GitOps for AI Infra", which tells you how the old loop ran. The CNCF lists three consequences of that design. Even a routine application update was tied to a lengthy infrastructure release. A stalled rollout could delay unrelated releases, because everything shared one deployment path. And there were no automated health checks to verify application status after a deploy. The second one is the on-call problem. A shared path means one stuck change holds the queue for every team behind it. A missing health check means the pipeline reports success on a deploy nobody has verified. Where each tool sits now The new split, as the CNCF describes it: Terraform still manages infrastructure. Argo CD reconciles application deployments against configuration stored in Git. Kargo orchestrates release promotion across environments. Some background for readers who haven't run either tool. Argo CD is a pull-based reconciler. A controller compares what Git says a cluster should be running with what it is actually running, and syncs the difference. Kargo works one layer up. It tracks versioned bundles of artifacts and moves them from one environment stage to the next, writing the change to Git so Argo CD can apply it. Per the announcement, this setup gives Meta independent rollouts, automated health checks and versioned release records. The CNCF says those records improve deployment traceability and recovery. For an SRE, recovery is the word that matters. A versioned record of what was promoted where is the starting point for a rollback that doesn't depend on someone's shell history. Meta also hid most of the machinery from application teams. Developers write a short application definition, and the platform generates the Argo CD and Kargo configuration from it. Application teams get independent promotion and health verification without maintaining that configuration themselves. What the announcement doesn't tell you The press release has no detail on how the health checks are defined, what a failed check does to a promotion, or how rollbacks work in practice. It doesn't say how many applications have moved over either. "More than four hours to minutes" is Meta's number for routine deployments, and there is no breakdown behind it. The full case study may answer some of this. The announcement does not. The roadmap hints at where it still hurts. Meta plans to move to a centrally managed Argo CD service to cut maintenance overhead across the fleet. It is also exploring upstream contributions on container registry authentication and on Argo CD performance in large clusters. Running a GitOps controller per cluster at this scale has a cost, and Meta is still paying it. How popular tools handle promotion across clusters Meta's pattern has two parts: a reconciler that keeps clusters matching Git, and a promotion layer that decides when a version moves to the next environment. Tools split that work differently. Argo CD is the reconciler Meta chose. ApplicationSets let one definition fan out across many clusters, and the web UI shows sync and health state per application. Argo CD has no promotion model of its own. Kargo fills that gap for Argo CD users. It models environments as stages and promotes versioned artifacts between them. If you already run Argo CD, it is the shortest path to what Meta built. Flux is the other CNCF-graduated GitOps reconciler. It is built as a set of controllers, and its image automation controllers can write new image tags back to Git. Teams that prefer composing small controllers over running one larger application tend to pick it. Spinnaker takes the push-based pipeline route, with deploy stages, manual judgment gates and automated canary analysis. It handles multi-cloud promotion well. It is also a heavy system to operate. GitHub Actions and GitLab CI/CD both offer environments with protection rules and approval gates, and work well when the deploy logic already lives next to the code. Both push to the cluster from a runner, so they don't correct drift in the cluster between deploys. Buddy is also push-based. It chains Kubernetes and Helm deploy actions with manual approval steps in one pipeline, and you can build and edit that pipeline in a UI or in YAML. The concrete reason to look at it here is team size. A small team with a handful of clusters can get gated, per-environment promotion without installing and upgrading a controller in every cluster. At Meta's scale, a pull-based reconciler is the better fit. With around 100 clusters, in-cluster drift correction and Git as the single record of desired state are worth the operating cost, and Meta's own roadmap shows how large that cost is. A push pipeline only knows what it deployed. It doesn't know what someone changed by hand afterwards. Meta says it will keep expanding adoption of the platform. The open question for anyone copying it is the one Meta is working on now: keeping Argo CD fast and maintainable once the fleet gets large.