GitOps Principles Explained

By Kokil Thapa | Last reviewed: September 2026

GitOps Principles Explained starts with a simple idea: your running systems should match what is written in Git, and software should reconcile that gap automatically. Teams outgrow manual SSH deploys and one-off kubectl commands. They need a repeatable model where every change is reviewed, versioned, and applied without someone logging into production. That is what application GitOps versus infrastructure GitOps debates are really about — not tools, but operating discipline. This guide breaks down the four OpenGitOps principles, shows how they differ from classic CI/CD push pipelines, and maps them to stacks you may already run, from Linux server administration with Deployer to Kubernetes with Argo CD or Flux.

What Are the Four Core GitOps Principles?

The OpenGitOps project defines four principles that most practitioners treat as the canonical baseline. They are intentionally short. The hard part is living them daily.

1. Declarative: Describe the desired end state, not the steps to get there.
2. Versioned and immutable: Store that description in Git with full history.
3. Automated delivery: Approved merges trigger automated application of change.
4. Continuous reconciliation: Controllers detect drift and correct it without manual intervention.

Principle one rejects imperative runbooks. You do not document "run these twelve commands on Tuesday." You commit a manifest that says "three replicas, this image tag, this ingress host." The reconciler figures out how to reach that state.

Principle two makes Git the contract between teams. Product, security, and ops all read the same YAML, Helm values, or Kustomize overlays. Rollback is a revert, not a scramble.

Principle three removes the human from the deploy button. CI may build and test. GitOps agents pull and apply. That separation reduces "works on my laptop" surprises after merge.

Principle four is the safety net. Someone patches a pod by hand? The controller puts it back. Drift becomes visible in status fields and alerts, not a silent production mutation.

Declarative configuration in practice

A Laravel deployment manifest might look like this in a GitOps repo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: booking-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: booking-api
  template:
    metadata:
      labels:
        app: booking-api
    spec:
      containers:
        - name: php-fpm
          image: registry.example.com/booking-api:v2.4.1
          envFrom:
            - secretRef:
                name: booking-api-env

You declare three replicas and a pinned image tag. You do not script kubectl scale commands. The same mindset applies outside Kubernetes. Terraform modules, Ansible roles, and Helm charts all express desired state. The reconciler differs by platform.

How Does GitOps Differ From Traditional CI/CD Push Deployment?

Classic CI/CD often ends with a push step. GitLab CI builds assets, runs tests, then SSHes to a server or calls a cloud API. Credentials live in the pipeline. The pipeline initiates change.

GitOps inverts that flow. A cluster-side agent watches Git. It pulls approved manifests on a schedule or after webhooks. Production credentials stay inside the cluster boundary. CI never needs kube-admin access.

I have maintained Deployer 7 plus GitLab CI pipelines on shared EC2 hosts for sister legal-tech sites like Notary Kathmandu. That model is push-based but still Git-centric: tagged releases, immutable artefacts, symlink swaps. It shares GitOps DNA even without Kubernetes. The gap is continuous reconciliation. Deployer does not auto-heal a manual config edit on the server.

Neither model replaces the other overnight. Many teams run push CI/CD for PHP 8.3 Laravel 12 apps on Ubuntu and GitOps for microservices on Kubernetes. The principle overlap is version control and automation. The divergence is reconciliation depth.

Why Is Declarative Configuration Central to GitOps?

Declarative configs survive staff turnover. Imperative knowledge lives in one engineer's head or a private Slack thread. YAML in Git survives audits, onboarding, and incident reviews.

Declarative files also enable diff tools. Argo CD and Flux render a three-way merge: live state, last applied state, and desired Git state. You see exactly which field drifted. That visibility is harder when deploy scripts mutate servers in place.

For infrastructure, Terraform and OpenTofu embody the same principle at the cloud layer. Application GitOps handles Kubernetes objects. Platform teams often combine both in a layered repo layout. See multi-cluster GitOps patterns for how directory structure scales.

