Apache CloudStack: The Underrated Workhorse
The previous post in this series made the case that OpenStack is the closest thing to a private AWS and that the price of admission is an operational complexity that sinks roughly half the teams who attempt it. If you read that and thought “I want a real cloud — self-service, multi-tenant, API-driven, with a scheduler that places VMs for me — but I do not have a three-to-eight-person platform team to keep thirty microservices alive,” this post is for you. Apache CloudStack is the platform that occupies exactly that gap, and it is the most consistently underrated piece of infrastructure software in the open-source cloud world.
CloudStack’s problem is not capability; it is marketing. It does not have a foundation with hundreds of corporate members, a sprawling ecosystem of vendor distributions, or a conference circuit. What it has is a tight, integrated, opinionated design that you can stand up in an afternoon and that has quietly run production clouds at real hosting providers and telcos for over a decade. Where OpenStack hands you a kit of thirty interoperating services and says “assemble your cloud,” CloudStack hands you a cloud. That difference — a product versus a toolkit — is the entire story, and for a large fraction of teams it is the right trade.
The architecture: one management server, not thirty services
The single most important thing to understand about CloudStack, and the thing that makes it so much easier to run than OpenStack, is its architecture. The OpenStack post described a constellation: Nova, Neutron, Cinder, Glance, Keystone, Horizon, Placement, and two dozen more, each a separate service with its own database, message queue traffic, API, and upgrade cadence. CloudStack collapses almost all of that into one Java application — the management server — backed by one MySQL/MariaDB database.
CLOUDSTACK OPENSTACK
---------- ---------
+------------------------+ Nova Neutron Cinder
| Management Server | Glance Keystone Swift
| (one Java app) | Horizon Placement Heat
| - orchestration | Ironic Octavia Designate
| - networking control | Magnum Manila ... (30+)
| - storage control |
| - identity / multi- | each: own DB, own API,
| tenancy | own queue traffic, own
| - allocator/planner | upgrade path, own failure
| - web UI + API | mode. You wire them up.
+-----------+------------+
|
+------+------+
| MySQL DB | <- one schema, the whole cloud's state
+-------------+
|
------------+------------------------------
| | | |
[host] [host] [host] [host] <- hypervisors
KVM KVM XCP-ng VMware (the management
server controls them)
The management server is the brain. It holds the cloud’s state in MySQL, exposes the web UI and the API, runs the allocator and planner that decide where new VMs land, and orchestrates the hypervisor hosts. You can run it as a single node to start (fine for a homelab or a small cloud) and cluster multiple management servers behind a load balancer for HA in production — but the point is that “the control plane” is one thing you understand and operate, not a distributed system you babysit. There is no message-queue debugging, no “which of the thirty services is wedged this time,” no cross-service version-skew matrix. When something is wrong with the control plane, there is one log to read and one process to restart.
This is the design decision that everything else flows from. It is why a single engineer can run a CloudStack cloud, why deployment is measured in hours rather than weeks, and why the operational burden is a category lighter than OpenStack’s. It is also, as we will see, the source of CloudStack’s ceiling: a monolith is less infinitely-customizable than a microservice kit. For most people that ceiling is far above their needs.
The infrastructure hierarchy: zones, pods, clusters, hosts
CloudStack imposes a clean, rigid physical hierarchy on your hardware, and learning it is most of learning CloudStack. From largest to smallest:
| Level | What it is | Analogy |
|---|---|---|
| Zone | The largest unit — typically a datacenter. Has its own secondary storage and a public-facing network | AWS region / availability zone |
| Pod | A rack or row within a zone; a layer-2 broadcast domain for management | A rack |
| Cluster | A group of identical hypervisor hosts sharing primary storage and a hypervisor type | A vSphere cluster |
| Host | A single hypervisor (a KVM box, an XCP-ng host, an ESXi host) | One server |
| Primary storage | Fast storage holding running VM disks, attached at the cluster level | A datastore |
| Secondary storage | Zone-wide storage for templates, ISOs, and snapshots | An image/template library |
ZONE (datacenter) ── secondary storage (templates, ISOs, snapshots)
├── POD (rack)
│ ├── CLUSTER (same hypervisor type, shared primary storage)
│ │ ├── HOST (KVM)
│ │ └── HOST (KVM)
│ └── CLUSTER
│ ├── HOST (XCP-ng)
│ └── HOST (XCP-ng)
└── POD
└── CLUSTER ...
The rigidity is a feature. Because CloudStack knows exactly how your hardware is organized — which hosts share storage (a cluster), which clusters share a broadcast domain (a pod), which pods make up a datacenter (a zone) — it can make intelligent placement and live-migration decisions automatically. A cluster is the unit within which live migration “just works,” because all its hosts share primary storage and the same hypervisor. A zone is the unit of failure isolation and the boundary for templates and public networking. You map your real datacenter onto this model once, during setup, and from then on CloudStack uses it to do the right thing.
Note the per-cluster hypervisor homogeneity: a single cluster is all-KVM or all-XCP-ng or all-VMware, but a single zone can contain clusters of different hypervisors. This is how CloudStack supports a heterogeneous estate — you can run KVM clusters and VMware clusters side by side in one cloud, under one UI and API, migrating workloads between hypervisor types (4.20.2.0 specifically improved VMware-to-KVM migration, a timely capability as shops flee Broadcom’s VMware pricing).
The hypervisor story: KVM, XCP-ng, VMware, and the VMware exodus
CloudStack is hypervisor-agnostic in a way that genuinely matters right now. It supports:
- KVM — the default and most common, managed via libvirt on each host. The path most new deployments take.
- XCP-ng / XenServer — full support for the Xen-based platforms (the subject of a later post in this series), with pools and live migration.
- VMware vSphere — CloudStack can sit on top of ESXi/vCenter, and 4.20 deepened this with NSX-T v4 integration for advanced VMware networking.
The VMware support is strategically important in 2026. With Broadcom’s acquisition of VMware having upended licensing and pricing, a large number of organizations are looking for an exit, and CloudStack is one of the more credible landing spots: you can put CloudStack over your existing vSphere, then incrementally migrate workloads from VMware clusters to KVM clusters within the same CloudStack zone — same UI, same API, same tenants — retiring VMware licenses as you go rather than in a big-bang cutover. That “manage VMware today, migrate off it gradually” story is one CloudStack tells better than most, and it is driving real adoption.
The networking model: basic vs advanced zones
Here is CloudStack’s most opinionated design choice, and the one that most divides reactions. When you create a zone, you choose its networking model, and the choice is fairly fundamental.
Basic zones give every VM an IP directly on a shared, flat layer-3 network, with isolation enforced by security groups — exactly the model of the old AWS EC2-Classic. It is dead simple, scales to enormous numbers of hosts (no per-tenant VLANs to exhaust), and is what some very large providers run because of that scale. The trade-off is that tenants share an IP space and isolation is security-group-based rather than network-level; you do not get per-tenant private networks with overlapping ranges.
Advanced zones give each tenant isolated networks — VLAN-backed or overlay-backed — with a per-network virtual router providing DHCP, DNS, NAT, load balancing, VPN, and firewalling, plus VPC support for multi-tier topologies. This is the “real cloud” networking most people expect: tenants get private networks they fully control, with overlapping CIDR ranges across tenants, just like a public-cloud VPC. The cost is the complexity of VLAN/overlay management and the virtual-router appliances that implement it.
BASIC ZONE ADVANCED ZONE
---------- -------------
one flat L3 network per-tenant isolated networks
VMs get IPs directly each with a Virtual Router:
isolation = security groups DHCP, DNS, NAT, LB, VPN, FW
(like EC2-Classic) + VPC for multi-tier apps
(like a real VPC)
+ dead simple, huge scale + full tenant network isolation
- shared IP space - VLAN/overlay + appliance mgmt
The virtual router deserves a note because it is central to how CloudStack works and a frequent source of “how does this even function” confusion. CloudStack runs a set of system VMs — lightweight appliance VMs the management server deploys and manages automatically — that provide infrastructure services: the virtual router (per-network gateway services), the secondary storage VM (moves templates/snapshots), and the console proxy VM (browser-based VM consoles). You do not manage these by hand; CloudStack spins them up from a SystemVM template (4.20.2.0 ships a fresh Debian 12.12-based one) and heals them when they fail. They are the moving parts that make a basic-looking cloud actually deliver DHCP, NAT, and consoles. When networking misbehaves in CloudStack, the virtual router system VM is the first place to look.
The honest assessment of CloudStack networking: it is capable but prescriptive. You pick basic or advanced up front, you live within the model, and it is less of a blank-canvas SDN than OpenStack’s Neutron. For teams that want a working multi-tenant network without designing one, that prescriptiveness is a gift. For teams with exotic networking needs, it can feel like a straitjacket — which is the recurring CloudStack trade in miniature.
The allocator: placement that just happens
The thing that separates a cloud from “a pile of hypervisors with a UI” — and the thread running through this entire series — is automatic placement: when a tenant asks for a VM, the platform decides which host it lands on. CloudStack has this built in, via its allocator and planner subsystem, and it is on by default with no extra components to deploy.
When a VM deploy request comes in, CloudStack’s planner filters the candidate hosts (right zone, right cluster type, enough CPU/RAM, compatible storage, any affinity rules) and the allocator picks one according to a configurable strategy — first-fit (pack onto the first host that fits), random, or dispersion strategies that spread load. You can attach affinity and anti-affinity groups so that, say, two replicas of a database never land on the same host, or a set of VMs is kept together. Host HA restarts VMs elsewhere when a host dies. This is the same class of capability OpenStack gets from its Nova filter scheduler and that Proxmox conspicuously lacks (a later post covers exactly that gap) — and in CloudStack it is simply there, part of the one management server, requiring no assembly.
It is not as elaborate as a mature vSphere DRS with continuous load-rebalancing, and the planner’s sophistication is a notch below Nova’s deep filter/weigher stack. But it crosses the bar that matters: you do not pick hosts by hand, placement respects your rules, and the cloud rebalances on failure. For the overwhelming majority of private clouds, that is exactly enough.
Standing one up
The deployment experience is where CloudStack’s “product not toolkit” nature pays off most viscerally. A minimal proof-of-concept is a management server plus one KVM host, and the broad strokes are:
|
|
Then you open the web UI, run the zone-creation wizard — which walks you through defining the zone, pod, cluster, hosts, and primary/secondary storage with the hierarchy above — and you have a working cloud. The UI wizard doing the initial cloud bring-up is emblematic: CloudStack assumes you want guidance, not a thousand config files. Compare the OpenStack post’s reality of Kolla-Ansible, OpenStack-Ansible, or Sunbeam orchestrating dozens of containers, and the difference in time-to-first-VM is stark — hours versus a serious project.
Everything the UI does is also available through a full, well-documented API (with the cloudmonkey CLI and Terraform/OpenTofu providers for automation), so “click to learn, automate to operate” is a natural progression. Multi-tenancy is first-class: domains and accounts give you hierarchical tenant isolation, projects group resources, and per-tenant quotas and resource limits are built in — the IAM and quota story that lighter platforms (like the Incus/LXD covered next) lack.
Where it beats both OpenStack and the HCI crowd
The sweet spot, stated plainly. CloudStack wins when you want a genuine multi-tenant IaaS cloud — self-service portal, full API, isolated tenant networks, automatic placement, quotas — without OpenStack’s operational tax. Against OpenStack, it trades ultimate flexibility and ecosystem breadth for a control plane one person can actually run; for the very large set of teams whose needs are well inside CloudStack’s capabilities, that is a decisively better deal than signing up for the OpenStack operational commitment.
Against the hyperconverged (HCI) crowd — Proxmox, Harvester, the VMware-style cluster managers — CloudStack’s edge is that it is a cloud, not a cluster manager. Proxmox and friends are excellent at running VMs on a cluster you administer, but they are administrator-centric: you create the VMs. CloudStack is tenant-centric: you hand out self-service to many isolated tenants who provision their own VMs against quotas, on networks they control, through an API. When the requirement is “give fifty teams their own slice of the infrastructure with a portal and an API,” CloudStack does natively what the HCI platforms require bolting on (and a later post shows just how much bolting-on it takes to make Proxmox cloud-like). It also natively manages a heterogeneous hypervisor estate (KVM + XCP-ng + VMware in one pane), which the single-hypervisor HCI products do not.
The honest weaknesses
No platform in this series gets a free pass, and CloudStack has real ones:
- Smaller mindshare. This is the big one. CloudStack has a fraction of OpenStack’s community, far fewer Stack Overflow answers, fewer third-party integrations, fewer engineers who have run it, and a smaller talent pool to hire from. When you hit a novel problem, you are more likely to be reading source code than finding a blog post. The software is better than its popularity; that gap is itself a risk you take on.
- An aging UI in places. The web UI is functional and was modernized (the 4.x line moved to a cleaner interface, with ongoing refinements in 4.20), but parts still feel dated next to a polished commercial console, and the UX occasionally exposes the underlying model’s rigidity. It works; it is not always a delight.
- Opinionated networking. The basic-vs-advanced-zone decision is fundamental and not trivially reversible, and the model is prescriptive. If your networking needs fit CloudStack’s model, great; if they are unusual, you have less room to maneuver than Neutron gives you. Choose the zone type carefully, because you are committing to it.
- Fewer integrations and a thinner ecosystem. No vast marketplace of plugins, distributions, and vendor add-ons. What ships is what you mostly get (plus the solid Terraform/OpenTofu and CKS-for-Kubernetes pieces), which is fine if it covers you and limiting if you needed that one niche integration.
- The monolith ceiling. The single-management-server design that makes CloudStack easy also makes it less infinitely-scalable and less customizable than OpenStack’s microservices at the extreme top end. CloudStack scales to thousands of hosts in production — this is not a real constraint for most — but at hyperscale, or for deeply bespoke requirements, OpenStack’s modularity wins.
A note on project health, since “is it alive?” is a fair question for an under-marketed project: CloudStack is an active Apache top-level project with a steady release cadence — 4.20 is the current LTS (18-month support), 4.20.2.0 landed in October 2025 with around 150 fixes, and feature releases continue beyond it. Commercial support and engineering are available (notably from ShapeBlue), and it underpins production clouds at hosting providers and telcos. It is quietly healthy, not fading.
The verdict
Apache CloudStack is what you reach for when you have looked honestly at OpenStack and concluded that you want what it does but not what it costs to run. It delivers the things that make a private cloud a cloud — multi-tenancy, self-service, a full API, isolated networking, automatic placement, quotas — through a control plane that is genuinely operable by a small team, on top of whichever hypervisors you already run, including a graceful path off VMware. Its weaknesses are real but mostly about ecosystem and polish rather than capability: smaller community, dated edges, prescriptive networking. For a great many organizations, “less popular but far easier to run, and it does everything I actually need” is the correct trade, and CloudStack makes it better than anything else in its class.
If your needs are smaller still — mostly Linux workloads, a single team, and a desire for the lightest possible path to self-service-with-placement rather than full multi-tenant IaaS — then even CloudStack may be more than you need. That is exactly where the next post goes: Incus and LXD, the lightweight cluster that auto-places, where system containers and VMs live under one excellent CLI and new instances land on the least-loaded node with almost no operational weight at all.
Sources and further reading
- Apache CloudStack — project home
- Apache CloudStack 4.20.2.0 release notes
- What’s new in Apache CloudStack 4.20 — ShapeBlue deep dive
- What’s new in CloudStack 4.20.2.0 — ShapeBlue
- CloudStack vs OpenStack comparison — ShapeBlue
- OpenStack vs CloudStack for migrating off VMware — OpenMetal
- Apache CloudStack documentation
This is part of an ongoing series on private cloud platforms. Previous: OpenStack: The Full Reference Cloud. Next: Incus and LXD: The Lightweight Cluster That Auto-Places.
Comments