Where Managed Kubernetes fits

Teams running Kubernetes in Switzerland choose between four layers of the market. Each makes a different trade-off between control, operational burden, and cost. This page maps those layers so you can see where VSHN Managed Kubernetes sits, and why we built it for the gap in the middle.

The four layers

Register interest

Do-it-yourself Kubernetes

Self-managed Kubernetes gives you total control: you pick every component, set your own upgrade cadence, and run on any infrastructure. That control is also the cost. Running Kubernetes in production means owning the node lifecycle, version upgrades every few months, CNI and ingress decisions, storage operations, security patching, and the on-call rotation behind all of it.

Consider DIY when: you have a mature platform engineering team that treats Kubernetes operations as a core competency, and you need control over every layer.

CSP managed control planes

Managed Kubernetes engines from a cloud service provider or managed service provider (Exoscale SKS, STACKIT, IONOS, OVHcloud and similar) operate the API server and etcd for you. This is genuinely useful, but the name oversells it. Node lifecycle, version upgrades of your workloads' dependencies, ingress, storage, observability, and add-on compatibility remain your job. A managed control plane is not a managed platform.

Consider a CSP control plane when: you want someone else to run the control plane but your team is ready and willing to operate everything above it.

VSHN Managed Kubernetes (the missing middle)

This service takes ownership of the whole platform lifecycle on one opinionated, standardized stack: Talos as the immutable OS, Cilium for networking, the Gateway API for ingress, Rook / Ceph for storage, all driven by Cluster API. VSHN runs version upgrades, OS updates, and the core components on a defined maintenance schedule. You get Kubernetes as a first-class interface with the operational weight lifted, without paying for enterprise scope you do not need.

It is deliberately bounded: standardized configurations, business-hours operations, and a clear responsibility line. That is what keeps it simpler and lower cost than an enterprise platform.

Consider VSHN Managed Kubernetes when: you want production Kubernetes operated for you, you value Swiss sovereignty, and an enterprise platform like OpenShift is more than your workloads require.

Enterprise OpenShift

Managed OpenShift is the enterprise option: continuous operations, higher service levels, integrated developer tooling, and the compliance posture regulated industries need. It is the right tool when your workloads demand around-the-clock operations and regulated-grade guarantees, and more than you need when they do not.

Consider OpenShift when: you operate regulated or business-critical workloads that justify continuous operations and a broader enterprise feature set. See Managed OpenShift.

Already running OpenShift?

Everything above assumes a decision you have not made yet. If you already run OpenShift, your question is different: you hold the subscriptions, you pay for them annually, and you may be using very little of what they buy. Teams in this position tend to describe it the same way. Routes are useful, buildconfigs get used, and beyond that the enterprise platform sits there being paid for.

There are two honest answers, and they lead to different places.

Keep OpenShift and change who operates it

If the platform is fine and the operations are the problem, moving to a different platform solves the wrong thing. Nothing about your clusters, your subscriptions or your Red Hat relationship has to change for someone else to run them. This is available today, and for most teams in this position it is the shorter path. See Managed OpenShift.

Move to Kubernetes

If you genuinely use little of the platform, leaving is worth costing out. Be clear with yourself about what that means: it is a replatforming project, not a migration. Your manifests do not move across unchanged, because the things you rely on are OpenShift's rather than Kubernetes'.

What has to be replaced:

• Routes become Gateway API or Ingress resources, with the TLS and hostname handling rebuilt around them
• BuildConfigs and ImageStreams have no equivalent. Builds move to your CI system, which is usually the largest single piece of the work
• Security Context Constraints become Pod Security Standards, and the two do not map one to one, so workload permissions get re-derived rather than converted
• The integrated registry becomes an external one you choose and operate, or that we operate
• Operators from the OpenShift catalog need upstream equivalents, and where none exists the capability is rebuilt or dropped
• The web console and developer tooling go away, which matters more to your developers than to your platform team

None of that is exotic and all of it is work. The license saving has to clear it, and it does not always.

Before you decide either

Two levers reduce an OpenShift bill without changing platform or provider, and they are worth exhausting first because they are reversible and take weeks rather than quarters: right-sizing against what the clusters actually consume rather than what they were provisioned for, and scaling non-production clusters to zero outside business hours. Teams frequently find the second one alone changes the arithmetic enough that the migration question stops being urgent.

Work that out before comparing platforms. A migration justified against an unoptimized bill is being justified against a number you could have changed anyway.

Managed Kubernetes is still in development, so we are not migrating anyone off OpenShift today. If you are working through this decision now, get a second opinion on the migration. Tell us what you run and what it costs, and you get our read on whether leaving is worth it, including when the answer is to stay.

Which layer is right for you?

If you want the cluster genuinely run for you but an enterprise platform is overkill, Managed Kubernetes is the layer built for that gap. Register your interest and tell us about your clusters. We will discuss whether the platform fits your team.