Environment promotion without config forks

A common pattern uses Kustomize overlays:

apps/
  booking-api/
    base/
      deployment.yaml
      service.yaml
      kustomization.yaml
    overlays/
      staging/
        kustomization.yaml
        patch-replicas.yaml
      production/
        kustomization.yaml
        patch-replicas.yaml

Base manifests stay DRY. Staging runs one replica. Production runs three. Promotion is a merge from staging overlay values to production, not a manual edit on the cluster. Validate JSON patches with a JSON formatter before you commit.

Secrets break the "everything in Git" ideal. Never commit plaintext credentials. Use Sealed Secrets, SOPS-encrypted files, or external secret operators that inject values at reconcile time. The declarative object references the secret name. The sensitive payload lives elsewhere.

How Do You Implement GitOps on a Real Project?

Implementation starts small. Pick one non-critical service. Define its manifests. Install a reconciler. Wire Git access. Turn on drift detection before you enable auto-sync.

Step 1: Structure the repository

Separate concerns across repos or mono-repo folders:

• Application repo: Laravel 13 or Symfony 8.1 source, Dockerfile, CI tests.
• GitOps repo: Kubernetes manifests, Helm values, environment overlays.
• Platform repo (optional): Cluster addons, ingress controllers, monitoring stacks.

CI builds and pushes container images. It updates the image tag in the GitOps repo via a bot commit or pull request. The reconciler deploys. That split keeps production credentials out of application CI. Read how to set up GitOps with Argo CD for a full walkthrough.

Step 2: Install and configure the reconciler

Argo CD and Flux CD are the two dominant choices in 2026. Both honour the same principles. Compare them in Flux vs Argo CD for GitOps.

A minimal Argo CD Application resource:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: booking-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/ops/booking-api.git
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

selfHeal: true enforces principle four. Manual kubectl edits get reverted. Use it carefully during break-glass incidents. Temporarily disable auto-sync, fix Git, then re-enable.

Step 3: Add observability and policy gates

GitOps without metrics is blind reconciliation. Export reconciler health, sync status, and drift counts to Prometheus. Alert when applications stay OutOfSync beyond a threshold.

Policy engines like OPA Gatekeeper or Kyverno validate manifests before apply. Block containers running as root. Require resource limits. Deny latest tags in production. Pair policy with CI pipeline review steps for defence in depth.

On booking platforms I have shipped with Laravel and Livewire, the application layer still needs queue workers, scheduled tasks, and Redis 8.10. GitOps manifests should include Horizon deployments, CronJob resources, and health probes — not just the web Deployment.

What GitOps Mistakes Do Teams Make Most Often?

Teams adopt GitOps for the label and skip the discipline. These failures show up repeatedly in production postmortems.

Treating GitOps as "Git-triggered kubectl"

Running kubectl apply from CI when a file changes is not GitOps. There is no continuous reconciliation. Drift goes undetected. You moved the deploy script into Git without changing the operating model.

Storing secrets in plaintext

A public GitOps repo leak becomes a full infrastructure breach. Encrypt at rest in Git. Restrict reconciler RBAC. Rotate tokens when staff leave. The Kubernetes secrets good practices guide remains the baseline reference.

Auto-sync in production on day one

Start with manual sync or auto-sync in staging only. Learn how your manifests behave under prune. A bad label selector with prune enabled can delete every resource in a namespace. I have seen similar damage from imperative scripts. GitOps makes it faster, which cuts both ways.

Ignoring application-level config

Kubernetes manifests alone do not configure PHP-FPM pools or Laravel .env values. Mount ConfigMaps and Secrets. Run init containers for migrations. Document which settings live in Git versus external stores. Testing and optimization should cover the full deploy path, not just pod readiness probes.

One reconciler per cluster without a strategy

Multi-cluster setups need a hub-spoke or fleet model. Duplicated Argo CD instances without shared policy drift apart quickly. Read GitOps across multiple clouds with Argo CD before you scale past two clusters.

