Deploying Into Any On-Prem Environment — Five Environment Classes We See

Last fall, a regional bank's IT lead opened our first meeting with one sentence:

"We don't have Kubernetes. We have three VMware vSphere hosts. Container orchestration just isn't something our team has ever operated."

That's not a problem statement. That's the baseline condition for most Korean / Japanese / EU public-sector and financial IT shops. And the environment isn't behind the times — the modern DevOps tools built on the premise of k8s + GitOps + service mesh simply weren't built with this baseline in mind.

This post is the five environment classes we've seen in 17 PoCs and how we deploy into each.

Class 1 — VM only, no plan to adopt k8s

The most common environment. VMware / Hyper-V / KVM hosts running VMs, with no k8s on the 3-year roadmap.

• Customer profile: Regional banks, insurers, some public agencies (5–30 IT staff)
• Minimum requirements: 1 VM (8 vCPU / 16 GB RAM / 200 GB SSD), 1 internal IP, sudo
• Deployment path: single-VM deploy. The full CollabOps stack (DB, search, API, workers) packaged into one VM. We embed a lightweight k8s internally (entirely transparent to the user)
• Gotchas: Agree the VM backup policy up front. Acknowledge it's a single point of failure. If HA emerges as a need, document the upgrade path to Class 2
• Time to first login: about 4 hours after PoC kickoff

Class 2 — existing k8s cluster

The next most common. Rancher / OpenShift / self-managed kubeadm clusters in production. They want DevOps tooling layered on top.

• Customer profile: Large insurers and brokerages, some telcos, public-cloud-adoption agencies (100+ IT staff)
• Minimum requirements: k8s 1.27+, ingress controller, persistent storage class, internal image registry, one namespace
• Deployment path: Helm chart. Namespace-level deploy on the existing cluster. External Postgres recommended — cluster-internal stateful sets often have weak RPO
• Gotchas: collisions with the existing ingress / DNS / cert-manager. First meeting must capture current ingress class, DNS provider, cert-manager version
• Time to first login: helm install + verification = 1–2 days

Class 3 — VMware vSphere, OVA template preferred

Large datacenter operations standardized on vSphere with workflows around OVA templates.

• Customer profile: Large enterprise IT, some financial groups, defense (200+ IT staff)
• Minimum requirements: vSphere 7.0+, OVA deploy permissions, internal DNS registration, NTP reachability
• Deployment path: OVA template. Deploy in vCenter → boots in 5 min → auto-initial setup → first login. cloud-init handles IP / DNS / hostname automatically
• Gotchas: VMware Tools version compatibility. Resource pool / DRS policy alignment. Some environments have vmxnet3 driver quirks
• Time to first login: OVA receipt → first login 30 min

Class 4 — OpenShift

RedHat OpenShift adopters. Operator pattern is the norm. Generic Helm charts collide with security context constraints.

• Customer profile: Telcos, some financial firms, RHEL-standardized public agencies
• Minimum requirements: OpenShift 4.13+, operator install permission, image stream, internal registry
• Deployment path: OpenShift Operator. Install via OperatorHub or internal CatalogSource. SCC-compatible images (non-root + readonly rootfs)
• Gotchas: RHACM integration often added late. FIPS-mode-enabled environments need FIPS-validated base images (separate certification)
• Time to first login: operator install + CR apply = 2–4 hours

Class 5 — Air-gapped + VM only

The strictest environment. Zero internet. Self-sufficient on 1–3 VMs.

• Customer profile: Defense, high-classification public networks, core financial infrastructure
• Minimum requirements: 1 VM, one-way file transfer to a transit zone, internal NTP
• Deployment path: offline tarball. Tarball contains all container images + Helm charts + dependencies + verification script. Installer handles offline verification + internal registry push + deployment automatically
• Gotchas: separate CVE DB / security patch sync required (→ air-gapped CVE mirror design). License renewal is also offline — quarterly encrypted license file delivery procedure
• Time to first login: tarball receipt → first login half day to one day

Decision matrix — which path

Environment           | Default path             | Next-step option
──────────────────────┼──────────────────────────┼──────────────────
1. VM only            | Single VM (embedded k8s) | Upgrade path to Class 2
2. Existing k8s       | Helm chart               | Class 4 (OpenShift) option
3. VMware vSphere    | OVA template             | Migration to Class 2 possible
4. OpenShift          | Operator                 | Class 5 (FIPS) option
5. Air-gapped         | Offline tarball          | (strictest — no further class)

All five paths deliver the same CollabOps. Only the entry packaging differs. The customer picks one path matching their environment.

Distribution across 17 PoCs

Class 1 (VM only)        | 6
Class 2 (existing k8s)   | 4
Class 3 (vSphere)         | 3
Class 4 (OpenShift)       | 2
Class 5 (air-gapped)      | 2

Class 1 is 35%. The class global SaaS / DevOps markets assume doesn't exist. For us, the largest segment.

Core — we don't assume customer infrastructure expertise

The technical core of fitting into all five is the minimum requirements definition — covered in minimum requirements to deploy anywhere.

"We can deploy anywhere" must be a product design decision, not a sales claim.

Which of the five environments is yours?

Every on-prem CollabOps deployment lands in one of five classes — standalone VM / existing k8s / VMware vSphere / OpenShift / air-gapped. If you're an IT lead evaluating on-prem and identify your class before the meeting, the next meeting starts with a precise deployment path. Skip that step and 3–4 meetings get spent on environment discovery alone.