GitOps, Reimagined: A Declarative, Configuration-as-Data Approach

GitOps promised a better way to run infrastructure. Put everything in Git. Use pull requests instead of tickets. Let automation handle deployments. In theory, it’s clean, auditable, and safe.

In practice, many GitOps implementations end up recreating the same operational bottlenecks they were meant to eliminate, just with YAML and CI pipelines instead of runbooks and change tickets.

If GitOps feels complicated, fragile, or overly procedural in your organisation, that’s not because GitOps “failed.” It’s because most teams stopped halfway through the idea.

In this article, I’ll walk through a GitOps model that’s a bit different from what you usually see. It leans hard on declarative configuration, treats intent as data in Git, and lets reconciliation, not pipelines, decide what actually runs in production. Configuration as Data (CAD) and Config Sync set the stage for a simpler and more predictable way to run platforms.

GitOps, at Its Core

At its heart, GitOps is still operations done the developer way.

Instead of filing tickets or manually touching systems, engineers make changes in Git repositories. Those changes go through pull requests, automated validation, and controlled promotion across environments. Git is the source of truth, and automation ensures reality matches what’s declared.

The familiar pillars still apply:

• Infrastructure as Code (IaC)
  Infrastructure and platform configuration are defined declaratively and stored in Git.
• Pull Requests as the Interface for Change
  Every change goes through review, testing, and approval.
• Automation and Reconciliation
  Systems continuously converge toward the desired state defined in Git.
• Idempotency
  Applying the same configuration repeatedly always yields the same result.

So what changes in a modern GitOps model isn’t what GitOps is, it’s how we apply it.

The Problem with “Traditional” GitOps at Scale

Many GitOps implementations quietly drift back toward imperative thinking:

• Pipelines decide what to deploy and where
• Promotion logic is encoded in CI scripts instead of configuration
• Environment differences are scattered across overlays and branches
• Operators and platform components are promoted implicitly, not explicitly

This works… until it doesn’t.

At scale, teams want:

• Clear, auditable intent
• Minimal pipeline logic
• Strong separation between configuration and execution
• A single, declarative view of “what should be running, where, and why”

That’s where Configuration-as-Data comes in.

Configuration-as-Data (CAD)

Configuration-as-Data treats configuration not as templated text, but as structured, versioned data that describes intent.

Instead of asking pipelines to “deploy version X to environment Y,” we declare:

Environment Y should run version X of this component.

Everything else is reconciliation.

Key ideas behind CAD:

• Configuration is authoritative data, not a side effect of pipelines
• Environments consume configuration by reference, not by copy
• Promotion is an explicit data change, not an implicit pipeline step
• Systems continuously reconcile desired state from Git

This approach dramatically simplifies GitOps workflows, and that’s where Config Sync shines.

Introducing Config Sync

Config Sync is a GitOps reconciler that continuously applies configuration from Git to Kubernetes clusters. Rather than relying on CI/CD pipelines to push changes, clusters pull their desired state directly from Git.

Key properties of Config Sync:

• Git is the single source of truth
• Clusters continuously reconcile against declared configuration
• Changes are applied declaratively, not imperatively
• Drift is detected and corrected automatically

Most importantly, Config Sync enables a clean separation between:

• What is declared (configuration-as-data)
• How it is enforced (continuous reconciliation)

A Modern GitOps Workflow with CAD and Config Sync

Let’s walk through a concrete example of how this works in practice. Below is the process of how our developers at Mesoform go from nothing to deploying a Kubernetes operator.

Understanding Kubernetes Operators

First off, what is an operator? At its core, a Kubernetes Operator is a method of packaging and managing applications by extending the Kubernetes API. Think of it as a digital Site Reliability Engineer — it codifies human operational knowledge to automate complex, stateful tasks like backups and upgrades. This allows us to manage sophisticated software with the same consistency and automation as a simple container, ensuring our infrastructure remains self-healing and scalable.

Our Promotion-Based Release Strategy

To deploy these safely, we follow a “build once, promote many” pipeline that ensures environmental parity. Every image starts with a Git commit tag, progressing through Sandbox, Integration, and UAT registries as it passes automated validation. This GitOps-aligned workflow means we never rebuild code between stages; instead, we promote the exact same binary that was already tested.

For the final move to production, we re-tag the proven commit with a formal version number (e.g., v0.2.1-stable) before pushing to our Live environment. This rigorous process,  managed via RootSync for automated deployments, ensures that the version running in production is identical to the one verified by our developers, providing a reliable and auditable path to every release.

1. Configuration as the Product

Instead of embedding environment logic in pipelines, we define it in Git:

• A platform configuration repository describes clusters, environments, and policies
• An operators repository builds and publishes operator images
• Environment configuration explicitly references operator versions by tag

For example:

This is not a deployment instruction — it’s a declaration of intent.

2. Development and Sandbox Experimentation

An engineer creates a feature branch and makes a change:

• Updating an operator version
• Modifying network policy
• Adjusting cluster-level configuration

A pull request triggers validation:

• Schema checks
• Policy validation
• Optional sandbox cluster reconciliation

Config Sync applies the change to a sandbox cluster automatically, giving fast feedback without risk.

3. Pull Requests as Promotion Gates

Promotion between environments is handled by changing data, not pipelines.

• Merging into develop updates integration clusters
• A PR into main promotes configuration to UAT
• Tags like vN.N.N and vN.N.N-stable represent explicit approval states

Each promotion is:

• A small, reviewable diff
• Fully auditable
• Easy to roll back

No hidden logic. No magic.

4. Continuous Reconciliation

Once merged, Config Sync ensures clusters continuously match Git:

• If a cluster drifts, it is corrected
• If a change is reverted in Git, the cluster follows
• If a new cluster is added, it converges automatically

Operations becomes a matter of maintaining the correct configuration, not executing deployments.

Operators, Revisited

Operators still follow a familiar lifecycle: build, test, release, but with clearer boundaries.

• Operator repositories produce immutable images
• Platform configuration decides where and when those images run
• No operator is promoted unless the configuration explicitly references it

This guarantees that production runs only what was intentionally approved, and nothing else.

Why This Approach Works Better

This modern GitOps model delivers tangible benefits:

For Engineers

• Less pipeline complexity
• Faster, safer experimentation
• Clear ownership and intent
• Easier rollbacks and debugging

For Platform Teams

• Strong separation of concerns
• Declarative, auditable promotion
• Minimal imperative logic
• Easier multi-cluster management

For Leadership and Governance

• Clear approval boundaries
• Complete audit trails
• Predictable, repeatable change management
• Reduced operational risk

GitOps becomes less about “how we deploy” and more about how we declare intent.

Conclusion

GitOps isn’t just about using Git. It’s about trusting declarative systems to do the right thing.

By embracing Configuration-as-Data and tools like Config Sync, teams can move beyond pipeline-heavy GitOps and toward a cleaner, more scalable model:

Declare intent → Review changes → Merge → Reconcile continuously

No tickets. No guesswork. No surprises.

The real shift isn’t new tooling, it’s a mindset change:
Make configuration the product, Git the contract, and reconciliation the engine that keeps everything honest.