How Do GitOps Principles Map to Broader Platform Engineering?

GitOps sits inside a wider platform toolkit. Ansible playbooks provision servers. Terraform manages cloud networks. GitOps reconcilers manage cluster objects. Each layer declares state in Git with different agents.

For enterprise application development, the win is operational consistency. A law-firm portal and an eCommerce store both benefit from auditable deploy history. Kubernetes GitOps adds self-healing. VM-based Laravel deploys gain that through immutable releases and disciplined rollback, not live reconciliation.

The CNCF Argo project ecosystem matured quickly. Flux GitOps Toolkit offers a modular controller set. Pick one stack per organisation. Running both Argo CD and Flux in the same cluster without boundaries creates confusion, not resilience.

Connect GitOps metrics to business outcomes. Faster mean time to recovery after bad deploys. Fewer manual production SSH sessions. Clear ownership when staging and production diverge. Those metrics justify the learning curve to founders who see Kubernetes as overhead.

If you are modernising legacy PHP, incremental beats rewrite. Containerise one service. Move it to GitOps. Keep the monolith on proven push deploy until the team owns the new workflow. That mirrors how I approach website migration projects — reduce risk per phase.

Documentation matters. A Laravel Livewire booking platform needs runbooks for queue failures alongside GitOps sync status. Principles do not replace on-call judgement. They give on-call a verifiable desired state to compare against.

Key Takeaways

• GitOps rests on four principles: declarative config, Git as source of truth, automated apply, and continuous reconciliation.
• Pull-based deployment keeps production credentials inside the cluster; CI pushes image tags, not kubectl commands.
• Start with manual sync and drift visibility before enabling auto-heal and prune in production.
• Never store plaintext secrets in Git; use encryption or external secret operators.
• VM and PHP-FPM stacks can adopt Git-centric discipline without full Kubernetes reconcilers.
• Pair GitOps with policy validation, Prometheus alerts, and staged environment promotion.

People Also Ask

Is GitOps only for Kubernetes?

No. The principles apply anywhere you can declare desired state and reconcile automatically. Kubernetes has mature tooling in Argo CD and Flux. Terraform-driven infrastructure and even configuration repos for Ansible follow the same logic. Kubernetes is where GitOps is most common in 2026 because controllers are built into the platform ecosystem.

What is the difference between GitOps and DevOps?

DevOps describes culture and collaboration between development and operations. GitOps is a specific operational pattern within that culture. You can practice DevOps without GitOps. GitOps gives DevOps teams a concrete implementation: Git merges drive production change with automated drift correction.

Do I still need CI if I use GitOps?

Yes. CI builds, tests, scans, and publishes artefacts. GitOps CD deploys what CI produced. A typical flow runs PHPUnit or Pest in GitLab CI, pushes a container image, opens a pull request to bump the tag in the GitOps repo, and lets Argo CD sync after merge. Removing CI leaves you with untested manifests.

Which GitOps tool should I choose in 2026?

Argo CD offers a strong UI and multi-tenant Application CRDs. Flux integrates tightly with Helm and the wider GitOps Toolkit. Both honour the same OpenGitOps principles. Standardise on one per organisation. Evaluate against your cluster count, team skill, and existing Flux versus Argo CD comparison criteria rather than feature checklists alone.

Put GitOps Principles to Work on Your Stack

GitOps Principles Explained are not abstract theory. They are an operating contract: write what you want, store it in Git, let software enforce it, and fix drift before users notice. Whether you run Laravel 12 on Ubuntu with Deployer or microservices on Kubernetes with Argo CD, the mindset transfer is immediate. Audit your current pipeline against the four principles, close the biggest gap first, and expand from there.

Need help designing a Git-centric deploy model or migrating workloads to declarative Kubernetes delivery? Review our support and maintenance services or custom software development offerings, browse the portfolio for shipped examples, and contact us to discuss your infrastructure goals.