Before deploymentgitops-readiness

GitOps Production Readiness Checklist

15 items ·11 critical ·4 warn ·0 info

How to use this checklist

This is the gate before a GitOps controller is allowed to manage production namespaces. It is deliberately about the controller”s behaviour and authority, not about the applications it deploys — those are validated by the GitOps Repository Review checklist.

A controller that fails any critical item here is a controller that should not be writing to production, regardless of how clean the repository is. The fix is platform configuration, not pipeline tuning.

Sign-off

Every critical item must pass. A failing critical item blocks the controller from being granted authority over production namespaces; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical11 items

The GitOps controller runs with at least two replicas for availability, with leader election enabled where supported. A single-replica controller is a single point of failure for every GitOps-managed workload.
```
kubectl get statefulset -n argocd -l app.kubernetes.io/name=argocd-application-controller -o jsonpath="{.items[0].status.replicas}"
```
Every Git repository the controller pulls from is reachable from the controller namespace and authenticates successfully. A broken repo is recorded as `Degraded` rather than silently skipped.
The controller's cluster role is the minimum required: it can read namespace-scoped resources, write the resources it manages, and no more. Wildcard API group grants are absent.
```
kubectl get clusterrole argocd-application-controller -o yaml | grep -E "(\*|all)" | head
```
Each application has an explicit sync strategy (`automated` with `prune` and `selfHeal`, or `manual`), and the strategy is appropriate to the blast radius. `automated + prune` on production namespaces without a guardrail is a finding.
```
kubectl get application -A -o json | jq -r '.items[] | select(.spec.syncPolicy.automated.prune==true) | "\(.metadata.namespace)/\(.metadata.name)"'
```
Self-heal is either enabled with a guardrail (Kyverno / ValidatingAdmissionPolicy that blocks out-of-band destructive changes) or disabled with the consequence understood. A controller that fights emergency fixes is itself an incident.
Drift detection runs at a defined interval, and drift findings produce an alert. A controller that reconciles silently without surfacing drift hides configuration accidents until the next deploy.
Argo CD AppProjects (or Flux Kustomization boundaries) define which source repos, destination clusters, and resource allow-lists are permitted. An unrestricted `default` project is a finding.
Sources are pinned to a specific commit, branch, or tag, not to `HEAD`. A controller that follows `HEAD` will deploy whatever the repository points at, including a force-pushed commit.
No plaintext secrets are committed to the GitOps repo. All secret values are sourced from an external system at apply time (Sealed Secrets, SOPS, External Secrets Operator, Vault Agent).
```
git ls-files | grep -E "(secret\.ya?ml|\.env$|credentials\.json|service-account\.json)" | head; gitleaks detect --source . --no-banner
```
A production rollback has been rehearsed on a non-production cluster of the same shape: revert the Git commit, force a reconcile, observe the cluster return to the previous state. The rehearsal is dated within the last 90 days.
A documented break-glass path exists for in-cluster emergency changes that bypass the controller, with the steps for reconciling the emergency change back into Git afterwards (so the controller does not fight the fix).

Warning4 items

The GitOps controller (Argo CD, Flux) is on a supported version and within one minor of the latest release. The version is recorded in the production inventory and is not "whatever the helm chart installed".
```
kubectl get statefulset -n argocd -l app.kubernetes.io/name=argocd-application-controller -o jsonpath="{.items[0].spec.template.spec.containers[0].image}"
```
The controller emits notifications (Slack, webhook, alertmanager) on `Degraded`, `SyncFailed`, and `HealthDegraded` states, and the alerts route to a real recipient, not into a void.
The controller exposes Prometheus metrics, a scrape is configured, and the key signals (reconciliation duration, sync status, app health) are graphed on a dashboard.
The controller does not race with a mutating webhook over the same resources. Webhooks and the controller operate in a defined order, and the manifest applied by the controller is the manifest the webhook sees.