Summary

Add support for an OCI-based ApplicationSet generator, similar to the existing git generator, but using OCI artifacts as the source instead of Git repositories. This would allow ApplicationSets to generate Applications from directories or files stored in an OCI artifact.

Motivation

OCI artifacts are increasingly used to distribute Kubernetes configuration and manifests, including hydrated or rendered manifests ready for deployment.

Today, the only way to do this with ApplicationSets is via the Plugin Generator. While workable, this requires reimplementing things that Argo CD already does well (OCI auth, caching, fetching, etc.) with no benefit for the community.

Having first-class OCI support in ApplicationSets, on the same level as Git, would make this a lot simpler and more consistent.

Proposal

Introduce a new oci generator for ApplicationSets with an API closely matching the Git generator.

Example OCI artifact layout, with each subdirectory represents a rendered or hydrated application, all versioned and promoted together.

.
└── platform
    ├── cert-manager
    │   └── manifest.yaml
    └── kyverno
        └── manifest.yaml

Pushed as a single OCI artifact:

oras push ghcr.io/my-org/platform:v1.2.3 .

Can be consumed by an ApplicationSet:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: oci-generator
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
generators:
- oci:
    repoURL: oci://ghcr.io/my-org/platform
    revision: v1.2.3
    directories:
      - path: platform/*
  template:
    metadata:
      name: '{{.path.basename}}'
    spec:
      project: "default"
      source:
        repoURL: oci://ghcr.io/my-org/platform
        targetRevision: v1.2.3
        path: '{{.path.path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{.path.basename}}'
      syncPolicy:
        syncOptions:
        - CreateNamespace=true

This enables a single OCI artifact to act as a versioned, immutable bundle of hydrated manifests, while still allowing Argo CD to manage each component as an individual Application.

I’m happy to work on the implementation and would appreciate feedback on the approach and scope before starting.