This year my life took a sharp turn: I quit the company I’d worked at for four years, moved to Japan – and started hunting for a new SRE/DevOps job.

Reading through job descriptions, I kept seeing the same thing again and again: Argo CD everywhere. Almost every team had it.

This wasn’t a surprise to me — I’d already used Argo CD a lot in my previous company. We had ~10 product teams, even more Kubernetes clusters, and an SRE group that owned the platform. Argo CD was “just there” when I joined, and for years I never seriously questioned that choice.

Only now did these questions really come to mind:

• Did we actually need Argo CD in that environment?
• Where did it really help – and where was it just extra complexity?
• Would I recommend it to a much smaller team?

This post is my attempt to answer those questions, mostly for myself, but also for anyone who is staring at a greenfield cluster or a messy CI/CD setup and thinking:

Should we bring in Argo CD – or is plain CI/CD enough for now?

Hank just got it

What pain does Argo CD actually solve?

A common starting point for Kubernetes deployments is a simple, push-based model:

• CI builds an image,
• the same pipeline runs helm upgrade or kubectl apply against the cluster,
• and sometimes people still do quick fixes with raw kubectl from their laptops.

On paper, everything is “in Git”: Helm charts or Kustomize overlays live in a repo, and pipelines are defined as code. In reality, once the pipeline has finished, nothing is watching the cluster anymore.

This leads to a few concrete problems:

1. It’s hard to say what should be running in the cluster right now – the last successful pipeline, or the last hotfix someone did with kubectl?
2. Git and the actual cluster state slowly drift apart, and nobody notices until an incident.
3. During an incident you can’t quickly answer: who changed production, when, and based on which commit?

You can try to solve this with process: forbid direct kubectl, enforce approvals, log everything, add scripts that re-apply manifests from Git. But all of that is extra glue you have to maintain yourself.

Argo CD changes the model from “CI pushes to the cluster and forgets” to “a controller continuously reconciles the cluster towards what’s in Git”.

• Git becomes the source of truth for your Kubernetes manifests.
• Argo CD regularly compares what’s in Git with what’s in the cluster.
• If they drift, Argo CD marks the application as OutOfSync and, depending on your settings, either just shows it or actively syncs the cluster back.

In environments with audit or compliance requirements this stops being a nice-to-have and becomes essential. When something goes wrong, it’s much easier to answer: “This change came from this commit, approved in this merge request, and was applied by this Argo CD sync.”

Under the hood Argo CD doesn’t do anything magical: it renders your Helm/Kustomize/plain YAML and talks to the Kubernetes API server, doing the same create/update/delete calls you would do with kubectl apply or helm upgrade – just as a continuously running controller instead of a one-off pipeline step.

Classic CI/CD vs GitOps with Argo CD: CI pushes directly to the cluster vs Argo CD reconciling from Git.

So Argo CD is very good at solving drift, visibility, and auditability problems in Kubernetes.

The tricky part is that you only really feel these pains at a certain scale. In smaller setups, Argo CD can easily become more overhead than help.

Signs You Don’t Need Argo CD (Yet)

Recently I built a small side project — a Telegram bot for a channel with around 3k people. I wanted to run it on a Kubernetes cluster I use for pet projects. Was Kubernetes overkill for a single bot? Of course. But I already had a small cluster I use as a playground, so it was the easiest place to put it.

Before that, I had installed Argo CD there via an operator to play with it for other apps.

So the obvious next step would be to create an Argo CD Application for the bot and sync it from a Git repo.

But very quickly it felt like pure overhead. I don’t ship new versions often. I’m the only person who touches the cluster. A simple CI/CD pipeline that builds an image and runs helm upgrade is enough for this setup. Adding Argo CD would just mean another control plane to manage, monitor and upgrade — for almost no benefit.

If your situation looks similar, you probably don’t need Argo CD yet:

• you have a single cluster and only a few services,
• releases are relatively infrequent,
• one person (or a very small team) controls all changes in the cluster,
• there are no strong audit/compliance requirements like “every change must go through Git”.

In that case, GitOps is still a nice idea, but Argo CD will mostly add complexity rather than solve real problems. You can always introduce it later, when the pain from drift and lack of visibility becomes real enough to justify the extra control plane.

If your setup is small and you don’t really feel the pain of drift or missing audit trails yet, Argo CD is more likely to slow you down than help.

Signs You Probably Do Need Argo CD

At my previous company, we had around ten product teams and an SRE group of more than ten engineers. We had enough capacity to maintain our internal platform services — including Argo CD itself — without being overwhelmed by the extra complexity.

In that setup, Argo CD started to pay off:

• developers could deploy new versions to our lab environments by themselves via the Argo CD UI,
• the same Git repo and Application definitions were used across multiple clusters and environments,
• we could see at a glance which version of each service was running where,
• and ad-hoc changes in production were discouraged, because Git was clearly the source of truth.

If you start recognizing patterns like:

• many services and more than one environment or cluster,
• several teams deploying independently and fairly often,
• production access has to be tightly controlled (no one-off kubectl in prod),
• incidents sometimes reveal “surprise” changes that nobody remembers making,
• your company cares about having a clear audit trail for production changes (whether because of regulation or just internal policy),

