GitOps made simple: Deploying apps with Argo CD and OCI registries

GitOps has a rhythm to it: a clean commit, an automated reconcile, and a deployed app that behaves like a well-tuned instrument. Argo CD has been a go-to conductor for that flow — and recent Argo CD releases added a new instrument to the ensemble: native OCI (Open Container Initiative) registry support for storing deployment artifacts (not just container images). That change makes it easier to treat registries as a single, auditable artifact store for charts and manifests while keeping Git as the source of truth for code and intent. (infoq.com)

This article explains why OCI registries matter for GitOps with Argo CD, how the integration looks in practice, and the trade-offs to watch for.

Why OCI registries for GitOps?

• Single artifact platform: OCI registries (Harbor, GHCR, ACR, Artifact Registry, etc.) already host images. Putting Helm charts or packaged manifests there lets teams reuse existing storage, security, and retention policies instead of adding another repo type. (infoq.com)
• Immutable references and provenance: Using digests (sha256) or signed artifacts improves reproducibility — the same digest always means the same chart contents, which tightens the deployment supply chain. Helm and registry tooling increasingly support signing and immutable pulls. (atmosly.com)
• Air-gapped and regulated environments: Registries can be mirrored inside restricted networks; OCI artifacts are easier to manage in disconnected clusters than relying on external Git hosting in some cases. (infoq.com)

How Argo CD consumes OCI artifacts Argo CD v3.x introduced the ability to use OCI registries as a source for configuration artifacts — most commonly Helm charts packaged and pushed to an OCI registry. Practically, this looks like an Application spec where repoURL points to an oci:// URL and chart + targetRevision pick the artifact. (infoq.com)

Example (Helm chart from an OCI registry)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-oci-helm-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.example.com/helm-charts
    chart: my-application
    targetRevision: 1.2.3
    helm:
      values: |
        replicaCount: 3
        image:
          repository: registry.example.com/my-app
          tag: v1.2.3
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

This pattern is now supported in Argo CD and in various community docs and examples; the key is the oci:// scheme in repoURL and a chart + version reference. (oneuptime.com)

What this buys you (practical benefits)

• Reduced toolchain friction: If your CI already pushes charts and images to the same registry, you avoid duplicating artifacts into Git-only repos solely for Argo CD consumption. That can simplify pipelines and artifact signing workflows. (infoq.com)
• Stronger immutability guarantees: Deploying by digest or pinned chart version reduces surprises from mutable tags. Combined with artifact signing, it improves auditability. (atmosly.com)
• Better fits existing devops policies: Organizations that already scan or sign artifacts in registries can extend those controls to deployment artifacts without adding separate supply-chain steps. (infoq.com)

Important caveats and current limitations OCI support is a useful step, but it’s not a universal replacement for Git, and there are some caveats to consider.

• Not yet feature-identical to Git sources: Some workflows still rely on mixing sources — for example, Helm value files are commonly stored in Git. There’s an active community discussion about treating OCI artifacts as first-class value-file sources, which indicates that certain multi-source patterns are still being refined. In short: OCI charts are supported, but workflows that assumed arbitrary file lookups from Git may need adaptation. (github.com)

• Private registry authentication and edge cases: Accessing private OCI registries demands correct credentials for the argocd repo server (and possibly other Argo CD components). Historically, users have reported TLS/auth issues in specific environments (and different Kubernetes distributions may handle registry certificates differently). Operationally this requires attention when you configure registry credentials and network mirrors. (docs.redhat.com)

• Not always a reduction in complexity: For small teams or simple apps, adding a registry-backed artifact workflow can add steps (package chart → push → publish) compared with storing Kustomize overlays or raw manifests in Git. OCI shines when you already use registries heavily or when immutability and signing are priorities. (atmosly.com)

Argo CD’s broader 3.x improvements (context) Argo CD’s v3 series has focused on performance, security, and UX improvements that make GitOps at scale smoother — improvements like better UI actions, ApplicationSet scaling and profiling, CLI/UX updates, and lifecycle hooks. These releases help teams operate large fleets of apps with clearer visibility while introducing the OCI integration into a more mature platform. (cncf.io)

A practical mental model Think of Git as the engineering notebook — it records the thinking, branches, and human intent. An OCI registry acts like the label-stamped vault where the finished albums (charts and signed artifacts) are stored and distributed. Argo CD sits at the playback console: it reads either the notebook or the vault, checks the metadata, and applies whatever’s declared — ideally with clear versioning and provenance. The two sources serve related but slightly different governance needs; using both together often yields the best balance of traceability and operational control. (infoq.com)

When OCI makes sense in your GitOps flows

• If your CI already packages charts and pushes them to a registry (and you want to avoid duplicate storage).
• If immutability, signing, and artifact provenance are security or compliance requirements.
• If your clusters are in restricted networks where mirroring registry content is easier than enabling external Git access. (atmosly.com)

When to prefer plain Git (or keep Git-centric artifacts)

• If your team relies on quick, human edits to raw manifests or Kustomize overlays in Git.
• If your value files, overlays, or environment-specific templating live in Git in a way that’s hard to move.
• If you want to keep a single, auditable commit that contains both template and environment values for a given change.

Closing notes Argo CD’s native OCI support is a meaningful addition to the GitOps toolkit: it brings registries into the conversation beyond image hosting and opens practical paths for immutable, signed deployments. At the same time, it’s an incremental change — useful in many scenarios but not an automatic replacement for Git-centric workflows. The healthiest approach treats OCI artifacts and Git as complementary tools in the deployment supply chain, using each where it naturally best fits. (infoq.com)

References

• Argo CD v3.1 and OCI support coverage: InfoQ. (infoq.com)
• CNCF announcement of Argo CD v3 (scalability/security background). (cncf.io)
• “What’s new in Argo CD 3.3?” — Octopus overview of v3.3 improvements. (octopus.com)
• Practical Argo CD OCI example and guidance. (oneuptime.com)
• Community discussion on missing OCI value-file support in Argo CD. (github.com)
• Notes on Helm/OCI and registry TLS/auth edge cases in platform docs. (docs.redhat.com)