portfolio Anshul Bisen
ask my work

ArgoCD and GitOps for a team of four: overkill or exactly right

After three months of ArgoCD managing our k3s and production clusters, the deployment confidence, audit trail, and rollback speed paid for the setup cost within the first incident.

When I first proposed ArgoCD at FinanceOps, the reaction was unanimous skepticism. We were four engineers with two Kubernetes clusters, a k3s staging environment on a mini PC and a production cluster on Hetzner. ArgoCD felt like bringing a fire truck to a candle. But after three months of running it, I believe GitOps through ArgoCD is one of the best investments a small team can make, precisely because you are small.

Where the data model or query started fighting back.

This is where the homelab stopped being a hobby and started acting like a leadership tool. It also builds on what I learned earlier in “Our Kafka consumer lag crisis and why I stopped trusting “it works on my machine” for event-driven systems.” The infrastructure and ctrlpane work gave me a cheap place to pressure-test release habits, GitOps discipline, and failure modes before I asked the team to trust those defaults at work.

The infrastructure mess that made the lesson stick.

Why Small Teams Need GitOps More, Not Less

The conventional wisdom is that GitOps is enterprise overhead. You need it when you have dozens of services, multiple teams, and complex deployment pipelines. For a small team, the argument goes, just use kubectl apply or a simple CI deploy step.

I used to agree. Then we had a production incident where a manual kubectl apply overwrote a configuration change that another engineer had deployed 20 minutes earlier. Neither of us knew the other had deployed. There was no audit trail, no diff, no record of who changed what. Debugging took two hours because we were guessing which change caused the issue. On a team of four, there is no dedicated platform engineer watching deployments. Everyone deploys, which means nobody has complete awareness of what is deployed at any given moment.

GitOps solves this by making Git the single source of truth for cluster state. Every change is a commit. Every commit has an author, a timestamp, and a diff. Rollback is a git revert. The cluster converges to whatever Git says. No more “who deployed what when” conversations.

The Setup

ArgoCD runs on our k3s staging cluster and manages both staging and production. The repository structure uses Kustomize overlays for environment-specific configuration.

k8s/
  base/
    deployment.yaml
    service.yaml
    ingress.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml   # image tag, replica count, env vars
      secrets.yaml          # sealed secrets
    production/
      kustomization.yaml
      secrets.yaml

ArgoCD watches the main branch for production and feature branches for staging. When a CI build completes, it updates the image tag in the Kustomize overlay and commits the change. ArgoCD detects the commit and syncs the cluster within 60 seconds. The entire deploy pipeline from merge to running in production takes about three minutes.

  • ArgoCD installation: 30 minutes including TLS configuration
  • Repository structure migration from raw YAML to Kustomize: 4 hours
  • CI pipeline updates to commit image tags instead of running kubectl: 2 hours
  • Sealed Secrets setup for managing secrets in Git: 1 hour
  • Total setup time: one full day for one engineer

The Payoff

The payoff came faster than expected. KubeCon EU 2025 ran the first week of April and I was following the sessions remotely while ArgoCD managed our clusters unattended. During that week, three CI builds triggered three production deployments. All three deployed without human intervention, updated correctly, and passed health checks. I reviewed the commit history the next morning and had a complete record of what changed, when, and why.

  • Deployment frequency increased from 3 per week to 8 per week because deploys no longer required human intervention
  • Mean time to rollback dropped from 15 minutes to under 2 minutes with a simple git revert
  • Deployment-related incidents dropped to zero in three months because drift between Git and cluster state is automatically corrected
  • Audit compliance improved because every deployment is a Git commit with a reviewable diff

The audit trail benefit was unexpected. During a client security review, the auditor asked how we track changes to production infrastructure. I showed them the Git log. Every deployment, every configuration change, every secret rotation was a commit with an author and a timestamp. The auditor said it was the cleanest deployment audit trail they had seen at a startup.

The Gotchas

ArgoCD is not without friction. The learning curve for the team was about two weeks. Engineers who were used to kubectl apply had to adjust to committing YAML changes and waiting for ArgoCD to sync. The initial reaction was that it was slower, which is true for a single deployment but false for the system as a whole.

  • Sealed Secrets adds complexity to secret management. Rotating a secret requires encrypting it with kubeseal and committing the sealed version.
  • ArgoCD sync waves and hooks have a learning curve. Ordering database migrations before application deployments requires explicit configuration.
  • The ArgoCD UI is useful but can become a crutch. Engineers need to understand the Git state, not just what the UI shows.
  • Resource usage is modest but not zero. ArgoCD runs three pods that consume about 500 MB of memory on the cluster.

The Verdict

The system after the boring-but-correct fix.

Operator mode means you inherit every downstream consequence. The code path is only half the story; the other half is how the decision warps planning, trust, and execution speed. I kept relearning that lesson while building infrastructure and ctrlpane.

ArgoCD is not overkill for a team of four. It is exactly right. Small teams have less margin for deployment errors, less capacity for manual operations, and less time to debug “who changed what.” GitOps eliminates an entire category of deployment problems and gives you an audit trail for free. The one-day setup cost pays for itself the first time you need to answer the question “what changed in production in the last hour.”

If you are running Kubernetes, even a single-node k3s cluster, and you are not using GitOps, you are accepting unnecessary operational risk. The setup cost is one day. The ongoing maintenance is near zero. The confidence it gives you when deploying to production on a Friday afternoon is worth the investment by itself.