When OpenStack is Not a Good Fit for Your Team

OpenStack isn't the right answer for every team or workload, and knowing when it isn't matters as much as knowing when it is. An honest guide to fit, from a team that's been operating it since 2011.

We've been part of the OpenStack community since Bexar, the second release, in 2011. Our CEO, Mohammed Naser, has chaired the Technical Committee, served as PTL across multiple projects, and sits on the OpenInfra Foundation board. Since 2016, we've contributed infrastructure to OpenDev, the development and CI backbone for the OpenStack community, including GPU-enabled instances and high-memory VMs that keep the project's testing pipeline running.

We have a history of deploying new OpenStack releases on the same day they launch, which is made possible because of how deeply our team invests in the upstream development process.

We are telling you this because it's the context for what follows. This post argues, in some cases, that you should not use OpenStack. That argument is only worth reading if it comes from people who have earned an opinion on the subject.

This is a genuine guide to fit. If you are evaluating OpenStack, whether to build on it, operate it yourself, or use a cloud that runs it, here is an honest account of where it belongs and where it doesn't.

What OpenStack Is

OpenStack is infrastructure software for building and operating clouds: compute, networking, storage, identity, orchestration, and more assembled into a coherent platform. It is the open-source alternative to AWS, Azure, and GCP. Where hyperscalers ask you to rent infrastructure on their terms, OpenStack lets you build and own a cloud on yours. The control, the hardware, the network topology, the data residency, the cost model, and the upgrade cadence are yours to govern.

That ownership is both its value and its weight. OpenStack gives you power that hyperscalers explicitly withhold. It also requires that you be capable of using that power, which is a real qualification and not a polite caveat.

Workloads That Belong on a Hyperscaler

You need a managed service with no mature open-source equivalent.

The hyperscalers have spent hundreds of billions building services that do not yet exist in open infrastructure: serverless compute with millisecond billing, globally replicated databases with automatic failover across continents, fully managed ML training pipelines with custom silicon. If your workload's competitive advantage depends on one of these services, you should use them. The open infrastructure ecosystem closes gaps over time, but the gap is real today for certain workloads.

You have bursty, unpredictable demand that spikes by orders of magnitude.

OpenStack is well suited to workloads with predictable capacity profiles, which is most workloads in most organizations. For a consumer product that could go from a hundred requests per second to a hundred thousand overnight, a hyperscaler's elastic capacity carries genuine value. You are paying for optionality, and for some workload profiles that optionality is worth the cost.

Your regulatory requirement names a specific hyperscaler.

Some compliance frameworks, government contracts, and industry certifications are scoped to named platforms. FedRAMP-authorized services, certain financial frameworks, and specific healthcare data agreements sometimes specify hyperscalers by name. When compliance requires a particular platform, use that platform.

You are an early-stage company with a small team and no infrastructure background.

OpenStack has a real learning curve. Running it well requires people who understand how networking, storage, and compute interact at a level below what most application developers ever need. If your entire engineering team is focused on shipping a product, the operational overhead of self-managed infrastructure is a genuine cost. Using a hyperscaler's managed services while you build the team to think about infrastructure differently is a reasonable call. Revisit the question when your scale and team make it worth revisiting.

Team Profiles That Are Not Ready for OpenStack

This is the section most vendors skip. We're including it because a team running OpenStack beyond its operational capacity has a bad time, and no one benefits from that.

Nobody owns infrastructure as a primary responsibility. OpenStack requires operational ownership: upgrades, capacity planning, incident response, security patching, configuration management. If the person responsible for your OpenStack deployment also owns CI/CD, developer tooling, and data engineering, it will be under-maintained. That is a mismatch of scope, not a failing of the individual.
You have not run an open-source infrastructure project at scale before. OpenStack is not a good first open-source infrastructure project to run in production. Experience operating something at scale first — a database cluster, a Kubernetes deployment, a storage system — builds the intuition for distributed system failure modes, upgrade risk, and the gap between what documentation says and what your specific hardware configuration does. If your team hasn't developed that intuition yet, OpenStack will teach it at an expensive moment.
You want managed, not operated. Some organizations know they want cloud infrastructure but not the work of running it. That is completely legitimate. If you want OpenStack's capabilities:
🔷 bare metal control
🔷 data sovereignty
🔷 predictable pricing
🔷 open standards
without the operational burden, the right answer is a managed OpenStack cloud, not a self-operated one. We run one. This is a different product from running OpenStack yourself, and it is the right fit for many organizations.
You are planning a very small deployment for a non-trivial production workload. OpenStack's design assumes distribution. Its failure modes, upgrade paths, and operational tooling are optimized for multi-node deployments. Running it at very small scale to avoid cloud costs is usually a false economy: you lose the resilience OpenStack is designed to provide while paying the full operational overhead. At small scale, a managed Kubernetes service or a hyperscaler's smaller tiers will serve you better.

