LinkedIn Replaces Argo CD for Application Deployments With Its Own GitOps Engine and Reports 925 Infra Failures in May 2025 Versus 63 in May 2026
LinkedIn describes replacing Argo CD with its own GitOps engine for application deployments, keeping it for add-ons and system services; infra failures fell from 925 to 63, but LinkedIn says not all of that is the engine.
Editor's Note ·
- Clarification:
- The summary says "LinkedIn says not all of that is the engine" and the Overview says LinkedIn says "the improvement cannot be completely attributed to the migration to the new engine", both placed against the fall in infra failures from 925 to 63. In LinkedIn's post that caveat is written about the total failures remaining constant in absolute terms (11,175 in May 2025, 10,023 in May 2026) despite 3.7x the deployments, because error classification and reliability in the deployment orchestrator also improved. For the infra-failure count the post says only failures "completely attributable to the deployment stack" were included and drift errors were excluded on both sides. InfoQ describes the caveat more broadly ("the improvement isn't solely due to the new engine").
- Clarification:
- The headline's "Infra Failures" means the post's "deployment infra failures": failures due to the deployment system, excluding application, controller and invalid-manifest failures and, on both sides, drift errors. It is not LinkedIn's total failure count, which was 11,175 in May 2025 and 10,023 in May 2026.
Overview
LinkedIn has described replacing Argo CD with a GitOps engine it built itself for deploying applications to Kubernetes, in a post on the LinkedIn Engineering blog dated November 2, 2026 and authored by Ramesh G. Iyer. InfoQ reported on the post on November 12, 2026. According to the post, the migration began in July 2025 and concluded by April 2026, and Argo CD is still used for deploying cluster add-ons and system services. InfoQ says the engine is internal and that no open-source release is mentioned.
The post puts the deployment infrastructure failure count at 925 in May 2025 and 63 in May 2026. LinkedIn says the improvement cannot be completely attributed to the migration to the new engine.
What LinkedIn says it runs
The post’s abstract describes 250+ Kubernetes clusters across a fleet of 500,000 bare metal servers, running more than 5 million containers, with more than 4000 services and over 100,000 deployments a week. LinkedIn chose one Argo CD instance per cluster because Argo CD was already managing its cluster add-ons and system services that way, and it ran every deployment in its own ephemeral pod, spawned by a central orchestration service rather than a long-running controller. The post says that per-deployment model was set before the first application was onboarded.
The problems the post lists
InfoQ counts seven problems in the post. Among them, as described by LinkedIn:
- Status mapping. The post says there is no ObservedGeneration in Argo CD’s status object, so a sync or health status cannot be tied to a specific deployment; LinkedIn wrote a Lua resource customization that reads a tracking annotation to mimic it. It also says stale repo-server cache entries can produce an unintended revision in non-happy-path scenarios.
- Noisy neighbours. Argo CD keeps a single watch per group-version-resource, so etcd churn from one application can slow syncs for others. In one scale test the post reports that sync took under 3 minutes in clusters with 60,000 pods and more than 10 minutes with more than 80,000.
- PATCH side effects. The post says managedFields information is truncated once an object accumulates more than 10 distinct field managers, after which a container removed from a manifest can stay on a live Pod. LinkedIn says this is rare but hard to diagnose and that it kept pruning disabled because destructive production operations need approval.
- Operations. LinkedIn also lists CRD schema changes that required controller restarts, OutOfSync states that were not real drift, and wrapped error messages, and says that maintaining 200+ Argo CD instances became an immense overhead and that rolling out a new Argo CD version became a multi-week project.
The post says LinkedIn evaluated other GitOps engines, including Flux, but found that they shared the same controller paradigm. It also says that the roadblocks were not failures of the tool but came from LinkedIn’s operational model outgrowing a general-purpose system.
The replacement design
The engine is a library, not a controller. Per the post, it uses PUT rather than PATCH, retries on resourceVersion conflicts with exponential backoff, and runs a 3-way diff of the live object, the previously deployed manifest and the newly rendered manifest, failing on unresolved drift. InfoQ adds that the same pod then watches the object’s status until it converges or times out, and that objects missing from the rendered manifest become deletion candidates subject to delete protection.
Results and their stated limits
The post’s results tables, which appear as images, compare May 2025 and May 2026. They list 105,925 deployments and 11,175 failures in May 2025, against 391,711 deployments and 10,023 failures in May 2026, with deployment infra failures at 925 and 63. LinkedIn defines those as failures due to the deployment system, excluding application, controller and invalid-manifest failures and, on both sides, drift errors, because the two systems define drift incompatibly. The post reports that the median time to detect and conclude a failed deployment fell from 16.1 to 2.45 minutes, and calls the successful-deployment median comparable across the two periods; its table lists 10.5 minutes in May 2025 and 9.15 in May 2026.
LinkedIn says the total failures remaining constant in absolute terms cannot be completely attributed to the migration, because error classification and reliability in the orchestrator also improved. InfoQ repeats that the improvement is not solely due to the new engine.
The Herald’s own arithmetic from the post’s table, recomputed from the raw counts: deployments rose by a factor of 3.70, matching the post’s 3.7x; total failures equalled 10.5% of deployments in May 2025 and 2.6% in May 2026; and infra failures were 8.3% of all failures in May 2025 and 0.6% in May 2026. These are Herald calculations, not LinkedIn figures.
What the Kubernetes and Argo CD sources add
The Herald read the Kubernetes source at tag v1.37.2 for the managedFields behaviour the post describes; the post does not say which Kubernetes version LinkedIn runs. A constant, DefaultMaxUpdateManagers, is set to 10, and its code comment describes it as the “default maximum retained number of managedFields entries from updates”, with the oldest entries merged when the number of update managers exceeds it. In capmanagers.go, the code that gathers entries to count skips those marked as applied, the Apply path passes straight to the wrapped manager, and merged entries go into per-version entries named “ancient-changes”. The Herald’s reading is that the cap of 10 counts update entries rather than Server-Side Apply entries and that merged entries are bucketed rather than deleted; the post’s wording, “more than 10 distinct field managers”, does not draw that distinction, and the Herald did not test LinkedIn’s scenario. The Kubernetes documentation says a field’s recorded operation is Apply when the request that last changed it was a Server-Side Apply patch and Update otherwise, and that when a field is removed from an applied manifest, Server-Side Apply checks whether any other field manager also owns it and, if none does, deletes it or resets it to its default. The Herald found no mention of the cap on that page.
On observedGeneration, an Argo CD issue opened in April 2025 proposes adding it to ApplicationCondition. In November 2025 a participant, crenshaw-dev, wrote that the Application’s status field is not set up as a subresource and that, until that changes, “I think we have to just document the limitation.” The issue was still open when the Herald read it on November 13, 2026. It is about ApplicationCondition, while the post discusses the sync and health status; it predates the post and is not a response to it.
What is not known
The post does not name the engine or state a release plan, and InfoQ says none is mentioned. The figures are LinkedIn’s own, covering one month a year apart, and none of the cited sources reports an independent measurement of them. None of the cited sources includes a response from the Argo CD project to the post.