Kubernetes GitOps engines: When to replace Argo CD
Engineering orgs are hitting the limits of off-the-shelf delivery tooling and responding by building bespoke deployment control planes, because multi-cluster scale, isolation requirements, and...
Table of Contents
Replace Argo CD only when fleet scale, isolation boundaries, or rollout risk demand a control plane you can prove. InfoQ’s November 2026 reporting on LinkedIn’s custom GitOps engine shows the upside and the hidden cost: once deployments become a system of record across hundreds of clusters, “tool choice” becomes “platform architecture.”
Should we keep Argo CD, or build a custom GitOps engine?
InfoQ reported in November 2026 that LinkedIn replaced Argo CD with a custom GitOps engine to deploy across 250+ Kubernetes clusters supporting 4,000+ services. That is not a casual swap. That is a declaration that the delivery layer is now a first-class platform.
A CTO decision shows up inside that story: the moment GitOps stops being “a deployment tool” and becomes “the control plane for change,” the failure modes start to look like core infrastructure failures.
Three forces tend to trigger the pivot:
-
Fleet realities beat product assumptions. Many GitOps tools are designed around a small number of clusters, a manageable number of teams, and a limited set of rollout patterns. At hundreds of clusters, everything becomes a scaling problem: API pressure, reconciliation storms, config fan-out, and coordination between shared and per-team resources.
-
Isolation requirements become architectural, not procedural. When deployment automation can write to production, isolation is not a policy doc. Isolation is enforced by the mechanism. InfoQ’s November 2026 coverage of GitHub Agentic Workflows GA is about coding agents, but the relevant non-AI takeaway is the product direction: read-only defaults, separately scoped write jobs, and explicit budget controls. Modern platforms are moving toward “default deny, scoped escalation.” Delivery control planes are following the same path.
-
Rollout mechanics become your lead time ceiling. LeadDev argued in November 2026 that teams can get far faster while lead time barely moves. That gap often lives in the release system: approvals, batching, environment drift, and the time it takes to safely move a change through progressive delivery.
A custom GitOps engine is not “better GitOps.” A custom GitOps engine is an admission that deployment is now a differentiated internal product.
What delivery constraints are forcing bespoke control planes?
LinkedIn’s reported scale makes one constraint obvious: multi-cluster operations demand a deployment system that behaves predictably under extreme fan-out. The more interesting constraints are the ones that show up at smaller scale too, then become existential at large scale.
Constraint 1: Blast radius is set by your delivery topology
A deployment controller is a high-leverage failure domain. If the controller misbehaves, it can misbehave everywhere.
Operational shutdowns are the blunt instrument for containing uncertain blast radius. In November 2026, BBC reported that Lego marketplace BrickLink went offline after “unusual activity”. The article does not provide technical root cause, but the CTO lesson is stable: when confidence is low, containment wins.
GitOps often increases confidence by making desired state explicit, but it can also increase blast radius if one reconciler, one credential, or one repo change can roll across too much surface area.
A bespoke control plane is frequently justified by a single requirement: “A change must not be able to affect more than X services or Y clusters without an explicit, auditable escalation.” Many off-the-shelf setups can approximate that. Few make it easy.
Constraint 2: Organizational boundaries need to map to enforcement
Teams often treat GitOps as a repo pattern plus a controller. At scale, GitOps becomes a permission model, an environment model, and a compliance story.
Once multiple business units share clusters, CTOs need answers to questions that are hard to bolt on later:
- Who can deploy to which namespaces, with which service accounts, under which conditions?
- How is emergency access granted, time-bounded, and audited?
- What is the rollback authority, and how is it executed when the owning team is asleep?
GitHub’s workflow isolation direction (read-only defaults, scoped writes) is a signal that the industry is standardizing on “narrow writes, explicit elevation.” A deployment control plane that cannot express that cleanly becomes a governance bottleneck.
Constraint 3: Lead time stalls in the “last mile” of change
LeadDev’s lead-time argument matters because it reframes the investment decision. Faster coding only helps if the release system can absorb more change safely.
Common “last mile” blockers:
- Promotion gates that exist because environments are inconsistent.
- Release batching because rollout safety is manual.
- Slow incident detection, which forces conservative rollout speed.
A custom engine can be the right call when the standard tool cannot express your rollout primitives (multi-step canaries, region sequencing, dependency-aware rollouts, or complex freeze windows) without turning into a fragile web of scripts.
Short version: delivery tooling becomes architecture when it sets the pace and safety of change.
How should CTOs evaluate the build vs buy decision for GitOps?
A CTO does not need a custom engine because a vendor tool is imperfect. A CTO needs a custom engine when constraints are structural.
Use four questions to decide:
-
Is the deployment system now a shared critical service? If multiple orgs depend on it and outages would halt shipping, treat it like a platform product with SLOs, capacity planning, and incident drills.
-
Can you enforce isolation and scoped writes without heroics? If the answer requires tribal knowledge and manual approvals, the control plane is already the bottleneck.
-
Can you bound blast radius by design? If one repo merge can touch too much production surface area, the system is not safe enough for higher change velocity.
-
Do you have a clear differentiation requirement? “We want control” is not differentiation. “We must deploy across N clusters with deterministic ordering, policy enforcement, and auditable escalation” is.
A custom GitOps engine is a long-term commitment. Expect a permanent team, a roadmap, and an ecosystem of integrations. The payoff is control and predictability.
What to decide this quarter
-
VP Engineering (deadline: 30 days): inventory every production cluster and map which teams deploy to which clusters and namespaces. Trigger: the inventory must cover 100% of production clusters, or the GitOps discussion is premature.
-
Head of Platform (deadline: 45 days): run a “blast radius tabletop” for the deployment controller. Trigger: document the maximum number of services and clusters that could be impacted by a single bad change in the GitOps control path, including credentials and repo permissions.
-
Security Engineering Manager (deadline: 60 days): define a scoped-write model for deployments (read-only defaults, explicit escalation paths, time-bounded credentials). Trigger: produce an access matrix showing who can cause writes to production, through which mechanism, with what audit trail.
-
SRE Lead (deadline: next quarterly planning cycle): set an SLO for the delivery control plane (availability and time-to-rollback) and decide whether the current GitOps stack can meet it at projected scale. Trigger: if projected cluster or service count grows 2x in 12 months, require a capacity plan and load test.
-
CTO (deadline: end of quarter): decide “standardize or specialize.” Trigger: if the org cannot bound deployment blast radius below an agreed threshold, or cannot implement scoped writes cleanly, approve a dedicated investment decision using a structured framework like the Build vs Buy Matrix (a tool that forces weighted criteria, vendor risk, and an ADR-ready recommendation).