Rendered Manifest Pattern

The rendered manifest pattern is the recommended Nyl deployment model. Nyl compiles trusted source configuration into ordinary Kubernetes YAML in a deployment Git revision. Argo CD reads plain recursive directories and does not run Nyl in the reconciliation path.

How the model fits together

Kubernetes-shaped configuration resources describe the deployment:

1. A GitRepository names credential-free read and write coordinates.
2. A Cluster records one concrete destination and the Kubernetes capabilities used for offline rendering.
3. A DeploymentTarget binds that Cluster to deployment values and a publication repository, revision, and path prefix.
4. An optional ArgoCDInstance separates the Argo CD control plane from workload destinations and owns parent-catalog defaults.
5. An ApplicationGroup declares source releases and generated Application and Namespace policy. It owns an implied least-privilege AppProject unless it shapes one with projectTemplate or shares one through an AppProjectDefinition.

These resources are compiler inputs. They are not installed in Kubernetes. nyl render-tree produces workload manifests, managed Namespaces, Argo CD AppProjects and Applications, and an ownership index. nyl publish-tree can commit that tree to the target revision.

Quick start

Initialize a Git repository with one cluster, deployment target, AppProject, and ApplicationGroup:

mkdir platform && cd platform
git init
git remote add origin https://git.example.com/platform/deploy.git
nyl init --cluster-name production --context admin@production

The wizard detects the Git remote and current kube context, writes a compact gitops.yaml, creates a minimal nyl.toml when needed, and creates the applications/ source directory. See nyl init for fully non-interactive flags and stdout mode.

Then list the targets, and validate and render one:

$ nyl get targets
NAME        CLUSTER  PUBLICATION      PATH-PREFIX  FILE
production  primary  platform@deploy  production   config/targets/production.yaml#document-1
staging     staging  platform@deploy  staging      config/targets/staging.yaml#document-1

nyl validate
nyl render-tree --target production --output-dir deploy-worktree

Seed the generated <target>-catalog Application once after the first publish. It then recursively manages the generated catalog, including itself. Generated Applications use ordinary Git directory sources with recursive discovery.

Guides

• Project structure and discovery explains the conventional layout, colocated groups, and remote sources.
• Targets and cluster variation covers multiple environments, clusters, publication models, values, and conditional rendering.
• Release inputs declares the values a Release takes and binds them per target.
• Rendered layout describes the generated tree, its catalog, and the ownership index.
• Git storage lists the repositories, branches, and path prefixes Nyl reads and publishes to, and when to use separate publication repositories.
• The workflow pages follow a CI pipeline in order: render and validate, diff in pull requests, publish from the protected branch, and move a publication.
• Trust and admission boundaries identifies what Nyl validates and what the Git forge, Argo CD, and Kubernetes must enforce.
• Kubernetes GitOps resource reference documents every configuration field by resource kind.

For direct cluster operations and debugging, see CLI-first workflows.