OpenStack is still worth it in 2026 if you have dozens of servers, several teams or customers who each need their own quotas and networks, and at least two engineers who will own the platform. The main advantages of OpenStack are no licence fees, one open API for compute, network and storage, real multi-tenancy, tight Ceph integration and freedom from any single vendor. The main disadvantages of OpenStack are the people and hardware it takes to run: a production cloud is a distributed system with a release every six months, and it only pays off above a certain size. For a small company with a handful of servers it is usually overkill, and a few plain KVM servers do the job with far less work.
Key facts, checked on 11 October 2026:
- The newest release is OpenStack 2026.2 "Hibiscus", shipped on 30 September 2026. The one before it, 2026.1 "Gazpacho", shipped on 1 April 2026, and 2027.1 "Indri" is planned for about 24 March 2027 (releases.openstack.org).
- About 600 people contributed 11,500 changes to Hibiscus, 21% and 28% more than for Gazpacho, according to OpenInfra figures reported by Network World on 30 September 2026.
- The OpenInfra Foundation estimated more than 55 million cores in production in October 2025, based on early analysis of the 2025 User Survey, with Walmart, Workday and CERN each running 1 million or more (OpenInfra press release, 1 October 2025).
- The OpenInfra Foundation, home of OpenStack, announced on 3 June 2025 that it was officially part of the Linux Foundation (OpenInfra blog).
- The Nova documentation says "KVM is configured as the default hypervisor for Compute" (Nova docs). In our lab, the Nova 31.0.0 package in Debian 13 ships with
virt_typeset tokvmby default.
OpenStack advantages and disadvantages side by side
Each row pairs a strength with the cost that comes with it. Read across, not down: most of the downsides are the price of the matching upside.
| Advantages | Disadvantages |
|---|---|
| No licence fee per core, socket or VM. The code is Apache 2.0. | You pay in salaries, control-plane servers and often a support contract instead. |
One REST API for VMs, networks, volumes, images and load balancers, usable from Terraform, Ansible and the openstack CLI. | Ten or more services sit behind that API, plus a database cluster and a message queue. Each can break. |
| Real multi-tenancy: projects, quotas, roles and private networks per team or customer. | Keystone roles and Neutron networking take weeks of study to set up safely. |
| Ceph plugs into Cinder, Glance and Nova, so disks, images and VMs share one storage pool. | Now you run two distributed systems, and Ceph wants at least three storage nodes. |
| Vendor neutral: pick the hardware, the distribution and the support company, or none. | Nobody owns the whole stack for you unless you pay someone to. |
| A release every six months with new hardware support, such as confidential computing in Hibiscus. | Each release is maintained for about 18 months, so upgrades are a permanent job. |
| Kubernetes runs well on top, with OpenStack providing the VMs, load balancers and volumes. | Teams that only run containers may not need the VM layer at all. |
| Scales from a lab to clouds of over a million cores with the same tools. | Below about ten hosts, the fixed overhead is out of proportion to the work it does. |
If you want the wider tour of each OpenStack service and who runs it, read why OpenStack is the engine behind modern cloud platforms. This article is the sceptic's companion: it looks at what the advantages cost and at the size where the sums work out.
Where OpenStack stands in October 2026
OpenStack names its releases by year and half, and gives each one a code name in alphabetical order. The schedule on releases.openstack.org, read on 11 October 2026:
| Release | Shipped | Upgrade type | What it means for you |
|---|---|---|---|
| 2027.1 Indri | Planned for about 24 March 2027 | SLURP | The next yearly target for clouds on Gazpacho |
| 2026.2 Hibiscus | 30 September 2026 | Regular | Newest; end of life estimated for 26 April 2028 |
| 2026.1 Gazpacho | 1 April 2026 | SLURP | The sensible base for a new cloud today |
| 2025.2 Flamingo | 1 October 2025 | Regular | End of life estimated for 28 April 2027 |
| 2025.1 Epoxy | 2 April 2025 | SLURP | Its move to "unmaintained" was estimated for 2 October 2026 (still listed as maintained on 11 October), so plan the jump to Gazpacho now |
SLURP stands for Skip Level Upgrade Release Process. Since 2023 every first release of the year is a SLURP release, and the Technical Committee's 2022 resolution says upgrades "will be supported between 'SLURP' releases". In plain words: you may upgrade once a year, from Epoxy straight to Gazpacho, instead of every six months. The same resolution warns that rolling upgrades between SLURP releases are not promised, so a yearly jump can mean some downtime.
Development is busier than the "OpenStack is dead" posts suggest. Hibiscus brought AMD SEV-SNP and Intel TDX confidential computing to Nova, an EVPN service plugin to Neutron, and Lustre and Weka drivers to Manila (Hibiscus highlights). The same notes also show the other side: Nova services now default to native Python threading instead of eventlet, and Horizon switches on stricter policy defaults. Those are exactly the changes an operator has to test before upgrading.
On adoption, the figures to trust are the Foundation's own. Its 16 November 2023 report counted 45 million production cores, up 350% from 10 million in 2018, and found about 23% of deployments in organisations with 10 to 99 employees. The October 2025 estimate raised the total to more than 55 million cores. We found no published 2026 survey results on 11 October 2026, so 55 million is still the latest official number. Treat any higher figure you see elsewhere with suspicion until the Foundation publishes it.
The VMware effect: a reason to look, not a reason to choose
Broadcom completed its purchase of VMware on 22 November 2023 and moved customers from perpetual licences to per-core subscriptions. That single change did more for OpenStack's visibility than any release. The Foundation's VMware migration page says 80% of OpenInfra members have had requests to move users from VMware to OpenStack and 60% have completed a migration. The page gives no date or sample size, and the members are companies that sell OpenStack services, so read it as a signal of demand rather than a market share.
A renewal quote that doubles is a fair trigger to compare options. It is a weak reason to pick the biggest one. Many vSphere estates are three to ten hosts run by one IT team, and for them the jump to OpenStack swaps a licence problem for a staffing problem. Our VMware to OpenStack guide covers the Broadcom timeline in detail, and the migration steps article walks through the actual disk and driver conversion.
The advantages, with the evidence
No licence fees, and nobody can reprice you
OpenStack has no licence server and no per-core count. That does not make it free to run, but it removes the one cost a vendor can change at renewal time. You can still buy support from a distribution vendor, and you can drop that vendor without reinstalling.
APIs first
Everything in OpenStack, from creating a VM to attaching a floating IP, is an API call. The dashboard is just another client. That is what lets developers build their own environments without opening a ticket, and what lets you rebuild a whole stack from a Terraform file.
Multi-tenancy built in
A tenant, called a project in OpenStack, is a group of users with its own quota, its own private networks and its own permissions. Two projects can even use the same private IP range without clashing. This is the feature that separates OpenStack from a simple cluster of hypervisors, and it is why hosting companies, universities and telecoms use it.
Ceph integration
Ceph is open-source storage that spreads data over many servers. Cinder (volumes), Glance (images) and Nova (VM disks) can all store on the same Ceph cluster, so a new VM is a fast copy-on-write clone of its image instead of a full copy. We tested Ceph on its own in a three-VPS Ceph lab, and the RBD block storage article shows what the disks underneath a cloud can do.
Vendor neutrality
The project is governed by an elected Technical Committee and, since 2025, sits under the Linux Foundation. You can install it from upstream code, from Debian or Ubuntu packages, or from a commercial distribution, and the APIs stay the same.
Kubernetes on top
The Foundation's 2023 report found Linux, OpenStack and Kubernetes running together in over 70% of reported deployments. The pattern is simple: OpenStack hands out VMs, networks, load balancers and volumes, and Kubernetes clusters use them through the OpenStack cloud provider. You get container orchestration plus tenants and VMs for workloads that do not fit in containers.
The disadvantages nobody prices in
Operational complexity
A small production cloud runs an API service for each project, schedulers, agents on every compute node, a clustered MariaDB, RabbitMQ and load balancers in front of the APIs. When one VM fails to boot, the cause can sit in Nova, Placement, Neutron, Glance, Cinder or the message queue. Deployment tools such as Kolla-Ansible and OpenStack-Ansible make installing it repeatable. They do not make the system smaller.
Staff skills
The people you need know Linux, KVM, Open vSwitch or OVN, VLANs and overlay networks, Ceph, and enough Python to read a traceback. One person is a single point of failure; holidays and sick days still happen. Our rule: if you cannot name two people who will own the control plane, buy OpenStack as a managed service or choose something smaller.
Upgrades every six months
SLURP turned the six-month treadmill into a yearly one, but it is still a treadmill. Epoxy, released in April 2025, was due to leave the maintained phase in October 2026. The Foundation's 2023 report said upgrades were "a common pain point which prevented many organizations from running the most recent release". Budget a test environment and a few weeks of work every year, forever.
Minimum hardware for a real cloud
A learning install is small. The Kolla-Ansible quick start asks for one host with 2 network interfaces, 8 GB of RAM and 40 GB of disk. A cloud you would put customers on is a different thing:
| Setup | Servers | What it is good for |
|---|---|---|
| All-in-one (DevStack or Kolla-Ansible) | 1 host or VM, 8 GB RAM or more | Learning the APIs and testing. Not production. |
| Small production, our estimate | 3 controllers, 3 Ceph nodes, 2 or more compute nodes | Survives one failed server. Controllers come in threes so the database and RabbitMQ clusters keep a majority. |
| Converged small production, our estimate | 3 to 5 servers running controller, Ceph and compute roles together | Cheaper, but a busy VM and a Ceph recovery now fight for the same CPU and RAM. |
The two production rows are our engineering estimate, not an official minimum. The point stands either way: the control plane costs about the same whether it serves 2 compute nodes or 200.
Overkill for small companies
A five-person company with a website, a database and a CI runner does not need tenants, quotas or a self-service API. It needs a few servers that stay up. Building OpenStack for that is like hiring a facilities manager for a single flat.
OpenStack vs KVM: what the comparison really means
"OpenStack vs KVM" is a common search, but the two are not rivals. KVM (Kernel-based Virtual Machine) is the part of the Linux kernel that runs virtual machines on the CPU. QEMU adds the virtual devices and libvirt is the management layer that starts and describes VMs. OpenStack is the control plane above them: Nova, its compute service, decides which host gets a VM and then asks libvirt on that host to start it. So the real question is "plain KVM hosts, or KVM hosts managed by OpenStack?". Our KVM vs OpenStack vs Proxmox article explains each layer in more depth.
Lab: a KVM guest with no OpenStack at all
To show the layer underneath, we ran a KVM guest by hand on 11 October 2026. The lab machine was a Debian 13 virtual machine with 2 vCPUs and 3 GB of RAM on our Amsterdam test server, with nested virtualization switched on. The guest is CirrOS, the tiny test image that DevStack also uses. No OpenStack was installed.
Step 1. Check that the CPU offers virtualization and that the KVM modules are loaded:
# as root
grep -Ec '(vmx|svm)' /proc/cpuinfo
lsmod | grep kvmWe saw 2 (one per vCPU, these are AMD CPUs so the flag is svm) and the modules kvm_amd and kvm. A result of 0 means no hardware virtualization, and KVM cannot work.
Step 2. Install QEMU, libvirt and the helper tools, then start libvirt's built-in NAT network:
# as root
apt-get update
apt-get install -y --no-install-recommends qemu-system-x86 qemu-utils libvirt-daemon-system libvirt-clients virtinst ovmf wget
apt-get install -y --no-install-recommends dnsmasq-base nftables
virsh net-start default
virsh net-autostart defaultThe first install took 37 seconds in our lab and used about 263 MB of disk. The ovmf package (UEFI firmware) is optional for this test. Expected output from the last two lines: Network default started and Network default marked as autostarted. Without the second line our first attempt failed with "network 'default' is not active".
Step 3. Create a normal user who may manage VMs, and let the libvirt service read files in that user's home folder:
# as root
adduser --disabled-password --gecos "" ops
usermod -aG libvirt,kvm ops
chmod 711 /home/ops
id opsThe id line should list the groups kvm and libvirt.
Step 4. As that user, download CirrOS, check it and make a copy-on-write disk on top of it:
# as the ops user
export LIBVIRT_DEFAULT_URI=qemu:///system
mkdir -p ~/lab && cd ~/lab
wget -q https://download.cirros-cloud.net/0.6.3/cirros-0.6.3-x86_64-disk.img
wget -q https://download.cirros-cloud.net/0.6.3/MD5SUMS
grep x86_64-disk.img MD5SUMS; md5sum cirros-0.6.3-x86_64-disk.img
qemu-img create -f qcow2 -F qcow2 -b cirros-0.6.3-x86_64-disk.img vm1.qcow2 1GBoth checksum lines printed 87617e24a5e30cb3b87fda8c0764838f. The image is a 20.7 MiB qcow2 file. The new vm1.qcow2 only stores changes and reads everything else from the base image, which is also how Nova's default local storage keeps many VMs on one cached image.
Step 5. Start the guest with KVM and look at what libvirt made of it:
# as the ops user
virt-install --name vm1 --memory 256 --vcpus 1 --virt-type kvm --import \
--disk path=/home/ops/lab/vm1.qcow2,bus=virtio \
--network network=default,model=virtio \
--osinfo cirros0.5.2 --graphics none --noautoconsole
virsh list --all
virsh dumpxml vm1 | grep -E "<domain|<emulator|driver name|<type "
virsh domifaddr vm1What we saw after about 45 seconds:
# output, as the ops user
Id Name State
----------------------
2 vm1 running
<domain type='kvm' id='2'>
<type arch='x86_64' machine='pc-i440fx-10.0'>hvm</type>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<driver name='qemu' type='qcow2'/>
vnet0 52:54:00:58:15:61 ipv4 192.168.122.106/24domain type='kvm' is the proof: libvirt asked the kernel's KVM module to run this guest. The QEMU process in the lab machine carried the arguments -accel kvm, used 247 MiB of resident memory for a 256 MB guest, and answered ping in 0.57 ms on average. Memory in use on the lab machine rose from 418 MB to 662 MB with the guest running.
What Nova adds on top
An OpenStack compute node runs this same libvirt, KVM and QEMU stack. To check Nova's own defaults without installing a cloud, we downloaded and unpacked the Debian 13 package:
# as the ops user
apt-get download python3-nova
dpkg-deb -x python3-nova_*.deb x
grep -n -A3 "'instance_name_template'" x/usr/lib/python3/dist-packages/nova/conf/compute.py
grep -n -A3 "StrOpt(.virt_type" x/usr/lib/python3/dist-packages/nova/conf/libvirt.py# output, as the ops user
1493: cfg.StrOpt('instance_name_template',
1494- default='instance-%08x',
1495- help="""
1496-Template string to be used to generate instance names.
105: cfg.StrOpt('virt_type',
106- default='kvm',
107- choices=('kvm', 'lxc', 'qemu', 'parallels'),
108- help="""The package is Nova 31.0.0, which is the 2025.1 Epoxy release. So on a stock compute node, Nova talks to libvirt with virt_type = kvm, and the VMs it creates show up in virsh list with names like instance-0000002a. Everything above that line is what OpenStack adds: a scheduler that picks the host, Placement to count free capacity, Neutron for networks, Cinder for volumes, Keystone for users and projects. If you do not need those, plain KVM is the same engine with less around it.
Should you use OpenStack? A decision table by size
Start with the size and shape of your organisation. The servers column counts physical hosts, or rented servers, that you expect to have within two years.
| Your situation | Servers | Usually the better fit | Why |
|---|---|---|---|
| Freelancer, startup or small business, no platform team | 1 to 5 | Plain KVM servers, rented as VPS or VDS | You need servers, not a cloud to look after |
| One IT team leaving vSphere | 3 to 20 | Proxmox VE, or plain KVM hosts with libvirt | Clustering and live migration with far fewer moving parts |
| Mid-size company that wants self-service VMs with a lighter control plane | 5 to 50 | OpenNebula or Apache CloudStack | Multi-tenant clouds with fewer services to run than OpenStack |
| Mostly containers, a few VMs | Any | Kubernetes with KubeVirt | One platform for containers and the odd VM |
| Several teams or customers, each with quotas and private networks | 20 and up | OpenStack | Tenants, APIs and Ceph integration are built in |
| Hosting provider, telecom, university, research centre | 100 and up | OpenStack | At this scale the fixed overhead is small and the APIs pay back |
The server counts are our rule of thumb, not a published threshold. Three questions settle most borderline cases. Do you have tenants? Will you pass about ten hosts soon? Can you name two people who will run it? Three yes answers point to OpenStack. One or none points to something simpler. For a direct comparison with the most common alternative, see Proxmox vs OpenStack.
Frequently asked questions
What are the main advantages of OpenStack?
OpenStack has no licence fees, offers one open API for compute, networking and storage, supports many tenants with their own quotas and private networks, integrates closely with Ceph storage and is not tied to any single vendor. It runs from small labs to clouds with more than a million cores.
What are the disadvantages of OpenStack?
OpenStack is complex to operate, needs engineers who know Linux, networking and storage, ships a release every six months with about 18 months of maintenance each, and needs several servers for a resilient production setup. For small companies the overhead usually outweighs the benefits.
Is OpenStack still relevant in 2026?
Yes. Version 2026.2 Hibiscus shipped on 30 September 2026 with about 600 contributors, and the OpenInfra Foundation's latest estimate is more than 55 million production cores. Its users are mostly hosting providers, telecoms, research centres and large enterprises.
What is the difference between OpenStack and KVM?
KVM is the hypervisor in the Linux kernel that actually runs virtual machines. OpenStack is a control plane that manages many KVM hosts through libvirt, adding scheduling, networks, storage, users and APIs. Nova, OpenStack's compute service, uses KVM by default.
Is OpenStack free?
The software is free under the Apache 2.0 licence. Running it is not: you pay for the hardware, the engineers who operate it and, often, a support contract from a distribution vendor.
How many servers do you need for OpenStack?
One host with 8 GB of RAM and 40 GB of disk is enough for a learning install with Kolla-Ansible. A production cloud that survives a server failure typically needs three controller nodes plus compute and storage nodes, anywhere from three converged servers to eight or more with separate roles, by our estimate.
Start small, grow into it
Most teams reading a pros and cons list do not need a private cloud yet. They need a few reliable machines. Every RS Computers VPS and VDS is a KVM virtual machine, the same hypervisor that sits under Nova, with NVMe storage, unmetered traffic and its own IPv4 and IPv6, in Amsterdam, Dublin and Prishtina. The VDS plans go up to 16 vCPUs and 32 GB of RAM with 10 Gb/s ports, and you can move to a bigger plan later from the client area with a short reboot. Availability by city is on the plans page. Compare them on our VPS and VDS plans, and if you are weighing a few servers against a full cloud, ask us on Telegram.