then you’re probably in the Argo CD zone.

It also helps a lot if there is a small platform/SRE group (or at least a couple of people) who can own Argo CD itself as a service: upgrades, RBAC, monitoring, disaster recovery.

In that kind of setup, a GitOps approach gives you a cleaner deployment process: production changes only happen after a merge to the main branch, Argo CD keeps a log of syncs, and you can ban direct kubectl access to production. When someone asks “who changed this?”, you can answer with a Git commit and an Argo CD sync event instead of digging through ad-hoc scripts and terminal history.

In that kind of environment, Argo CD (or another GitOps controller) is much more likely to give you a net positive return. It’s not only about team size — it’s about how many moving parts you have, how strict your change process needs to be, and how much you suffer from drift and lack of visibility today.

Don’t need Argo CD yet	Probably do need Argo CD
One cluster, few services	Many services, multiple clusters/environments
One small team, rare deployments	Several teams deploying independently and often
No strict audit/compliance	Need clear audit trail for production changes
CI already works and drift isn’t a big problem	Incidents reveal “surprise” changes in prod

Trade-offs and Hidden Costs

On paper, Argo CD can look like “just install one more tool and enjoy GitOps”. In reality, there are a few costs that are easy to underestimate:

Operating another control plane.

Argo CD itself needs upgrades, backups, monitoring, TLS, SSO, RBAC, and sometimes disaster recovery. Someone has to own it and treat it like any other critical service.

Migrating existing pipelines.

If your current CI/CD pipelines already handle deployments, you either need to simplify them or carefully split responsibilities between CI and Argo CD. That migration costs time, attention, and usually a few broken deployments along the way.

Training the team.

Developers need to learn how Applications, Projects, sync policies and health statuses work. SREs need to learn how to debug things like “Why is this app OutOfSync again?” and what exactly Argo CD is doing under the hood.

Debugging a new failure mode.

You add a new moving part. Sometimes deployments fail not because of Kubernetes or the app, but because of a misconfigured Argo CD Application, an out-of-date repo, an unexpected auto-sync, or a problem in the Argo CD controller itself.

Security and permissions.

You now have one more place where RBAC and access control have to be correct — both in Argo CD itself and in Kubernetes for its service accounts.

None of these are deal-breakers, but they are real costs. For a small team with a simple setup, they can easily outweigh the benefits you get from GitOps.

What About Alternatives?

Argo CD is just one implementation of the GitOps idea: keep the cluster in sync with a declared state in Git instead of trusting that your last CI pipeline run still reflects reality. You don’t have to use Argo CD to get some of the benefits.

Stick with classic CI/CD.

If you have a small setup and most of the “Signs you don’t need Argo CD yet” apply, it’s perfectly fine to keep using your existing CI/CD pipelines. You can still improve them — add approvals, better observability, maybe some simple drift checks — without going full GitOps.

Roll your own GitOps-lite.

Some teams glue together a few scripts or a small controller that periodically runs kubectl apply from Git, or templates Helm charts and applies them on a schedule. This can work, but once you start adding drift detection, a UI, multi-cluster support and RBAC, you’re basically re-implementing Argo CD (or Flux) with fewer features and more maintenance.

Use Flux instead of Argo CD.

Flux is another popular GitOps controller. It’s more “Kubernetes-native” (no big central UI, more CRDs) and can be a better fit if you prefer configuring everything as YAML and don’t need a rich web UI for developers. The trade-offs are similar: you still operate a controller, define sources and targets in Git, and think about the same failure modes.

Argo CD and Flux are the two tools I see mentioned most often in real-world setups. There are other options — Jenkins X, Fleet from Rancher, commercial GitOps platforms — but the basic trade-offs stay the same: you still run a controller, point it at Git, and deal with the same kinds of failure modes and operational costs.

How I Would Decide in a New Team

If I joined a new team tomorrow, I wouldn’t start with “let’s install Argo CD”. I’d start with a few questions:

When you run Argo CD, you also own upgrades, RBAC, TLS/SSO, training, DR, and debugging sync failures.

1. How many services and clusters do we actually run?
2. How often do we deploy?
3. Who is allowed to touch production?
4. Do we need a clear audit trail of what was deployed when and by whom?
5. Do we have enough people to own a GitOps platform?

If the answers look more like the “don’t need it yet” section, I’d focus on improving the existing CI/CD pipelines first.

If they look more like the “probably do need it” section, I’d plan a gradual GitOps adoption — starting with one or two services and a single environment, and only then scaling it out to the rest.

The tool choice (Argo CD, Flux, or something else) would come after that. The important part is being honest about the problems you actually have today, instead of installing GitOps just because it’s in everyone’s job description.

Conclusion: Start with Problems, Not Tools

Argo CD is a great piece of technology, but it’s not a badge of being a “serious” DevOps team. For some setups it’s exactly the missing piece; for others it’s just another control plane to babysit.

Don’t install Argo CD to look “modern”. Install it when your drift and audit problems are painful enough to justify another control plane.

If you start from your actual problems — drift between Git and the cluster, lack of visibility, many teams and environments, compliance and audit needs — it becomes much easier to decide whether Argo CD (or GitOps in general) is worth the extra complexity for you right now.