All Articles

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.

DevOpsBoysMar 24, 20266 min read
Share:Tweet

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:

yaml
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Instance
metadata:
  name: my-ec2-instance
spec:
  forProvider:
    region: us-east-1
    instanceType: t3.medium
    ami: ami-0abcdef1234567890

Push 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 plan on every PR and terraform apply on 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:

yaml
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:

  1. Developer creates a migration file and opens a PR
  2. CI runs the migration against a staging database
  3. Review and approval happen in the PR
  4. 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:

  1. No audit trail — who changed what and why is lost (or buried in CloudTrail logs no one reads)
  2. No review process — the change goes live without a second pair of eyes
  3. 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:

EraHow Infrastructure Changes
2015SSH into servers, run commands
2018Write Terraform, run apply from laptop
2021Write Terraform, run apply from CI/CD pipeline
2024Write K8s manifests, ArgoCD syncs them
2026Write everything as code, GitOps reconciles everything
2028GitOps 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:

  1. Move all Terraform runs into CI/CD — stop running apply from laptops
  2. Set up drift detection — know when reality diverges from your Git repo
  3. Put policies in Git — Kyverno, OPA, or Sentinel policies should be versioned and reviewed
  4. Adopt Crossplane or Pulumi Operator for cloud resources if you are already running Kubernetes
  5. 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.

Newsletter

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

Comments