Manifest Management

For Git-source apps, source.git.manifestType selects how manifests are rendered before being applied.

Supported Types

Raw YAML/JSON

Wardn reads .yaml, .yml, and .json files from source.git.path and parses them into resources.

spec:
  source:
    type: Git
    git:
      repoURL: https://github.com/myorg/my-app
      path: manifests
      manifestType: Raw

Multi-Document Files

Documents separated by --- are all parsed:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  key: value
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3

Directory Structure

my-repo/
└── manifests/
    ├── deployment.yaml
    ├── service.yaml
    ├── configmap.yaml
    └── ingress.yaml

All .yaml, .yml, and .json files in the path are parsed and applied.

Kustomize ✅

When manifestType is Kustomize (or Auto finds a kustomization.yaml in the path), the operator renders the overlay — bases, overlays, patches, components.

spec:
  source:
    type: Git
    git:
      repoURL: https://github.com/myorg/my-app
      path: overlays/production
      manifestType: Auto        # detects kustomization.yaml
      kustomize:
        images:
          - ghcr.io/acme/api=v1.2.3     # newName=newTag overrides
        namePrefix: prod-
        components:
          - ../../components/monitoring

source.git.kustomize layers overrides on top of the tracked kustomization.yaml without editing the repo — image pins, name prefixes, extra components.

Helm — 📋 planned

The target shape:

spec:
  source:
    type: Git
    git:
      path: charts/my-app
      manifestType: Helm
      helm:
        valuesFile: values/production.yaml
        releaseName: my-app
        inlineValues: |
          replicas: 3

Variable Substitution ✅

source.git.substitution applies a Flux-style ${VAR} map to rendered manifests post-build:

spec:
  source:
    type: Git
    git:
      substitution:
        ENVIRONMENT: production
        IMAGE_TAG: v1.2.3

Keeps environment-specific values out of tracked manifests.

SOPS Encrypted Manifests — 📋 planned

Server-Side Apply

All rendered objects are applied with Kubernetes server-side apply:

• Field manager wardn-operator with forced ownership — fields Wardn rendered stay Wardn-managed; conflicts are taken over rather than failing
• Managed-by label cd.wardn.space/app: <app-name> stamped on every applied object — this is what syncPolicy.prune selects on
• Pruning — objects carrying the app's label in the destination namespace that leave the rendered set are deleted (when prune: true)

Related

• Configuration — full App CRD spec
• Helm Charts Guide — Helm deployment (planned)
• Kustomize Guide — tutorial for Kustomize overlays
• Secret Management — Vault/OpenBao, SOPS age, and ESO integration