Installing one SaaS product in 60 customer environments.

The challenge

Large enterprises wanted the product in their own accounts and networks, not as shared SaaS. Every install was a one-off, and every customer was different: Amazon EKS, Azure AKS, Google GKE, OpenShift, plain virtual machines, and sites with no internet access at all.

The constraints

• Customer-owned clusters and networks, often behind proxies that inspect TLS.
• Air-gapped sites cannot pull anything from the internet.
• The vendor needed to know which version runs at which customer.

Decisions & tradeoffs

• One configuration per customer: a customer file plus layered values for configuration, infrastructure, and versions.
• A single pipeline with three modes: add a customer from a template, update customers, and refresh a daily release-tracking table.
• Versioned Helm and deployment packages in Amazon S3, assembled into a per-site bundle.
• For virtual machines, an installer that builds Kubernetes with kubeadm and Calico on Ubuntu or RHEL; for air-gapped sites, a bundle builder that ships Kubernetes, containerd, and Calico with proxy settings.
• A readiness validator runs before every install.

The implementation

On customer AWS accounts the pipeline creates the cluster with eksctl and a scoped deployment role; on other platforms it targets the customer's existing cluster. Rook-Ceph provides storage where no cloud storage exists. A Kyverno policy injects the customer's CA bundle so the product works behind TLS-inspecting proxies. Datadog monitoring is wired in per customer.

Outcomes

Adding a customer is a pipeline run from a template instead of a project, and a daily table shows exactly which version each customer runs.

Handover & ongoing ownership

Pipeline documentation, the customer template, and the readiness checker, used by the vendor's DevOps team.