# Apache CloudStack: an IaaS platform for operators who own the hardware > Apache CloudStack orchestrates virtual machines across VMware, KVM, XenServer, XenProject and Hyper-V from a single management server and API. It is a fit for service providers and private-cloud teams, and a poor fit for anyone who wants a one-command lab. **apache/cloudstack** — Apache CloudStack is an opensource Infrastructure as a Service (IaaS) cloud computing platform. - Repository: https://github.com/apache/cloudstack - Website: https://cloudstack.apache.org/ - Stars: 3,082 · Forks: 1,387 - Language: Java - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/apache-cloudstack ## The problem CloudStack solves, and who ends up running it CloudStack targets a specific operator: someone who already owns racks of hypervisors and needs a control plane above them. The README describes it as software "designed to deploy and manage large networks of virtual machines", and lists the audience directly: service providers offering public cloud, companies building an on-premises private cloud, and hybrid setups. If you have a single server and want containers, this is the wrong layer entirely. The scope is deliberately broad. The README calls it a turnkey solution covering compute orchestration, Network-as-a-Service, user and account management, a native API, resource accounting and a UI. That list matters because it is the difference between CloudStack and a hypervisor manager: a KVM host already schedules VMs, but it does not know what a tenant is, does not meter CPU hours, and does not expose a query API. CloudStack supplies those pieces. The supported hypervisor list is the other half of the audience definition. VMware vSphere, KVM, XenServer, XenProject and Hyper-V are named, plus OVM and LXC containers. That is a heterogeneous fleet, and CloudStack's value proposition is precisely that you do not have to standardise on one vendor before you can manage it. ## How the management server, agents and hypervisors fit together The repository layout tells you most of the architecture before you read a line of documentation. There is a server/ directory for the management server, an agent/ directory for the in-host agent, plugins/ for hypervisor and storage integrations, and a vmware-base/ directory that exists solely for the vSphere path. api/ holds the API surface, client/ and cloud-cli/ the clients, and ui/ the web interface. In practice the management server is the single point where state lives. It talks to the database, exposes the API and the UI, and dispatches commands to agents running on the hypervisor hosts. Those agents do the local work: starting and stopping VMs, attaching storage, wiring networks. systemvm/ is the third leg, holding the system virtual machines that CloudStack deploys for things like secondary storage and virtual routing. This split has a consequence worth stating plainly. The management server is a central component, so its availability and database health bound the whole cloud. The README's "highly available" claim refers to the design intent of the platform, not to the management server being magically redundant. Anyone planning production should treat the management server tier as a service to be made redundant on its own terms. ## Installing Apache CloudStack and making a first API call The README does not give a package install sequence. It gives two paths: download a released version from the downloads page, or build from source following INSTALL.md. The repository also ships debian/ and packaging/ directories, which is where distribution packaging lives. The honest summary is that installation is documented in INSTALL.md and the project documentation, not in the README. Start by getting the source if you intend to build. The README names the official Git repository and the GitHub mirror, and notes that the mirror is strictly read only. It gives the clone URL in exactly this form: ```bash git clone https://gitbox.apache.org/repos/asf/cloudstack.git ``` The build is Maven-based, as the top-level pom.xml indicates, and the repository root carries a .java-version file. The README points at INSTALL.md for the build instructions rather than spelling out the command, so read INSTALL.md for your target platform before running anything. The project also publishes a running demo, which is the cheapest way to see the UI before you commit hardware. The README gives the URL and credentials directly. ```text https://qa.cloudstack.cloud/simulator/ (admin:password) ``` Once a management server is up, the API is the interface most automation will use. It is query-based, and the README links a separate API documentation site. The README does not show a sample request, so read the API documentation before writing client code rather than guessing at parameter names. For scripting, the repository includes a python/ directory and a requirements.txt. That file exists mainly to install the SolidFire SDK for Python, and it notes that Marvin dependencies come from their own bundle. Do not assume requirements.txt installs the CloudStack client library; it does not. ## Where CloudStack stops being the right tool The clearest limitation is operational weight. CloudStack is a distributed system with a management server, a database, agents on every host, and system VMs. That is a lot of moving parts before your first tenant VM exists. A lab or a small internal environment will spend more time on the control plane than on the workloads it wanted to run. Second, the README is not an installation guide, and that is a signal about the intended user. It links INSTALL.md, the downloads page and the documentation site, but does not walk a newcomer through a minimal deployment. If you need a step-by-step path from zero to a working cloud, expect to read the project documentation, not the repository front page. Third, the supported hypervisor list is a boundary, not a suggestion. If your fleet runs a hypervisor outside VMware vSphere, KVM, XenServer, XenProject, Hyper-V, OVM or LXC, CloudStack is not the tool for you without custom plugin work. There is no claim in the README of broader coverage. Finally, the README does not document rollback or in-place upgrade procedures for the management server. The release notes are linked separately. Anyone planning an upgrade should read those release notes rather than inferring a procedure from the README, which says nothing about it. ## CloudStack against OpenStack and Proxmox The comparison people actually search for is CloudStack versus OpenStack, and the architectural difference is the useful part. OpenStack is a collection of separately deployed services that you assemble and operate; CloudStack ships as one platform with a management server, agents and system VMs, and the README presents it as a turnkey stack covering orchestration, networking, accounts, API, accounting and UI. Fewer integration decisions, less freedom to swap individual components. Against Proxmox, the split is different again. Proxmox is a hypervisor platform built around KVM and LXC with its own management interface, aimed at running virtual machines and containers on hardware you control. CloudStack sits one level up: it manages fleets of hypervisors, including KVM, and adds the multi-tenant account model, resource accounting and query API that a provider needs to bill and delegate. If you are one team running one cluster, Proxmox is closer to the problem. If you are handing accounts to customers, the CloudStack layer is the point. Both comparisons come down to the same question: do you need a tenant model and an API, or do you need virtual machines? CloudStack answers the first question. ## Releases, licensing and what an upgrade actually costs CloudStack is licensed under Apache-2.0, and the README carries the standard Apache header plus a NOTICE file and a separate notice about cryptographic software. The cryptographic notice is worth reading before you redistribute anything, since export rules can apply to software that includes encryption. That is a compliance question for your own counsel, not something the repository settles. The release cadence visible in the repository is LTS-oriented. 4.22.1.0 is labelled LTS and 4.22.1.1 is labelled an LTS security release, with 4.20.3.1 as a parallel security release on the older line. The practical read is that security fixes land as point releases on maintained LTS branches, so an upgrade is not a single-track affair: you may need to decide whether you stay on 4.20.x or move to 4.22.x, and both received security releases on the same day. The last push to the repository was on 2026-08-21. Upgrading means reading the release notes linked from the README, checking the CHANGES.md file in the repository root, and testing against your hypervisor and storage plugins. The README does not describe a rollback path, so the cost of a failed upgrade is something you have to plan for yourself. ## Conclusion Adopt CloudStack if you operate your own hypervisor fleet and need account management, resource accounting and a query-based API in one control plane; skip it if you want a single binary that boots a cluster in minutes, because the README points you at released packages and INSTALL.md rather than a one-liner. Before committing, read INSTALL.md for your target distribution, confirm which hypervisor in the supported list your hosts run, and check whether the 4.22.1.1 or 4.20.3.1 LTS security line matches the branch you plan to run. ## FAQ ### Is Apache CloudStack free? Yes. The repository is licensed under Apache-2.0, and the README includes the standard Apache licence header. There is no paid tier described in the README, though commercial distributions of CloudStack are mentioned in the user list. ### What is Apache CloudStack? It is open source software for deploying and managing large networks of virtual machines, described in the README as a highly available and highly scalable Infrastructure as a Service platform. It includes compute orchestration, Network-as-a-Service, account management, a native API, resource accounting and a UI. ### What is the difference between OpenStack and CloudStack? The README presents CloudStack as a turnkey solution that includes the whole stack of IaaS features in one platform, with a management server, agents and system VMs. OpenStack is assembled from separately deployed services, so the trade-off is fewer integration decisions against less freedom to replace individual components. ### Is CloudStack a hypervisor? No. CloudStack manages hypervisors rather than being one. The README lists VMware vSphere, KVM, XenServer, XenProject and Hyper-V as supported, along with OVM and LXC containers. ### How do I install Apache CloudStack? The README gives two routes: download a released version from the downloads page, or build from source using the instructions in INSTALL.md. It does not provide a package install sequence itself, so INSTALL.md and the project documentation are the places to follow. ### How do I use Apache CloudStack once it is running? The README states that users manage the cloud through a web interface, command line tools, or a full-featured query-based API, and it links separate API documentation. The repository also ships a client/ and cloud-cli/ directory for the command line path. ## Sources - [Official documentation](https://cloudstack.apache.org/) - [Official README](https://github.com/apache/cloudstack#readme) - [Project repository](https://github.com/apache/cloudstack) - [Release notes](https://github.com/apache/cloudstack/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-cloudstack