In a recent post, LinkedIn revealed it has replaced Argo CD with its own GitOps engine. This new system deploys applications across over 250 Kubernetes clusters. It supports more than 4,000 services and manages over 100,000 deployments each week. According to a post, deployment infrastructure failures fell from 925 to 63 despite a 3.7x increase in deployment volume. The median time to detect and conclude a failed deployment dropped from 16.1 to 2.45 minutes.
LinkedIn started with one Argo CD instance per cluster, a topology it chose because Argo CD already managed its cluster add-ons that way. Clusters run up to 5,000 nodes each. A central deployment orchestrator spawned an ephemeral pod per deployment, with Argo CD hidden behind it. The team lists seven problems that emerged at scale. Argo CD doesn't have an observedGeneration, so you can't link sync and health status to a specific deployment. LinkedIn created a Lua health check that uses a tracking annotation to address this. A Synced and Healthy application could also resolve to an unintended revision when stale repo-server cache entries were used.
Two of the issues were architectural. Argo CD maintains one watch per group-version-resource across Applications. LinkedIn’s clusters have low resource-type diversity. This means etcd churn from one app can slow syncs for all apps. In one test, sync took under 3 minutes on a cluster with 60,000 pods and over 10 minutes with more than 80,000. The second was server-side-apply PATCH. Kubernetes truncates managedFields once an object has had more than 10 distinct field managers, and the API server then forgets who owns a field. In LinkedIn's AI workloads, which run multiple containers per Pod, a container removed from a manifest could therefore survive on the live Pod. The team had pruning disabled because destructive operations in production require approval. The remaining problems were CRD schema changes that required controller restarts across the fleet. Some OutOfSync states did not reflect real drift. Error messages were buried in boilerplate.
LinkedIn evaluated Flux but found it shared the same controller paradigm, so it built the engine as a library. Each deployment runs in its pod, with no shared controller state. Updates use PUT for full replacements, not PATCH. They retry on resourceVersion conflicts with exponential backoff. A 3-way diff across the live object, the previously deployed manifest, and the newly rendered manifest detects drift, and genuine drift fails the deployment. The same pod then watches the object's status until it converges or times out, and the API server unwraps errors for the user. Objects missing from the rendered manifest become deletion candidates, subject to delete protection, and convergence logic for LinkedIn's CRDs is built in.
The comparison uses the same calendar month a year apart. The migration ran from July 2025 to April 2026, which makes May 2026 the first clean post-migration month. The infra failure count covers only failures caused by the deployment system and excludes drift errors, since the two systems define drift differently. LinkedIn states that the improvement isn't solely due to the new engine. The orchestrator's error classification and reliability also got better during this time. The median duration for successful deployments is similar for both systems. However, the mean and tail have improved. The team attributes this to a namespace-scoped informer cache.
The engine is internal, and no open-source release is mentioned. Argo CD remains in use at LinkedIn for cluster add-ons and system services. The team had also found that maintaining 200+ Argo CD instances made each upgrade a multi-week project.
Teams running Argo CD at scale can check two things without a rewrite. Count the field managers on long-lived objects, since managedFields truncation can leave orphaned containers that produce no error. Then check whether sync latency tracks total pod count on shared clusters, which points to watch contention. LinkedIn concludes that the build-or-extend decision relies on the operational model. They say that per-deployment isolation, not controller tuning, allows the system to scale with compute.
LinkedIn is not the only large operator to build deployment logic around Kubernetes rather than adopt a general-purpose GitOps controller. Uber’s Up platform assigns each deployment to a dedicated controller. This is the Uber Deployment Controller. It translates the intent into Kubernetes primitives and sends status updates. This helps the workflow move forward. Uber keeps a long-running controller, while LinkedIn runs one ephemeral pod per deployment with no shared controller state.
Airbnb went further back and built its own tooling years earlier. In a talk at QCon London 2019 on InfoQ, infrastructure engineer Melanie Cebula introduced kube-gen. This internal framework creates Kubernetes configuration from one versioned project file. It also includes a deploy tool that applies or replaces objects and restarts pods, so changes take effect right away. Airbnb's deploy tool also returns an atomic success or failure, and a container that restarts for 30 seconds at the start of a rollout counts as a failed deploy. Airbnb was then at roughly 125,000 production deploys a year.