On the Path to Gitless GitOps: Introduction

What is GitOps and why use it?

At its core, GitOps is an operational framework that takes the best practices used in software development, such as version control, immutability and automation, and applies them to infrastructure management.

Organizations and teams benefit from GitOps in the following ways:

• Improved stability: Deployments can automatically self-heal from drift or failure.
• Higher reliability: The configuration lives entirely outside the cluster, enabling faster, more reproducible recovery from incidents.
• Consistency and standardisation: Deploy from a single source of truth, ensuring parity across environments.
• Stronger security guarantees: Security controls can be shifted left because changes undergo peer reviews and are handled by CI pipelines like any other code change.

To standardise these practices, the CNCF’s OpenGitOps initiative codified the four fundamental principles that govern the framework:

• Declarative: A system managed by GitOps must have its desired state expressed declaratively.
• Versioned and immutable: The desired state is stored in a way that enforces immutability and versioning, while retaining a complete version history.
• Pulled automatically: Software agents automatically pull the desired state declarations from the source.
• Continuously reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.

The industry standard doesn’t mandate a specific version control tool; instead mandating immutability and version control as operational principles. Historically, the software agents of choice have been Argo CD or Flux CD, while Git became the standard for storing these declarative definitions, hence the “Git” in GitOps. Crucially, GitOps principles don’t mandate Git; it is neither the only source of truth available, nor is it entirely fit for purpose. As the GitOps paradigm has expanded to handle massive enterprise scale and complex delivery pipelines, the industry has outgrown Git’s ability to serve as the source of truth.

More Git, more problems

While Git paved the way for modern infrastructure automation, abusing a tool designed for code collaboration to serve as a high-load production data source has revealed significant structural limitations.

The operational strain

Git was designed to track code changes, not to serve as a high-performance database for automated deployments. As organizations scale to thousands of microservices, GitOps agents must continuously poll the Git server to detect changes.

Every single query against a Git server is a computationally-intensive operation. When hundreds of automated agents continuously poll, organizations frequently hit rate limiting and throttling. This “thundering herd” effect can freeze deployment pipelines entirely.

The security perimeter

In a classic GitOps model, there is no structural disconnect between the developer and production environments; both interact with the same Git repository. If an attacker compromises a developer’s workstations or access tokens, they gain a direct, unhindered path to alter production configurations.

While cryptographic commit signing provides a layer of protection, verifying the authenticity of a Git commit during production is far from a simple task. To truly trust a deployment, a continuous delivery engine must verify the entire historical chain of commits, imposing additional computational load and introducing operational complexity into the production cluster.

Furthermore, this trust is frequently diluted because many developers rely on platform-managed keys, such as those automatically generated by GitHub. This offloads cryptographic identity verification to a third party and, in the process, obscures the true, verified provenance of the infrastructure change.

The lifecycle disconnect

To ensure that a configuration is safe to deploy, teams rely on automated tests and security scanners running in Continuous Integration (CI) pipelines. In classic GitOps, compliance with these checks is enforced at merge time using platform-specific controls.

However, once a commit is merged into the main branch, the GitOps deployment agent blindly pulls and applies it. The deployment tool itself has no native mechanism to verify that the commit it is pulling actually passed the required security gates. To fix this, teams must build brittle, custom integrations, forcing the deployment tool to double-check external third-party status APIs right before a release, adding architectural complexity and moving parts to a critical junction.

Gitless GitOps

Solving these bottlenecks requires an architectural shift towards decoupling the Git server from the actual production delivery. This is achieved by leveraging Open Container Initiative (OCI) artifacts.

Originally, the OCI specification was designed with containers in mind. However, over time, it has matured towards a universal cloud native packaging format capable of distributing virtually any payload, including raw configuration files. Supporting this trend, in Kubernetes v1.36, the ImageVolume feature gate graduated to stable, allowing pods to mount OCI images directly as storage volumes.

This makes OCI images ideal to distribute deployment manifests with the added benefits of:

• Vendor interoperability: OCI images benefit from the widespread adoption of the OCI standard.
• Superior performance at scale: OCI registries utilise optimised data caching and are backed by high-throughput cloud object storage, which can easily absorb traffic spikes and high volumes of requests.
• Hardened, consistent shift-left supply chain security: Attestations created during build time for security, provenance and governance assertions can be included within the OCI artifact. This enables automated accept-or-reject decisions, using the same systems as the application they deploy.
• Reduced network load: Production clusters no longer need network access to Git hosting services, and re-use the application’s OCI registries.

