The OpenGitOps Standard
Because "GitOps" became a massive industry buzzword, marketers began labeling every deployment tool as "GitOps." To stop the dilution of the term, a working group within the CNCF created the OpenGitOps framework.
To legitimately claim you are using a GitOps architecture, your system must strictly adhere to these four foundational principles.
Principle 1: Declarative
The system managed by GitOps must have its desired state expressed declaratively.
You cannot write imperative scripts (like bash scripts saying "Run this command, then run this command"). You must write files that declare the end-state you want.
- Imperative (Not GitOps):
kubectl create deployment web --image=nginx - Declarative (GitOps): A YAML file that explicitly describes exactly what the deployment should look like, leaving the "how to build it" up to Kubernetes.
This heavily limits GitOps to platforms that inherently support declarative configurations, such as Kubernetes (YAML) and Terraform (HCL).
Principle 2: Versioned and Immutable
Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
You cannot just store your YAML files in an S3 bucket or Google Drive. They must be stored in a system that tracks complete history and prevents people from secretly modifying files without leaving an audit trail.
Git is the undisputed king of this principle. Every single change to a system must be a Git commit.
- If you need to view exactly what production looked like on October 14th, you check out the Git SHA from that date.
- If an audit committee asks exactly who approved the firewall change that allowed a breach, you look at the Git Pull Request approval history.
Principle 3: Pulled Automatically
Software agents automatically pull the desired state declarations from the source.
In a standard CI/CD deployment, an external tool (Jenkins/GitLab) logs into your cluster and pushes code.
In true GitOps, the external server is strictly forbidden from accessing the cluster. Instead, a local software operator (like ArgoCD or Flux) actively runs inside the environment. This internal operator watches the Git repository and pulls configurations down.
This creates a massive security boundary. Your Kubernetes cluster doesn't need to expose its API to the internet to accept deployments. It only needs outbound internet access to read from GitHub.
Principle 4: Continuously Reconciled
Software agents continuously observe actual system state and attempt to apply the desired state.
If you run terraform apply on your laptop, the infrastructure is updated. But what happens 3 hours later if someone manually changes the infrastructure in the AWS Console? Nothing happens, until the next time you manually run terraform apply.
Traditional deployments are "fire and forget."
A GitOps system is continuous. The software agent constantly runs an infinite reconciliation loop. Every few seconds, it compares Reality to Git. If reality drifts away from Git (due to human error, a malicious attack, or a hardware failure), the agent will aggressively overwrite reality to force it back into alignment with Git.
Git is the absolute dictator of reality.