Argo CD: When You Actually Need It

This year my life changed a lot: 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 popping up everywhere.

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.

At first glance, everything is “in Git”: Helm charts live in a repo, and pipelines are defined as code. But after the pipeline runs, it just means we pushed something once — nobody keeps checking that the cluster still matches it.

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 at some point you’re basically re-implementing a GitOps controller by hand.

This is exactly where Argo CD fits.

Instead of a one-off push from CI, you get a controller that keeps the cluster in sync with a Git repo:

• Git is the source of truth for your Kubernetes manifests.
• Argo CD regularly compares what’s in the repo with what’s running 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.

If you have strict audit or compliance requirements, this setup helps a lot. 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.

Argo CD itself isn’t doing anything magical here: it renders your Helm/Kustomize/plain YAML and talks to the Kubernetes API server, doing the same create/update/delete calls you’d 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 audit problems in Kubernetes.

The tricky thing is that you only really feel these pains once you have multiple services or teams. In a small setup with a single cluster and a few apps, Argo CD can easily be 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? I would say yes. 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 seeing 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 ready for Argo CD.

Note. It helps a lot if there is a small platform/SRE group (even 1–2 people) who own Argo CD itself: upgrades, RBAC, monitoring, backups and 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, because you have more moving parts, stricter change requirements, and you’re already suffering from drift and lack of visibility.

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

What Argo CD actually costs you

Even if you like the idea of GitOps, Argo CD is not something you install once and forget about. You pay for it with time and complexity in a few places:

• Running Argo CD itself.
  
  It needs upgrades, backups, monitoring, TLS, SSO, RBAC and a plan for disasters. Someone has to own it and treat it like any other important service.

• Changing existing pipelines.
  
  If your CI/CD pipelines already deploy to Kubernetes, you’ll need to strip that part out: CI should only build and update Git, and Argo CD should be the one doing the deploys.

• Teaching people how it works.
  
  Developers need to understand Applications, Projects, sync policies and health statuses. SREs need to learn how to debug why is this app OutOfSync again? and what Argo CD is doing when it syncs.

• New ways for things to break.
  
  You add another moving part. Sometimes a deploy fails not because of Kubernetes or the app, but because of a bad Argo CD config, an out-of-date repo, an unexpected auto-sync, or a problem in the controller.

• Extra place to get permissions right.
  
  There is one more layer of access control — in Argo CD itself and in Kubernetes for its service accounts.

For a small team with a simple setup these costs can easily be higher than the benefits you get from GitOps. For bigger, more regulated environments they are usually worth it.

What about alternatives?

Argo CD is just one way to do GitOps: keep the cluster in sync with what you have in Git instead of assuming the last CI run still reflects reality. You can get some of the same ideas without Argo CD.

• 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 fine to keep using your current CI/CD pipelines. You can still make them better — add approvals, improve visibility around deploys, maybe add a simple drift check — without going full GitOps.

• A small GitOps-ish script.
  
  Some teams run a cronjob or a small controller that periodically does kubectl apply from a Git repo, or renders Helm charts and applies them on a schedule. This can work for a while. But once you start adding drift detection, per-team permissions and a UI, you’re basically building your own GitOps tool and have to maintain it.

• Flux instead of Argo CD.
  
  Flux is another GitOps controller. It leans more on CRDs and YAML and doesn’t ship with a big central UI. It can be a better fit if your team is happy to work from Git and kubectl instead of a web interface. The idea is still the same: a controller reads from Git and applies changes to your clusters.

In practice I mostly see Argo CD and Flux. There are other options — Jenkins X, Fleet from Rancher, paid GitOps tools — but they all look similar: you run a controller, point it at Git, and you also have to operate and debug that part.

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 first ask a few basic questions:

1. How many services and clusters do we run?
2. How often do we deploy?
3. Who is allowed to touch production?
4. Do we need a clear history of who deployed what and when?
5. Do we have people who can look after a GitOps setup?

If most answers look like the don’t need it yet side, I’d just improve the CI/CD we already have.

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

If it looks more like the probably do need it side, I’d introduce GitOps slowly: start with one or two services in one environment, see how it behaves, and only then roll it out wider.

The exact tool (Argo CD, Flux or something else) can come later. The main thing is to start from the problems you actually have today, not from a tool that just happens to be popular in job descriptions.

Conclusion: start from problems, not tools

Argo CD is a good tool, but it’s not a badge that makes you a “serious” DevOps team. For some setups it really solves day-to-day pain; for others it’s just another set of components to look after.

Don’t add Argo CD to look modern. Add it when drift and audit issues hurt enough that an extra controller is worth it.

If you start from concrete problems — drift between Git and the cluster, no clear view of what’s running where, several teams and environments, compliance or audit needs — it becomes much easier to see whether Argo CD (or GitOps in general) is worth the extra complexity for you right now.