The current state of Gitless GitOps

As we have already mentioned, the most widely adopted GitOps tools by far are Argo CD and Flux CD, both of which are graduated Cloud Native Computing Foundation (CNCF) projects. Indeed, many commercial tools wrap them to provide GitOps functionality.

Argo CD has recently added full support for OCI manifests after supporting OCI Helm charts for some time. However, it does not natively support validation of cryptographic attestations for deployed OCI artifacts. To extract the maximum security benefits of OCI artifacts, it is necessary to employ external components, such as policy engines like Kyverno or the Sigstore Admission Controller.

Conversely, Flux CD features more mature support for OCI artifacts. It handles this through its native source-controller CRD, meaning it intercepts, verifies, and unpacks the OCI signature before the rest of the cluster ever sees the manifests. It also features native integrations with Cosign and Notary for cryptographic verification.

Why does it matter?

Shifting away from standard Git delivery mechanisms is not just an exercise in infrastructure optimisation; it is a baseline requirement for regulatory survival, operational continuity, and modern risk mitigation.

The EU Cyber Resilience Act (CRA) came into force in September 2026, meaning that organizations placing digital products on the European market are legally mandated to report actively exploited vulnerabilities within a strict 24-hour window. Where classic GitOps frameworks present an audit nightmare by blindly pulling files from Git, OCI artifacts change the paradigm significantly. They allow organizations to package immutable cryptographic attestations, Software Bills of Materials (SBOMs), and governance checks directly into the deployment payload, enabling automated compliance guardrails.

Git servers are inherently designed for code collaboration, meaning they’ll inevitably throttle high-frequency machine requests and scale poorly under large automation footprints. This bottleneck becomes a non-issue with OCI registries. Purpose-built for massive throughput, registries absorb traffic spikes and parallel deployments seamlessly, ensuring that production platforms remain fully operational and self-healing even during major outages.

By decoupling deployment artifacts from source code repositories, components in your software supply chain can be cryptographically validated. Platform teams can implement admission policies to ensure that only configuration artifacts carrying validated attestations from a build pipeline are permitted to run within production clusters.

Moving forward with Gitless GitOps

Transitioning from classic Git-based delivery to an artifact-centric, OCI-driven paradigm marks a major evolutionary step for cloud native infrastructure. By treating your configurations with the same rigour as your applications, you eliminate the operational constraints of collaboration tools and establish a robust, compliant, and highly scalable delivery model. As this shift touches every phase of the development lifecycle, we will be breaking down the technical roadmap step-by-step across the next three posts in this series:

• Building trusted artifacts: How to isolate and structure your upstream CI pipelines to establish a robust security boundary.
• Kubernetes manifests as artifacts: A deep-dive into the packaging mechanics, version-pinning strategies, and storage patterns of YAML configurations inside an OCI registry.
• Deploying with Gitless GitOps: Exploring the real-world configurations required within tools like Argo CD and Flux CD to pull, verify, and reconcile these immutable objects natively.
• End-to-end demonstration: We will be creating, signing, attesting and deploying OCI artifacts to provide a hands-on experience on how the mechanisms we just described work.

Take your platform to the next level

Navigating the intersection of infrastructure velocity, supply chain security, and strict regulatory deadlines, such as the EU CRA, can be a complex journey. You do not have to architect it alone.

• Interested in GitOps but don’t know where to start? We can help you design a modern, declarative automation framework tailored to your organization’s scale from day one.
• Worried about your supply chain security but unsure how to handle it? We specialise in building hardened, shift-left build pipelines, implementing SBOMs, and establishing robust cryptographic verification layers.
• Already using Argo CD or Flux CD, but ready to take it to the next level? Our team can help you transition your existing pipelines into high-throughput, network-isolated OCI engines to future-proof your delivery pipeline.

Whether you are looking to secure your deployment pipelines, achieve automated governance compliance, or scale your cloud native platforms, ControlPlane brings years of experience delivering secure, high-end solutions in highly regulated spaces to your architecture.

Get in touch with ControlPlane today to schedule a threat modelling evaluation or discuss your platform engineering roadmap.