ArgoCD engineering services
ArgoCD makes Git the source of truth for what runs in a cluster. Deployment stops being a pipeline permission and becomes a merged commit — reviewable, revertable and visible.
Where we use ArgoCD
ArgoCD is part of the stack on this service. Each page covers how we work, what you get and what it costs to start.
ArgoCD in practice
ArgoCD makes Git the source of truth for what runs in a cluster. Deployment becomes a merged commit rather than a pipeline permission, and anything changed manually shows as out of sync instead of persisting quietly until it causes an incident.
It also removes cluster credentials from CI. The pipeline builds an image and updates a repository; ArgoCD, running inside the cluster, pulls and reconciles. That inversion closes a meaningful piece of attack surface, and it means deployment permissions become repository permissions — something most organisations already govern properly.
What we build with ArgoCD
Cluster state driven from a repository, with drift detected and reconciled automatically.
Changes moving from staging to production as commits, with an approval step that is a pull request.
Reverting a deployment by reverting a commit, with a full history of who changed what and when.
Is ArgoCD right for you?
Ask usA good fit when
- Kubernetes estates with more than one environment
- Teams wanting deployments reviewed and audited like code
- Organisations that would rather not give CI cluster credentials
- Many applications or clusters needing a consistent process
Probably not when
- A single application in a single cluster deployed rarely
- Teams not yet comfortable with Kubernetes fundamentals
- Non-Kubernetes infrastructure, which is not what it does
What we run alongside ArgoCD
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- Helm or Kustomize
- How manifests are rendered from the repository.
- Image updater
- Bumping image tags automatically on new builds, still through a commit.
- SOPS or Sealed Secrets
- Encrypted secrets in Git, since GitOps needs everything to be in the repository.
- App of apps
- One application managing others, which is how multi-team estates stay organised.
Why ArgoCD
Let’s talkDrift is visible
Anything changed manually in the cluster shows as out of sync instead of quietly persisting until the next incident.
No cluster credentials in CI
The pipeline writes to Git, not to the cluster, which removes a large piece of attack surface.
Rollback is a revert
Recovery uses the same mechanism as deployment, so it is a path the team has already practised.
What we get called in to fix
Get a second opinionPermanent out-of-sync state
Applications never reconciled because someone patched the cluster by hand.
Secrets outside Git
Manifests referencing secrets applied manually, so a fresh cluster cannot be rebuilt from the repository.
No sync windows
Automatic syncs landing during business hours on systems that should not change then.
Repository structure sprawl
Environments and applications organised inconsistently until nobody can find the right file.
ArgoCD or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Both are solid. ArgoCD has the better interface and is easier to hand to a team; Flux is lighter and more composable.
GitOps gives audit, drift detection and easy rollback. Pipeline deployment is simpler for one small application.
Manual apply from CI means cluster credentials in the pipeline and no drift detection. It works until it does not.
Got an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
No, but on more than one environment it quickly becomes the difference between controlled and improvised deployment.
Yes. ArgoCD renders Helm charts from the repository and keeps the cluster reconciled to them.
Whoever approves the pull request. Deployment permissions become repository permissions, which most organisations already govern.
Encrypted in the repository with SOPS or Sealed Secrets, or pulled from a secret store by an operator. Never plain text, and never applied by hand.
Yes, but it will show as drift until the repository catches up — which is exactly the behaviour you want.