LinkedIn drops Argo CD and builds its own GitOps engine to scale Kubernetes

What LinkedIn announced

In a recent post, LinkedIn revealed that it replaced Argo CD with an internally built GitOps engine to orchestrate deployments across more than 250 Kubernetes clusters, according to InfoQ. The system serves more than 4,000 services and processes over 100,000 deploys per week.

The migration ran from July 2025 to April 2026, which makes May 2026 the first full month operating solely on the new engine. The company compared the same calendar month a year apart: deployment infrastructure failures dropped from 925 to 63, even as deploy volume grew 3.7 times. The median time to detect and complete a failed deploy fell from 16.1 to 2.45 minutes.

What the architecture with Argo CD looked like

LinkedIn started with one Argo CD instance per cluster, a topology chosen because the tool already managed cluster add-ons in that format. Clusters reach up to 5,000 nodes each. A central deploy orchestrator created an ephemeral pod per deployment, with Argo CD hidden behind it.

The team lists seven problems that emerged at this scale:

• Missing observedGeneration: there's no way to tie sync and health status to a specific deployment. LinkedIn created a Lua health check with a tracking annotation to work around this.
• Stale repo-server cache: an application marked Synced and Healthy could, in practice, resolve to a different revision than the intended one.
• Watch contention: Argo CD keeps one watch per group-version-resource across all Applications. Since LinkedIn's clusters have low resource-type diversity, etcd churn generated by one app delayed sync for all the others. In one test, sync took under 3 minutes in a cluster with 60,000 pods and more than 10 minutes with over 80,000 pods.
• PATCH via server-side-apply: Kubernetes truncates managedFields once an object exceeds 10 distinct field managers, and the API server loses track of who owns each field. In LinkedIn's AI workloads, which run multiple containers per pod, a container removed from the manifest could survive in the production pod. The team kept prune disabled because destructive operations in production require approval.
• Schema changes in CRDs required restarting controllers across the entire fleet.
• OutOfSync states that didn't reflect actual drift.
• Error messages buried in boilerplate, hard to interpret.

Why build instead of extend

LinkedIn evaluated Flux, but concluded it shares the same controller paradigm as Argo CD, which was precisely the root of the contention problems. The decision was to build the engine as a library, not as a central controller.

In the new design, each deployment runs in its own pod, with no shared controller state. Updates use PUT for full object replacement, instead of PATCH, with retries on resourceVersion conflicts and exponential backoff. A three-way diff, comparing the live object, the previously deployed manifest, and the newly rendered manifest, detects genuine drift and fails the deployment when it occurs.

The same pod watches the object's status until it converges or times out, and the API server passes errors back in readable form to whoever made the deploy. Objects missing from the rendered manifest become deletion candidates, subject to delete protection, and the convergence logic for LinkedIn's own CRDs is already built into the engine.

The numbers come with caveats

LinkedIn itself qualifies the comparison before celebrating the gains:

• The infrastructure failure count covers only failures caused by the deploy system, excluding drift errors, because the two systems define drift differently.
• The improvement doesn't come only from the new engine: error classification and orchestrator reliability also evolved during the same period.
• The median duration of successful deploys is similar across both systems; what improved were the mean and the tail, an effect the team attributes to a namespace-scoped informer cache.

The engine is internal and there's no mention of an open-source release. Argo CD remains in use at LinkedIn for cluster add-ons and system services. One of the motivations for the change, according to the company, was that maintaining more than 200 Argo CD instances turned every upgrade into a multi-week project.

It's not just LinkedIn reinventing the wheel

Other large-scale operations have also built deploy logic around Kubernetes instead of adopting a generic GitOps controller:

Airbnb's kube-gen generates Kubernetes configuration from a single versioned project file, and treats a container that keeps restarting for 30 seconds at the start of a rollout as a failed deploy. At the time of the talk, Airbnb was running about 125,000 production deploys per year.

What to check before thinking about a rewrite

LinkedIn itself suggests two diagnostics that teams running Argo CD at scale can perform without rewriting anything:

1. Count the field managers on long-lived objects: managedFields truncation can leave orphaned containers without generating any visible error.
2. Check whether sync latency tracks total pod count in shared clusters, a sign of watch contention.

For those who design deploy architecture day to day, LinkedIn's case isn't a verdict against Argo CD. It's an account of a scale limit: the tool proved solid up to a certain volume of clusters, nodes, and field managers per object, and the problem that emerged was structural to the central-controller model with shared watch, not a one-off bug.

LinkedIn's conclusion is that the decision to build versus extend depends on the operational model: per-deployment isolation, not controller fine-tuning, was what allowed scaling alongside available compute power. Teams that don't operate in that range of 5,000-node clusters are unlikely to run into the same seven problems, but the two diagnostics, managedFields and watch contention, are worth using as preventive checks in any Argo CD installation that already manages thousands of objects.