The hyperscaler default is a good default. For most teams, most workloads and most stages of a company, AWS, Azure or GCP is the right answer, and this post will not pretend otherwise. But “default” and “always” are different words. In 2026 there is a specific, describable set of situations where a private cloud on OpenStack is the sober engineering choice rather than the contrarian one — and an equally specific set of obligations you take on the day you choose it.
The decision matrix, honestly
Private cloud wins when several of these are true at once; one alone is rarely enough.
- Data sovereignty — a regulator, a public-sector customer or your own legal team requires data to stay in-jurisdiction under an operator not subject to foreign legal reach. For many European organisations this has moved from a compliance footnote to a board question, and a hyperscaler region inside your borders does not fully answer it.
- Predictable heavy workloads — steady-state, high-utilisation compute: batch processing, media pipelines, sustained inference. Hyperscaler pricing is elasticity you pay for continuously; if your load curve is flat, you are renting a fire engine by the minute to water your garden every day.
- Cost control at scale — owned capacity has a different cost structure from metered capacity, and past a certain sustained footprint that difference compounds. Where that line sits depends entirely on your workloads and your ops maturity — anyone quoting you a universal figure is selling something.
- Regulatory comfort — auditors who can walk to the rack, and an infrastructure story you can explain end to end without a shared-responsibility diagram.
The hyperscaler keeps winning everywhere else: spiky or unpredictable load, small teams, global presence, and above all the breadth of managed services — if your architecture leans on a dozen proprietary managed products, OpenStack is not a lift, it is a rebuild.
What running OpenStack seriously requires
Here is the part the sovereignty pitch usually skips. OpenStack is not a product you install; it is an operational commitment you staff. Running it seriously means a real platform team — people who operate networking, storage and compute at the layer below your applications, and who carry a pager for that layer. It means upgrade discipline across a release cadence that does not wait for you, capacity planning with hardware procurement lead times measured in months, and monitoring that treats the platform itself as a production system, because it is one.
An undersized OpenStack operation is the worst of both worlds: hyperscaler-grade complexity with none of the hyperscaler’s operational muscle behind it. If you cannot staff the platform team, the honest options are two — stay on the hyperscaler, or buy the platform from someone who runs it as their day job.
Where we stand in this
Our group runs a full OpenStack cloud implementation as a PaaS — built and operated end to end, alongside the product systems we run on top of it. We say that as a statement of scope, not a case study with numbers: it means the opinions above are operational, not theoretical. We know what the upgrade cycle demands, what capacity planning feels like when the hardware is yours, and which parts of the stack reward boring choices. That experience cuts both ways — it is also why we will tell a client whose workloads belong on a hyperscaler to stay there.
Portability is leverage even if you never move
There is a quieter reason to keep private cloud on the table: your next hyperscaler negotiation. A credible, demonstrated ability to run elsewhere changes the conversation about committed-spend discounts and renewal terms in a way no amount of posturing does. The engineering that creates that credibility is worth doing anyway — workloads on Kubernetes rather than proprietary orchestration, open interfaces at the storage and queue layers, infrastructure as code that does not assume one vendor’s control plane. Portability is like insurance: its value does not depend on filing a claim. The companies with the best hyperscaler contracts tend to be the ones who could leave.
Decide with a matrix, not a mood
Private cloud in 2026 is neither a retro affectation nor a sovereignty panacea. It is a specific tool for a specific intersection: sovereignty requirements, flat heavy load, scale, and a team — yours or a partner’s — that can genuinely operate it. Score your situation against that matrix honestly, and let the default win when it deserves to.
If you are weighing private cloud against the hyperscalers, or want the portability without the migration, our platform teams have run both sides of the trade — book a technical call, not a sales call.