Delivery Generator and Targets

The Delivery Generator is the core engine that transforms your project configuration — workload bindings, Helm values, Kustomize overlays, and manifest patches — into ArgoCD Application and ApplicationSet YAML files ready for deployment. It resolves all dependencies, merges values across the hierarchy, and commits the output to the .argocd/ directory in the project's Git repository where ArgoCD picks it up.

Delivery Page Overview

The Delivery page is accessible at /projects/:slug/delivery and provides a unified workspace for managing how your project reaches its target clusters.

Delivery Architecture

The following diagram illustrates how the delivery generator processes your configuration into deployable manifests:

Cluster Targets

Cluster targets define where your generated manifests will be deployed. Each target is a combination of:

Target Resolution

The delivery generator builds its target map using tenantSlug/environment as the lookup key. Resolution follows a two-step approach:

1. Explicit binding — If a target is bound to the exact tenantSlug/environment combination, use the configured server URL and namespace.
2. Default fallback — If no explicit binding exists, the generator falls back to https://kubernetes.default.svc with namespace default.

Agent Bindings

Agent bindings connect your project to the cluster agents that will execute deployments.

Workload Matrix

The workload matrix provides a bird's-eye view of your entire delivery topology:

                │ acme/dev  │ acme/staging │ acme/prod  │ beta/dev  │
────────────────┼───────────┼──────────────┼────────────┼───────────┤
api-server      │ ✅ dev-01 │ ✅ stg-01    │ ✅ prod-01 │ ✅ dev-02 │
worker          │ ✅ dev-01 │ ✅ stg-01    │ ⚠️ —       │ ✅ dev-02 │
redis           │ ✅ dev-01 │ ✅ stg-01    │ ✅ prod-01 │ ❌ —      │

• Green checkmark: Binding and target are complete
• Warning icon: Binding exists but target is missing or incomplete
• Red X: No binding configured for this cell

Artifact Resolution

The delivery generator resolves artifact versions using a hierarchical lookup:

Values Resolution

Helm values are resolved through a layered merge hierarchy. Each layer overrides the previous:

HQ Variables use {{hq.var.KEY}} interpolation syntax (or explicit scope variants like {{hq.var.env.KEY}}):

image:
  repository: "{{hq.var.registry}}/api-server"
  tag: "{{hq.var.version}}"
resources:
  limits:
    cpu: "{{hq.var.cpuLimit}}"
    memory: "{{hq.var.memoryLimit}}"

Runtime Adapters

The delivery generator currently supports ArgoCD as the runtime adapter. All generated output is written to the .argocd/ directory in the project's Git repository.

ArgoCD Adapter

Generates Application and ApplicationSet resources for ArgoCD.

Configuration options:

• ArgoCD Project: Which ArgoCD project to assign applications to
• Sync Policy: Auto-sync, prune, self-heal toggles
• Retry Policy: Backoff and retry configuration
• Ignore Differences: Fields to ignore during sync comparison
• Include Repo Secret: Whether to generate a repo secret for Git access

Example generated Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: acme-prod-api-server
  namespace: argocd
spec:
  project: acme
  source:
    repoURL: https://gitopshq.example.com/git/r/acme-project/repo.git
    targetRevision: HEAD
    path: .argocd
  destination:
    server: https://k8s.prod.example.com
    namespace: acme-production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Delivery Output Structure

The delivery generator writes ArgoCD Application and ApplicationSet YAML files to the .argocd/ directory in the project's Git repository:

.argocd/
├── acme-production-api-gateway.yaml      # ArgoCD Application
├── acme-production-web-frontend.yaml     # ArgoCD Application
├── acme-staging-api-gateway.yaml         # ArgoCD Application
├── acme-staging-web-frontend.yaml        # ArgoCD Application
├── beta-corp-production-api-gateway.yaml # ArgoCD Application
└── beta-corp-production-web-frontend.yaml

Delivery Preview vs. Generate

Delivery Profiles

Delivery profiles are named configurations that encapsulate a set of delivery settings for different deployment strategies.

Profiles can be switched per delivery operation, allowing teams to reuse standardized configurations across projects.

Sync Controls

Each agent binding supports granular sync controls:

Warning States

The delivery generator surfaces warnings when the configuration is incomplete or ambiguous:

RBAC and Access Control

API Reference

Troubleshooting

Best Practices

1. Always preview before generating — Catch issues before they hit Git
2. Pin versions in production — Never use latest or wildcard versions for production environments
3. Complete the target matrix — Ensure every tenant/environment cell has a target before generating
4. Use profiles — Standardize delivery settings across projects with named profiles
5. Review warnings — Treat warnings as action items, not noise
6. Pair with approval policies — Gate production delivery generation behind approvals
7. Monitor sync status — After generation, verify that ArgoCD successfully syncs the new manifests