Adopting GitOps using engines like ArgoCD or Flux provides automated application deployments to Kubernetes. However, if your GitOps repository structure is poorly organized, managing configuration values across development, staging, and production clusters becomes complex. Structuring configurations into distinct directories allows teams to reuse Helm charts while maintaining isolated environments.

By organizing resources into apps/, infrastructure/, and environments/ directories, you build scalable GitOps flows.

1. Structuring the GitOps Repository

We define a standardized directory structure to isolate environment values cleanly:

my-gitops-repo/
├── apps/
│   └── web-service/
│       ├── Chart.yaml
│       └── values.yaml  # Default chart values
└── environments/
    ├── dev/
    │   ├── values-override.yaml  # Dev-specific configs
    │   └── kustomization.yaml
    └── prod/
        ├── values-override.yaml  # Production-specific configs
        └── kustomization.yaml

2. The Environment Kustomization Config

Inside the production environment directory, we write a kustomization.yaml file that references the base application chart and applies the production value overrides, ensuring secure deployments.

Production Multi-Environment Helm Values Architecture

When managing 20+ microservices across dev, staging, and prod GKE clusters as a Senior Freelance DevOps & Kubernetes Programmer, keep a single base chart per workload class and override only environment-specific resource limits, HPA thresholds, and ingress hostnames via layered values-{env}.yaml files. See also Freelance Docker, Kubernetes & Helm Programmer Guide.