GitOps with Argo CD or a control plane? What teams without a platform team actually need

A SaaS team, four developers, two clusters on Scaleway, no platform team. In the sprint review someone says: “Let’s do GitOps, with Argo CD.” Three weeks later there is a second repository with 140 YAML files, an open debate about Sealed Secrets versus SOPS – and no answer to who upgrades Argo CD itself. The project ships a new minor version every three months and patches only the latest three.

GitOps is an operating model in which a system’s desired state is stored declaratively and versioned in Git, and an agent in the cluster pulls and applies it continuously. The question is not whether that is good – it is – but whether it suits a team where nobody runs the platform full-time.

What is GitOps, and what does Argo CD do?

OpenGitOps sums it up in four principles:

• Declarative: the target state is described, not scripted as commands.
• Versioned and immutable: every version is kept with its complete history.
• Pulled automatically: an agent pulls the state from the source – nobody pushes it in with kubectl apply.
• Continuously reconciled: the agent compares desired and actual state and closes the gap.

Argo CD and Flux are the best-known of these agents. By default Argo CD checks the repository every 120 seconds plus up to 60 seconds of jitter. Automated sync is optional, and even with it, deleting surplus objects (prune) and reverting manual changes (selfHeal) stay off until you switch them on.

What GitOps does well

• Review by pull request: every change to the cluster is a diff someone approves.
• History: the Git log is the change log, a revert is the rollback.
• Drift correction: with self-heal, a manual change in the cluster is undone within seconds.
• Many clusters: one repository, twenty clusters, the same rules – what the model was built for.
• Rebuilds: a new cluster is filled from the repository, not from memory.

With a platform team, that is a strong package. The maths changes when the same four people also build the features.

What does GitOps cost a team without a platform team?

• Repository structure: folders per environment, Kustomize overlays or Helm values, app-of-apps – an architecture decision that is painful to change later.
• Secrets in Git: plain text is out, so Sealed Secrets, SOPS or the External Secrets Operator. Argo CD itself recommends populating secrets in the destination cluster rather than while rendering manifests.
• New images: every release becomes a second commit – CI builds the image, then writes the new tag into the configuration repository.
• Running Argo CD: upgrades every three months, RBAC, single sign-on and a highly privileged service in the cluster that needs monitoring itself.
• Learning curve: sync waves, hooks, ignoreDifferences for fields a controller sets itself – knowledge that in small teams often sits with one person.
• 2 a.m.: when a sync hangs, you need someone who understands Argo CD, Git and Kubernetes at once.

The Argo CD alternative: desired state that lives in the product

A control plane turns the model around: the desired state lives in the product’s database, not in Git, and changes through a user interface or an API. So that it does not become a black box, it needs four things GitOps gets from Git:

• An audit log instead of Git history: who changed what and when, person or token.
• A configuration check instead of drift detection: what is stored against the live cluster, field by field.
• API tokens for CI instead of a commit bot: the pipeline triggers the deploy directly.
• Versions by digest instead of a revert: an earlier version comes back in one step.

This is how Clusterward works on Scaleway. Apps come from Git – built inside the cluster without a Docker daemon, or via GitHub Actions – as a container image or as a Helm chart. Images from the cluster’s registry roll out by digest, and “Restore this version” brings back an earlier healthy version without a new build; the background is in the article Rollbacks on Kubernetes: why a tag is not a version. A pipeline deploys with an API token carrying a role, chosen applications and an expiry date; every change lands in the audit log (Security & access). The configuration check shows where the cluster differs from what is stored.

What Clusterward is not

Clusterward is not a GitOps tool. No repository supplies the state; the configuration’s JSON export documents it but restores nothing. The configuration check corrects nothing on its own – a person starts “Deploy & re-check”. And there are no canary or blue-green deployments: a rollout replaces the pods. The deploy path in detail: Deployments.

When is GitOps the better choice?

• There is a platform team that runs Argo CD or Flux as a product for the developers.
• You run many clusters across several clouds or regions.
• Infrastructure is code anyway: Terraform, pull requests, four-eyes approval for every change.
• Your change management requires per-change approval evidenced as a pull request.
• You need canary or blue-green releases with gradual traffic shifting – in the Argo ecosystem, Argo Rollouts provides that.

In these cases a control plane without Git would be the wrong compromise.

Argo CD or a control plane: a decision list

1. Who maintains the delivery tool a year from now? Without a name, every component counts double.
2. How many clusters in two years? Below five, the multi-cluster argument weighs little.
3. Must every change be approved by pull request – by rule, not by habit?
4. Where do your secrets live today, and who may read them?
5. Do you need canary releases, or is a fast rollback enough?
6. Can someone without Kubernetes knowledge get back to the previous version at night?

If you have no name for question 1, stay below five for question 2 and say “rollback is enough” for question 5, a control plane usually gets you to production faster – and keeps you there. If you answer “yes, by rule” to question 3, take GitOps seriously. Effort and cost against building it yourself: Clusterward vs. building it yourself.

Conclusion

GitOps is a good model with a price: a second repository, a secrets strategy and a tool that needs looking after. Teams with a platform team pay it gladly. Teams without one mainly need what GitOps delivers along the way – traceability, a comparison with the cluster, a fast rollback – and get that without Git as the source of truth.

Wondering whether Argo CD suits your team? Describe your setup – we’ll tell you honestly when GitOps is the better choice. Ask a question →

Sources and further reading

• OpenGitOps: the GitOps principles
• Argo CD: automated sync
• Argo CD: secret management
• Argo CD: release cadence
• Argo Rollouts: canary and blue-green