${REPO_NAME}
Kubernetes deployment source-of-truth repository for ${REPO_NAME}.
This template is intended for applications deployed with ArgoCD through an
ApplicationSet. It uses a base/ plus overlays/ layout, stores runtime
secrets as SOPS-encrypted manifests, and includes Gitea workflows for manifest
validation and dormant-transition PR creation.
Layout
.
├── .gitea/
│ ├── template
│ └── workflows/
│ ├── dormant-pr.yaml
│ └── validate.yaml
├── bootstrap/
│ ├── applicationset.yaml
│ └── config.yaml
├── manifest/
│ ├── base/
│ │ ├── kustomization.yaml
│ │ ├── runtime/
│ │ │ ├── deployment.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── service.yaml
│ │ └── state/
│ │ ├── kustomization.yaml
│ │ └── persistentvolumeclaim.yaml
│ ├── components/
│ │ └── example-component/
│ └── overlays/
│ ├── dormant/
│ │ └── kustomization.yaml
│ └── production/
│ ├── ingressroute.yaml
│ ├── kustomization.yaml
│ └── storage/
│ └── persistentvolume-nfs.yaml
├── DORMANT_IMPLEMENTATION_REPORT.md
├── OPERATIONS.md
└── scripts/
Active and dormant overlays
- Active
productionincludes runtime resources plus retained state. - Dormant includes only retained state so Argo CD removes runtime workloads but keeps app data.
- The
bootstrap/applicationset.yamloverlayfield is the control point for switching between active and dormant desired state.
First edits
Update these files before the first deployment:
manifest/base/runtime/deployment.yamlSet the container image, ports, probes, resource requests, and required environment variables.manifest/overlays/production/ingressroute.yamlSet the real hostname, entry point names, and middleware references if used.manifest/base/state/persistentvolumeclaim.yamlSet the requested size, access mode, and storage class for the environment..sops.yamlReplace the sample age recipient with the public key that ArgoCD should use for decryption.manifest/overlays/production/secret.secret.yamlRe-encrypt the placeholder secret values with your own data.
Dormant PR flow
Push a protected tag in the form dormant/<repo-name>/production.
The Gitea workflow creates a short-lived branch, changes the ApplicationSet overlay target to manifest/overlays/dormant, and opens a pull request against main. Merge approval is the dormancy gate. Reactivation is a normal PR that switches overlay back to production.
See OPERATIONS.md for storage prerequisites and required Gitea protections.