GitOps Will Become the Default Infrastructure Management Model by 2028
Why GitOps is moving beyond Kubernetes deployments to become the standard way all infrastructure is managed — from cloud resources to databases to security policies.
Every infrastructure change will go through a Git pull request by 2028. Not just Kubernetes manifests — cloud resources, database schemas, security policies, network configs, and compliance rules. All of it, declared in Git, reconciled automatically.
This is not a hot take. It is the natural conclusion of trends that are already well underway.
GitOps Has Already Won for Kubernetes
ArgoCD and Flux have become the default way teams deploy to Kubernetes. The CNCF ecosystem has fully embraced the model: declare your desired state in Git, let a controller reconcile it continuously.
But here is what most people miss — Kubernetes was just the proving ground. The same pattern works for everything.
The Expansion Beyond Kubernetes
Cloud Infrastructure via Crossplane + ArgoCD
Crossplane lets you define AWS, GCP, and Azure resources as Kubernetes custom resources. Pair it with ArgoCD, and you get GitOps for cloud infrastructure:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Instance
metadata:
name: my-ec2-instance
spec:
forProvider:
region: us-east-1
instanceType: t3.medium
ami: ami-0abcdef1234567890Push this to Git. ArgoCD syncs it. Crossplane provisions the EC2 instance. No one logs into the AWS console. No one runs terraform apply from their laptop.
This is already happening at companies like Upbound, Deutsche Telekom, and multiple fintech startups. It is not theoretical.
Terraform GitOps with Atlantis and Spacelift
Even Terraform — the tool that predates the GitOps movement — has been pulled into the model:
- Atlantis runs
terraform planon every PR andterraform applyon merge - Spacelift adds policy enforcement, drift detection, and approval workflows on top
- env0 brings cost estimation and governance into the Git-based workflow
The pattern is the same: Git is the source of truth, automation handles execution, humans review changes through PRs.
Policy-as-Code in Git
Security and compliance teams are writing policies as code and storing them in Git:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resource-limits
spec:
validationFailureAction: Enforce
rules:
- name: check-limits
match:
any:
- resources:
kinds: ["Pod"]
validate:
message: "CPU and memory limits are required"
pattern:
spec:
containers:
- resources:
limits:
memory: "?*"
cpu: "?*"Push it to Git, ArgoCD syncs it, Kyverno enforces it. The security team reviews policies through the same PR process as application code. Audit trails come free with Git history.
Database Schema Migrations
Tools like Bytebase and Atlas are bringing GitOps to database changes:
- Developer creates a migration file and opens a PR
- CI runs the migration against a staging database
- Review and approval happen in the PR
- Merge triggers automatic migration to production
No more running DDL statements manually. No more "who changed the schema on Friday night?"
Why ClickOps Is Dying
Every time someone makes a change through a web console, three things happen:
- No audit trail — who changed what and why is lost (or buried in CloudTrail logs no one reads)
- No review process — the change goes live without a second pair of eyes
- Drift accumulates — the actual state diverges from what is documented (if anything is documented at all)
GitOps solves all three by making Git the single source of truth. Every change is a commit. Every commit has a message, an author, and a reviewer. Drift is automatically detected and corrected.
The teams that still rely on ClickOps are the ones that have not been burned badly enough yet. But as infrastructure scales, the cost of untracked changes compounds until it becomes unsustainable.
The Convergence of IaC and GitOps
Infrastructure as Code and GitOps are merging into a single discipline. Here is the evolution:
| Era | How Infrastructure Changes |
|---|---|
| 2015 | SSH into servers, run commands |
| 2018 | Write Terraform, run apply from laptop |
| 2021 | Write Terraform, run apply from CI/CD pipeline |
| 2024 | Write K8s manifests, ArgoCD syncs them |
| 2026 | Write everything as code, GitOps reconciles everything |
| 2028 | GitOps is the default — non-Git changes require justification |
The tooling is converging too. Crossplane, Pulumi Operator, and the Terraform Kubernetes Operator all bring IaC tools into the Kubernetes reconciliation loop. The distinction between "IaC tool" and "GitOps tool" is disappearing.
My Predictions for 2028
1. Console access will require justification. Cloud provider consoles will be read-only by default in most organizations. Write access will require break-glass procedures, similar to production SSH access today.
2. Drift detection will be table stakes. Every infrastructure tool will include continuous drift detection and auto-remediation. Tools without this will be considered legacy.
3. PR-based infrastructure changes will be the norm, not the exception. New engineers will find it strange that people used to make infrastructure changes without code review.
4. Multi-cloud GitOps will be solved. Crossplane, Pulumi, and similar tools will mature to the point where managing AWS, GCP, and Azure from a single Git repo is boring and routine.
5. Compliance-as-Code will be mandatory in regulated industries. Auditors will expect Git history as evidence. Manual compliance checklists will be considered insufficient.
The Counterarguments
"GitOps is too complex for small teams." This was true in 2022 when you needed to stitch together ArgoCD, Kustomize, sealed-secrets, and image updaters. In 2026, platforms like DigitalOcean's App Platform and managed ArgoCD offerings have drastically lowered the barrier. A two-person startup can set up GitOps in an afternoon.
"Not everything belongs in Git." Secrets do not belong in Git, correct. But secret references do. Tools like External Secrets Operator, Vault, and SOPS solve this cleanly. The secret value lives in a vault; Git stores the declaration that says "pull secret X from vault Y and mount it as Z."
"Break-glass scenarios need console access." Absolutely. GitOps does not mean you never touch a console. It means the console is for emergencies, not routine operations. And when you do use break-glass access, the GitOps controller detects the drift and flags it for proper remediation.
"Terraform state is too complex for GitOps." Terraform state is an implementation detail, not a counterargument. Atlantis, Spacelift, and the Terraform Operator all manage state transparently. The user interacts with Git; the tool handles the state file.
What This Means for DevOps Engineers
If you are building infrastructure today, start treating Git as the only way changes happen:
- Move all Terraform runs into CI/CD — stop running
applyfrom laptops - Set up drift detection — know when reality diverges from your Git repo
- Put policies in Git — Kyverno, OPA, or Sentinel policies should be versioned and reviewed
- Adopt Crossplane or Pulumi Operator for cloud resources if you are already running Kubernetes
- Document break-glass procedures — because when console access becomes the exception, you need a clear process for emergencies
The engineers who understand GitOps deeply — not just kubectl apply but the full reconciliation model across infrastructure, policies, and compliance — will be the most valuable platform engineers in 2028.
If you want to build these skills hands-on, KodeKloud's GitOps and ArgoCD courses are an excellent starting point. They cover the full lifecycle from basic ArgoCD setup to multi-cluster GitOps with ApplicationSets.
The Bottom Line
GitOps is not a Kubernetes-specific pattern. It is a way of managing change. Git provides the audit trail, the review process, and the source of truth. Reconciliation controllers provide the enforcement.
By 2028, "we manage infrastructure through Git" will not be a flex — it will be the baseline expectation. The question will not be "should we adopt GitOps?" but "why are you still not using it?"
The shift is already happening. The only question is whether you lead it or get dragged into it.
Stay ahead of the curve
Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.
Related Articles
ArgoCD Application Stuck OutOfSync or Progressing: Complete Fix Guide
ArgoCD app won't sync? Stuck in OutOfSync or Progressing state forever? Here's every cause and how to fix each one step by step.
ArgoCD vs Flux vs Jenkins — GitOps Comparison 2026
A deep-dive comparison of the three most popular GitOps and CI/CD tools — ArgoCD, Flux CD, and Jenkins. Learn which one fits your team, use case, and Kubernetes setup.
Build a Complete CI/CD Pipeline with GitHub Actions + ArgoCD + EKS (2026)
A full project walkthrough — from a simple app to a production-grade GitOps pipeline with automated builds, image scanning, and deployments to AWS EKS using ArgoCD.