When Managed Kubernetes Without OpenStack Is the Right Call

Your entire infrastructure footprint is containerized and stateless.

If every workload you run is a container, your storage requirements are object storage and managed databases, and you have no bare metal or VM-level requirements, you may not need the layer OpenStack provides. Managed Kubernetes gives you workload orchestration without requiring you to own the compute layer beneath it. OpenStack earns its place when you need that layer. If you genuinely do not, you are paying for abstraction you are not using.

Your team has deep Kubernetes expertise and no OpenStack expertise, and the workload fits. Operator expertise matters.

If your infrastructure team knows Kubernetes well and has never operated OpenStack, and your workloads fit cleanly in containers, adding OpenStack is adding a large unfamiliar system to reach a capability you already have. The learning investment is only justified if OpenStack gives you something specific you cannot get from managed Kubernetes alone: bare metal, data sovereignty, VM workloads, economics at significant scale.

You are running edge workloads at locations where a full OpenStack control plane is impractical.

Small-footprint edge deployments at retail locations, manufacturing floors, or remote facilities often cannot support a proper OpenStack control plane. Lightweight Kubernetes distributions serve these use cases well. OpenStack has edge capabilities and the community is actively developing them, but for many current edge deployment patterns, Kubernetes alone is the simpler and more reliable choice.

You need a development environment that mirrors a hyperscaler target closely.

If your engineers are building applications that will run on GKE or EKS in production and you want a private development environment that mirrors that experience, managed Kubernetes is a better fit than OpenStack with Kubernetes on top. The mapping is cleaner and the tooling transfers more directly.

Where OpenStack Is Genuinely the Right Answer

You have VM workloads, legacy applications, or mixed infrastructure that is not fully containerized.

Container orchestration needs compute underneath it. OpenStack provides that layer, along with networking, storage, and identity, as a coherent whole. If your infrastructure includes virtual machines, be that for databases, for Windows workloads, or for applications that predate containers, you need something beneath your container layer. OpenStack is the best open-source answer to that.

You want to move away from VMware but not to a hyperscaler.

We built MigrateKit specifically for this transition: it is an open-source near-live migration toolkit for moving VMware environments to OpenStack, because the "we have a lot of VMs and we want out of our current platform" problem is one we have helped many organizations work through.

Data sovereignty, regulatory residency, or security posture requires infrastructure you control.

Healthcare data in a specific jurisdiction. Financial transaction data with strict audit requirements. Workloads that cannot share infrastructure for compliance or contractual reasons. Defence and government deployments with network isolation requirements. These are not niche cases. They represent a large and growing share of serious infrastructure requirements, and they are ones that hyperscalers structurally cannot address. OpenStack on hardware you control, in a location you specify, with people under your authority managing it, is the answer.

You are running at the scale where public cloud economics reverse.

At sufficient scale, the per-unit economics of public cloud become punishing. The inflection point varies by workload characteristics and operational capacity, but it exists, and it is lower than most people expect. If you are spending seven figures annually on hyperscaler compute that could run on owned or leased hardware, the math is worth doing carefully. Many organizations have found that the operational investment in OpenStack pays back within a year or two at that scale.

You want to own your infrastructure dependencies.

Hyperscalers deprecate services, change pricing, modify APIs, and make product decisions that affect your operations. Open infrastructure gives you a fundamentally different relationship with change: the community governs the roadmap, the software is yours to inspect and modify, and you are not subject to a vendor's product strategy. For organizations where that autonomy matters, and for many it matters a great deal, OpenStack is the right foundation.

The Honest Summary

The question is not whether OpenStack is good. The question is whether it is right for your specific situation, and that requires looking at your workloads, your team, your compliance requirements, and your operational appetite honestly.

If you are working through an infrastructure decision and you are uncertain whether you are ready for OpenStack, the most useful thing we can tell you is: talk to someone who has operated it at scale and ask about the failure modes, not the success stories. Ask what they would do differently. Ask what the first year looked like. The community is open about this, which is one of the things that makes it worth being part of.

If you conclude that OpenStack is not the right answer for you right now, that is a good conclusion to reach before committing resources.

VEXXHOST has been contributing to the OpenStack community since 2011 and operates production clouds for organizations ranging from research institutions to commercial enterprises. We build Atmosphere, a production-ready OpenStack platform supporting managed private cloud, public cloud, and hybrid deployments. We are a Gold Member of the OpenInfra Foundation and a member of the Linux Foundation, CNCF, and Ceph Foundation. If you are working through an infrastructure decision and want a direct conversation, we are happy to have it.

Les dernières de notre équipe

Deploy Kubernetes on Bare Metal, OpenStack, or Any Cloud with One API

Why Data Sovereignty Laws Are Forcing A Shift Toward Localized Private Infrastructure

Why Navos Is Built on Cluster API — Architecture, Portability & Multi-Cloud Explained