Two roads to a private cloud. Only one of them is built for the developers.
If you are about to build a private cloud, there are in practice two roads. Either you build it from the bottom up on a hypervisor, where Azure Local is Microsoft's packaged offering. Or you build it on containers, where Kubernetes is the standard and Stackship is the layer that turns it into a cloud. The choice is less about technology than about who the platform is for — this page walks through the difference without pretending one road always wins.
What the two roads actually optimize for
Both give you a private cloud. They solve different problems on the way there.
The hypervisor road
You get infrastructure, storage, clustering, and management in one package from one vendor. Operations gets a familiar toolbelt and one support channel. Application teams get virtual machines, and whatever they build on top, they build themselves.
Optimized for the infrastructure team. A good fit when the center of gravity is operating what you already have.
The container road
You get a standard orchestrator that neither we nor anyone else owns, and a platform layer on top that gives developers a self-service catalog. Operations changes how it works. Application teams stop waiting.
Optimized for the people who build software. A good fit when new services must ship faster than infrastructure can be requisitioned.
What Stackship adds
A platform layer on top of your Kubernetes — not another infrastructure stack.
A service catalog, not a VM catalog
Postgres, object storage, cache, message queues, secrets, and functions as ready-made services. The difference from a virtualization platform is not how fast a machine boots — it is that nobody has to boot a machine.
Self-service that actually is
A team should get from idea to running environment without anyone else opening a ticket. That is the bar a cloud has to clear, and it is the bar most on-prem platforms fail.
We don't touch your infrastructure
Vanilla Kubernetes, OpenShift, Tanzu, or something else, operated by you or by a partner. We put no requirements on distribution, hardware, or who runs the cluster.
The services live in your own registry
All resource images ship with the installation and land in your registry. Running the platform and provisioning new services requires no contact with us. The only thing fetched from outside is upgrades of the platform itself.
No dependency on a cloud account
The control plane runs on your clusters. The license is a key with a validity period, not a connection. With a prepaid license term, no usage data is sent to us at all.
Your identity provider, Microsoft's included
SAML and OIDC against the IdP you already run. If you have Entra ID it works great. It just isn't required.
When Azure Local is the better choice
We don't believe the container road is right for everyone. Azure Local is likely the better choice if:
If that sounds like you, you should not buy from us. Reach out anyway — we'll tell you if we think you're making the right call.
When the container road is the better choice
The container road with Stackship on top is likely right if:
If several of these ring true, the hypervisor road is major surgery to solve a problem that sits at the top of the stack.
No Kubernetes yet?
Stackship is the platform layer. We don't deliver Kubernetes and don't take responsibility for it.
That doesn't have to be your problem. Our partners deliver Kubernetes as an operated service with Stackship on top, giving you the same whole that Azure Local offers — but with a European supply chain and without locking the stack to a hyperscaler. If you'd rather build and operate it yourself, that of course works too.
Talk to us about which road fits youFrequently Asked Questions
The choice in practice: scope, requirements, and terms.
Compliance
GDPR data residency, NIS2 controls, audit logging, policy as code, RBAC, and encryption. Built in, not bolted on, and on infrastructure that is not managed from someone else's cloud.