The fear in the room
When I tell a small engineering team that I want to set up GitOps for their deployments, the first reaction is usually fear. They picture a six-month platform-engineering project, a stack of CRDs they will not understand, and an operator on-call rota none of them volunteered for. None of that is necessary.
💡 What GitOps actually is
GitOps is the principle that your production environment is described declaratively in Git, and a controller continuously makes the real cluster match Git. That is it. The fancy tools are optional.
The minimal toolchain that scales to a 10-person team
- One Git repo for application code and one for environment manifests. The split makes review boundaries clean.
- One CI system (GitHub Actions or GitLab CI) that builds containers and writes new image tags to the environment repo via a pull request.
- One reconciler in your cluster — ArgoCD or Flux — that pulls the environment repo and applies it. Pick whichever your team already knows.
- One alerting target (Slack channel or PagerDuty) for failed reconciles. That is your production heartbeat.
A typical flow
Here is how a deploy actually happens, end to end:
# 1. Engineer merges a feature PR to main
# 2. CI builds the container image, tags it with git SHA
# 3. CI opens a PR against the env repo:
# bumping image tag from sha-abc123 → sha-def456
# 4. PR is merged (auto for staging, manual for prod)
# 5. ArgoCD reconciles within 60 seconds
# 6. New pods roll out via Kubernetes rolling update
# 7. Slack notification fires on success or failureThe trade-offs nobody warns you about
| You gain | You give up |
|---|---|
| Reproducible production | "Just SSH and fix it" muscle memory |
| Full audit trail in Git | Some deploy speed (~60s reconcile lag) |
| Easy rollback via git revert | Need to teach the team manifest hygiene |
| Self-healing on cluster restart | Mental model of "two repos" instead of one |
Things to do on day one
- Secrets: Use sealed-secrets, SOPS, or an external secrets operator. Never commit raw secrets to Git.
- Branch protection: Require PR review on the env repo. This is your last line of defence against accidental prod changes.
- Drift detection: Alert when someone runs
kubectl applydirectly against the cluster. The cluster should mirror Git, always. - Runbooks: "How to roll back" should be one git command, documented in the env repo README.
DevOps tip: Start with staging only. Get the team comfortable for two weeks before flipping production over. The muscle memory matters more than the tooling.
Conclusion
A small team can run GitOps without a platform team. The investment pays back the first time an engineer leaves and you discover that production now lives in Git, not in their head. For the security and dependency side of running production safely, see Secure Your Node.js App and The Hidden Cost of Ignoring Dependency Upgrades.
