Kustomize-Driven GitOps on an Offshore VPS

Helm and Kustomize solve overlapping problems but with different philosophies. Helm uses Go templates to generate Kubernetes YAML from variable inputs. Kustomize takes plain Kubernetes YAML as input and applies patches and transformations to produce environment-specific output. Both have their place. Kustomize wins when you need to make small environment-specific adjustments to upstream manifests. You take vanilla manifests from a project (or your own internal base), put them in a `base/` directory, then create `overlays/prod/` and `overlays/staging/` directories with patches that change just the image tag, the replica count, the namespace, or any specific fields. The output is plain YAML, fully kubectl-applyable, with no runtime templating. Helm wins when you need to ship reusable application packages with rich configuration. Templates with conditionals, loops, and complex parameter validation are easier with Helm. For internal applications where you control the manifests anyway, Kustomize is usually the lighter choice. For installing community software (ingress controllers, monitoring stacks, databases), Helm is typically what is available.

The high-value GitOps setup on an offshore VPS combines a self-hosted git remote (Gitea), a Kustomize-based manifest repo, and ArgoCD as the reconciliation engine. The git repo contains a `base/` directory with the application's deployment, service, and configmap manifests, plus per-environment overlays. Developers update the manifests via pull request; ArgoCD detects the merge and applies the change to the target cluster. For a small team, all of this runs on two or three offshore VPSes. Gitea on one VPS with 4 GB RAM hosts the git remote and acts as the OAuth provider for ArgoCD. ArgoCD runs on a second VPS as a k3s single-node cluster with 4 GB RAM. The downstream workload cluster (where the actual applications run) can be a third VPS or a multi-VPS k3s cluster. The pull-based GitOps model has real security benefits. The workload cluster never has credentials to reach out to git or to a CI runner. Instead, ArgoCD watches git from inside the cluster's trust boundary and pulls changes. There is no inbound deployment path - a compromised CI runner cannot push to production because there is no push channel.

Create the repository structure: `mkdir -p k8s/{base,overlays/staging,overlays/prod}`. In `base/` add a standard `deployment.yaml`, `service.yaml`, and `kustomization.yaml` listing those files: `kustomization.yaml` content is `apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - deployment.yaml - service.yaml`. Verify base renders correctly with `kubectl kustomize base/`. In `overlays/prod/kustomization.yaml`, set the namespace, the image tag, and patches for production: `apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: prod resources: - ../../base patchesStrategicMerge: - replicas.yaml images: - name: myapp newTag: v1.2.3`. Render the overlay: `kubectl kustomize overlays/prod/`. The output is the base manifests with the prod-specific patches applied. In ArgoCD, create an Application that points at the git repo URL, the path `overlays/prod`, and the target cluster and namespace. ArgoCD detects this is a Kustomize app from the `kustomization.yaml` and runs `kubectl kustomize` internally to render the manifests before applying. Every commit to the manifest repo gets reconciled to the cluster within ArgoCD's polling interval (3 minutes by default, configurable down to a few seconds). For zero-touch deployments, use Gitea webhooks to trigger ArgoCD's API and apply changes within seconds of a merge.