Multi-application GitOps deployment platform

Context

Several client applications, built with different technologies, need to run on the same self-hosted Kubernetes cluster, each deployed with the same rigour.

Problem and constraints

• Avoid hand-written manifests per application that drift over time.
• No manual deployment to production: every change must be reviewed and traceable.
• Databases, backups and secrets to manage without storing them in Git in plain text.

Architecture decisions and trade-offs

Seventeen architecture decisions shape the platform, including:

• One generic Helm chart fed by a profile per application: output is rendered and validated before it is committed, instead of duplicated charts.
• Argo CD reads a dedicated GitOps repository: the cluster state is what Git says, and promoting a release is a reviewed change.
• PostgreSQL run by CloudNativePG in production, with storage and backup strategy decided up front.
• One canonical host per application, and an explicit namespace, ingress and TLS strategy.

Security and delivery

• Secrets encrypted with SOPS in Git: the repository can be read without exposing any value.
• A Jenkins promotion pipeline: a new image is pinned in the profile, the output is validated, then Argo CD syncs.
• A single entry point to validate locally before any promotion.

Results and current state

• In production: the platform currently deploys several applications (including the medical NGO and the EdTech platform shown here).
• The end-user portal planned on top of the platform is not built yet.