GitOps often starts as a simplification: put desired state in Git, let automation reconcile it, and make deployments more auditable. But at large scale, the same default toolchain that once reduced operational complexity can become the system teams have to work around.
LinkedIn recently revealed that it replaced Argo CD with a custom GitOps engine for Kubernetes deployments, as reported by InfoQ in its coverage of the move. That decision is worth studying not because every organization should follow it, but because it highlights a modernization question many engineering leaders eventually face: when does a widely adopted platform stop fitting your operational needs?
Context: Argo CD is not the problem
Argo CD has become one of the most common choices for Kubernetes GitOps. It is open source, Kubernetes-native, widely understood by platform engineers, and supported by a broad ecosystem. For many teams, it remains an excellent default.
That is why LinkedIn’s decision is interesting. Replacing Argo CD does not imply Argo CD failed as a product. Instead, it suggests LinkedIn reached a scale, operating model, or integration boundary where a general-purpose tool no longer matched its internal deployment requirements closely enough.
This is a familiar pattern in infrastructure modernization. Teams adopt a standard platform to move faster, reduce variance, and avoid bespoke engineering. Over time, the platform becomes deeply embedded in release workflows, compliance controls, incident response, and developer experience. Eventually, the organization may discover that the tool is no longer just tooling. It is part of the production delivery system.
At that point, the evaluation changes from feature comparison to operational fit.
What LinkedIn’s move signals
The InfoQ report states that LinkedIn replaced Argo CD with a custom GitOps engine used for Kubernetes deployments. Even without treating LinkedIn’s architecture as a blueprint, the move points to several pressures that commonly appear in mature platform organizations.
Scale changes the economics of defaults
Default toolchains are designed for broad applicability. That is their strength. But broad applicability also means they must support many use cases, many deployment models, and many organizational patterns.
At smaller scale, flexibility is helpful. At very large scale, flexibility can introduce cost. Every abstraction has operational consequences: reconciliation behavior, controller performance, repository layout assumptions, access control models, drift detection, rollback workflows, observability, and integration with internal systems.
A platform team managing hundreds or thousands of services may need highly specific behaviors. They may need deployment orchestration that aligns with internal release policies, multi-tenant safety boundaries, custom approval flows, or fleet-wide visibility that is difficult to achieve through configuration alone.
In that context, the question becomes less about whether the default tool can be made to work and more about whether making it work creates a growing maintenance burden.
GitOps becomes part of the control plane
GitOps is sometimes described as a deployment pattern, but at scale it behaves more like a control plane. It determines how desired state is represented, who can change it, how changes are promoted, what happens during drift, and how failures are surfaced.
That means GitOps tooling sits at the intersection of developer productivity, security, reliability, and compliance. If the system is slow, opaque, or hard to extend, those costs show up across the engineering organization.
For CTOs and platform leaders, this is the key modernization insight: deployment infrastructure is not neutral. It shapes how teams ship software. A mismatch between tooling and operating model can create hidden friction that accumulates release after release.
The build-versus-buy question is really a maintenance question
LinkedIn’s custom engine naturally raises the question: should other teams build their own GitOps platform?
Usually, no. Most organizations are better served by adopting and improving standard tools, especially when they lack the scale or platform engineering capacity to maintain a custom deployment system safely. A custom GitOps engine is not a one-time project. It requires ongoing ownership, compatibility work, incident response, documentation, security review, and developer support.
But the opposite mistake is also common: treating build-versus-buy as a permanent decision. A tool that was the right choice three years ago may still be valuable, or it may have become a constraint. Modernization requires periodic reevaluation.
A useful way to frame the decision is to ask whether the current tool is still reducing total system complexity. If teams are building layers of scripts, policy workarounds, sidecars, manual exception processes, and dashboards around the tool, the organization may already be paying for a custom platform without receiving the benefits of intentional design.
This connects to a broader point raised in another recent InfoQ discussion on technical debt as the price of learning by doing. Tooling debt is often not a sign of bad decisions. It is evidence that the organization learned more about its real requirements after operating the system in production.
Signs your GitOps platform may be outgrowing its original design
Engineering leaders do not need LinkedIn’s scale to learn from the pattern. The following signals can help teams identify when GitOps tooling is becoming a modernization candidate.
1. Operational workarounds are becoming normal
If deployment success depends on tribal knowledge, manual sequencing, or unofficial scripts, the platform is no longer providing a clean abstraction. Workarounds are sometimes acceptable, but when they become standard operating procedure, they represent technical debt.
Track how often teams bypass the intended workflow. Also track how many deployment incidents involve gaps between the official process and the real process.
2. Performance issues affect release confidence
GitOps systems must reconcile desired and actual state reliably. If reconciliation lag, controller load, repository size, or event volume creates uncertainty, developers may stop trusting the platform.
The issue is not just speed. It is predictability. A slow deployment can be planned around. An unpredictable deployment system creates operational risk.
3. Internal policy does not map cleanly to the tool
As organizations mature, deployment policy often becomes more nuanced. Teams may need different controls by environment, service criticality, data classification, or compliance boundary.
If the platform cannot express those policies clearly, teams may encode them in scattered scripts or approval processes. That fragmentation makes auditing harder and increases the cost of change.
4. Developer experience is diverging across teams
One promise of platform engineering is consistency. If each team has to learn a different set of deployment conventions, the platform is not scaling as an internal product.
GitOps modernization should consider the developer interface, not only the backend engine. A technically powerful system that developers cannot understand will still generate support load and adoption problems.
5. Upgrades feel too risky to perform regularly
This is one of the clearest maintenance signals. If the team avoids upgrading deployment tooling because the blast radius is unclear, the organization has created a critical dependency it cannot comfortably change.
That does not automatically mean replacement is required. It does mean the system needs an upgrade strategy, test coverage, migration planning, and clearer ownership.
Practical implications for engineering teams
LinkedIn’s move should encourage platform teams to evaluate their deployment systems with the same rigor they apply to customer-facing services.
Treat deployment infrastructure as a product
Define users, service-level expectations, support channels, documentation standards, and a roadmap. GitOps tooling is not just an internal utility. It is the path to production for engineering teams.
Product thinking helps teams avoid overfitting to one group’s needs while still making deliberate tradeoffs.
Measure friction before proposing replacement
Before considering a custom engine, gather evidence. Useful metrics include deployment frequency, failed deployment rate, mean time to rollback, reconciliation latency, support tickets, manual intervention frequency, and time spent maintaining workarounds.
Qualitative feedback matters too. Ask developers where they lose confidence in the deployment process. Ask SREs which failure modes are hardest to diagnose. Ask security teams where policy enforcement is inconsistent.
Prefer extension before replacement
A full replacement is the highest-risk modernization path. Many issues can be addressed through better repository structure, policy engines, improved observability, controller tuning, clearer tenancy models, or platform wrappers.
The goal is not to preserve the current tool at all costs. The goal is to avoid rebuilding core infrastructure when targeted modernization would solve the actual problem.
Make ownership explicit
If a team chooses to build or heavily customize deployment infrastructure, ownership must be long term. Who handles upgrades? Who responds to incidents? Who maintains documentation? Who validates Kubernetes compatibility? Who reviews security-sensitive changes?
Custom tooling without durable ownership becomes technical debt quickly.
Plan migration as a risk-reduction program
Replacing deployment infrastructure touches production delivery. Migration should be incremental, observable, and reversible where possible.
Start with low-risk workloads, run old and new systems in parallel when practical, define rollback criteria, and publish clear migration guides. Most importantly, treat the migration itself as a modernization project with stakeholder communication, not as a background refactor.
Where Vibgrate fits into the modernization conversation
At Vibgrate, we see this pattern across software maintenance and modernization efforts: the hardest systems to replace are often the ones that were originally adopted to simplify delivery. CI/CD platforms, deployment controllers, test frameworks, and internal developer portals can all become deeply coupled to how an organization ships.
The lesson is not that teams should avoid popular tools. It is that every platform decision should include a lifecycle plan. How will the tool be upgraded? How will fit be reassessed? What signals indicate it is time to extend, consolidate, or replace it?
Modernization is healthiest when it is continuous. Waiting until the deployment platform becomes an urgent constraint usually makes the eventual migration more expensive.
Conclusion: the best platform is the one you can evolve
LinkedIn’s replacement of Argo CD with a custom GitOps engine for Kubernetes deployments is a useful case study in platform maturity. It shows that even proven tools can reach a point where organizational scale, operational requirements, or integration needs justify a different path.
For most teams, the immediate takeaway is not to build a custom GitOps engine. It is to examine whether deployment tooling is still serving the organization or quietly accumulating debt. The future of DevOps modernization will belong to teams that treat delivery infrastructure as an evolving product: measured, maintained, and periodically redesigned when reality outgrows the default.