GitOps explained: concept, workflow and core principles

GitOps is an operating model where a Git repository is the single source of truth for both application and infrastructure configuration, and an automated agent continuously reconciles the running system to match what is declared in Git. Every change to production happens through a pull request, which gives you a complete audit trail, easy rollbacks, and a consistent workflow for code, configuration, and infrastructure.

Define GitOps

The term was coined by Weaveworks in 2017. The Open GitOps project, hosted by the CNCF, codifies four principles that distinguish GitOps from generic CI/CD:

1. Declarative. The desired state of the system is expressed declaratively, not as a sequence of imperative commands.
2. Versioned and immutable. That desired state is stored in a way that enforces immutability, versioning, and full history (Git is the obvious fit).
3. Pulled automatically. Approved changes to the desired state are pulled from the source automatically by a controller running in the target environment.
4. Continuously reconciled. Software agents continuously observe actual state and act to converge it on the desired state, alerting on drift.

Note the third principle: GitOps is pull-based. A controller inside the cluster watches the Git repository, instead of an external CI runner pushing changes in. This avoids handing production credentials to your CI system.

How the workflow runs

The most common controllers are Argo CD and Flux, both CNCF graduated projects. For infrastructure outside Kubernetes, tools such as Atlantis, Terraform Cloud or Crossplane bring similar patterns to cloud resources.

Practical guidance for adoption

Best practices:

• Separate application repositories (source code) from environment or config repositories (the declared desired state). Tag images by digest, not latest.
• Use one folder or branch per environment and promote via pull requests, not by editing in place.
• Run a policy engine (Kyverno, OPA Gatekeeper) inside the cluster so that even merged manifests are validated before they are admitted.
• Treat secrets carefully: never commit raw secrets. Use Sealed Secrets, SOPS with KMS, or an external secrets operator that pulls from Vault, AWS Secrets Manager or similar.
• Wire alerts on drift and sync failures, not just on application health.

For more depth on the underlying platform, see our overview of Kubernetes and the related concept of KubernetesOps (K8sOps).

How Opsio helps

Opsio designs and operates GitOps platforms on Kubernetes (EKS, AKS, GKE, on-prem) for European and Indian enterprises. We set up the repository topology, choose between Argo CD and Flux based on your team model, build policy and secrets management around it, and run it 24/7 if you want a managed service. See our DevOps services or contact us to discuss a pilot.

Frequently Asked Questions

Is GitOps the same as CI/CD?

No, but they work together. CI/CD describes how code is built and delivered. GitOps describes how the desired state of a system is declared and reconciled. A typical pipeline is: CI builds and tests the image, then commits a new image tag to the environment repository, and the GitOps controller picks up the change and applies it.

Does GitOps only work with Kubernetes?

The pattern originated with Kubernetes because Kubernetes already exposes a declarative API that converges to desired state. The same principles can be applied to cloud infrastructure with Terraform, Pulumi, or Crossplane, and to platforms like databases or networking, but tooling outside Kubernetes is less mature.

What is the difference between Argo CD and Flux?

Both are pull-based GitOps controllers for Kubernetes. Argo CD ships with a polished web UI and a strong application-centric model, which suits teams that want a visual control plane. Flux is more modular, integrates tightly with Helm and Kustomize controllers, and is often preferred by platform teams who want a composable toolkit. Both are CNCF graduated.

How does GitOps handle secrets?

Plaintext secrets must never be committed to Git. Common patterns are Sealed Secrets (encrypts secrets to a cluster-only key), SOPS with a cloud KMS, or the External Secrets Operator, which keeps secrets in Vault or a cloud secret manager and only injects them into the cluster at runtime.

Can GitOps roll back a bad deployment?

Yes. Because every change is a Git commit, rollback is a Git revert: open a PR that reverts the offending commit, merge it, and the controller reconciles the cluster back to the previous state. This is usually faster and safer than ad-hoc rollback scripts.