# ZStack IaaS: API-driven private cloud management

> ZStack is an open source IaaS platform for managing compute, storage, and networking through APIs. Its plugin architecture, rollback workflow, and downloadable deployment model target private clouds and large public-cloud infrastructure.

**zstackio/zstack** — ZStack - the open-source IaaS software http://zstack.org (国内用户请至 http://zstack.io)

- Repository: https://github.com/zstackio/zstack
- Stars: 1,402 · Forks: 400
- Language: Java
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/zstackio-zstack

## What ZStack manages

ZStack solves the operational problem of running infrastructure as a service across a data center. Its intended users are cloud operators who need to automate physical servers, virtual machines, storage, and networking rather than configure each component separately. The README describes users controlling a cloud through either a web UI or a command line tool, with both interfaces interacting with ZStack management nodes.

The central design choice is API management. Resources are not presented as a collection of local configuration files that operators must maintain independently. Instead, ZStack exposes operations for managing the data center and provides query APIs for finding resources. The README includes examples such as filtering virtual machine NICs by a guest IP and filtering hosts by fields such as name, management IP, hypervisor type, virtual machine state, and attached-volume size. Those examples indicate that resource discovery is intended to be part of the platform rather than an operation requiring direct database access.

The project is aimed at both a first proof of concept and larger deployments. The README says that a proof of concept can run on one Linux machine, while a multi-node production environment can be deployed across multiple nodes. It also positions ZStack for organizations that want a software-defined data center without purchasing special networking hardware, according to its networking description. That does not mean that hardware requirements disappear. Physical compute, storage, hypervisor support, and network design still determine what a real deployment can provide.

## Architecture behind ZStack's API model

The repository layout separates areas such as compute, storage, network, image, identity, portal, REST, search, resource configuration, and long-running jobs. This separation is consistent with the README's claim that the core orchestration is built around an Eclipse and OSGi-like plugin system. The repository contains a plugin directory, core directory, REST-related code, and dedicated compute, network, and storage modules, so the implementation appears organized around replaceable capability components rather than a single undifferentiated application.

ZStack also documents a workflow engine that can roll back completed changes when an operation fails. A cascade framework can propagate an operation from one resource to dependent resources. These mechanisms address a difficult IaaS problem: a request may involve several dependent objects, and a failure after one object has changed can leave the environment inconsistent. The rollback mechanism is especially relevant for infrastructure operators because it changes the failure model from manual cleanup toward recovery handled by the management layer.

Networking is not described as a passive configuration added to each server. The default model uses network functions virtualization and gives each tenant a dedicated networking node implemented by a virtual appliance VM. The README says that this model is self-contained and self-managed, and that administrators do not need to buy special hardware or place networking servers in front of computing servers. This is a specific architectural choice with a corresponding dependency on virtual appliances and the surrounding management plane. It should be evaluated as part of the deployment design, not treated as a universal replacement for every data center network arrangement.

## Installing ZStack and completing a first tutorial

The README does not provide a package-manager command or a self-contained command sequence for installation. Instead, it directs users to several documentation paths based on the required environment. Those links are the authoritative starting points for the exact deployment steps:

* The Quick Installation guide is for users who want to try ZStack quickly.
* The Manual Installation guide is for a production environment.
* The Multi-node Installation guide is for a multi-node environment.
* The matching getting-started guides follow installation for Quick Installation, Manual Installation, and Multi-node Installation.

ZStack is described as being installed by deploying a Java WAR file. The README also says that a proof of concept can be installed with a bootstrap script, but it does not include the script name, command syntax, operating system requirements, Java version, database configuration, or service startup procedure. Consequently, a reader should not invent a command from the project name. Follow the selected installation guide and confirm its prerequisites before downloading or deploying the WAR.

The first real use should follow one of the linked getting-started guides. The tutorials cover an Elastic IP deployment, a flat network, and a three-tiered network. Each topic has both web UI and command line variants where the README lists them. The shortest path for evaluation is therefore not to create every network type at once, but to complete one documented tutorial in the chosen interface, then compare the resulting resources with the API and UI state before moving to another topology.

## Query APIs, CLI access, and operational boundaries

ZStack's query API is one of its most concrete differentiators in the README. The examples use expressions with nested resource fields, conditions, sorting or paging controls, and field selection. One example queries virtual machines through `vmNics.eip.guestIp` and `zone.name`. Another queries hosts with `fields=name,uuid,managementIp`, `hypervisorType=KVM`, virtual machine conditions, `start=0`, and `limit=10`. These examples show that operators can build targeted inventory queries instead of writing ad hoc scripts or querying the database directly.

The command line tool is documented alongside the web UI for at least the Elastic IP and flat network tutorials. The repository also includes `sdk`, `rest`, and `portal` directories, which supports the stated API-centered architecture. However, the README does not publish the complete CLI installation procedure, authentication setup, endpoint format, or required request payloads. Those details must come from the linked tutorials and documentation.

The platform's claims about scale need careful interpretation. The README says that one management node can manage hundreds of thousands of physical servers, millions of virtual machines, and tens of thousands of concurrent API requests. It also publishes VM creation timing figures ranging from 0.51 seconds for one VM to 23 minutes for 10,000 VMs. The README qualifies those figures with a note about a mixed environment containing nested virtualization and simulator VMs created by 100 threads using one management node. Those are project-reported figures, not a promise for a particular deployment. Hardware, storage, networking, tenant load, and the mix of real and simulated workloads can change the result substantially.

## Plugin and workflow trade-offs

The plugin system is useful when an operator wants the orchestration core to remain separate from individual features. The README explicitly gives two design principles: adding or removing features should not affect existing code, and the system should support long-term operation. The repository's separate `plugin`, `compute`, `storage`, `network`, and related directories make this modularity visible in the source organization, but they do not prove that every plugin has identical compatibility or upgrade behavior.

The workflow engine introduces another trade-off. Automatic rollback can reduce recovery work after a failed multi-resource operation, but it also makes correctness dependent on the workflow's definition of completed changes and dependency boundaries. Operators still need to understand which actions participate in a workflow, what happens when an external dependency fails, and how partially completed operations appear through the API. The README names the rollback and cascade mechanisms but does not document retry policies, operator override procedures, or failure-state inspection.

The automated testing section deserves a similarly precise reading. The README states that three automated testing systems guard every feature, but it does not identify their scope, execution frequency, hardware requirements, or relationship to a release gate. There are no GitHub releases in the repository metadata, so there is no release-based upgrade history available here. The last push was on 2026-10-17, but the repository description and README do not provide a compatibility matrix for upgrading between versions. An operator should treat upgrade testing as part of infrastructure planning rather than assume that plugin removal or replacement is consequence-free.

## ZStack versus direct component management

The main alternative described by ZStack's README is direct management of individual data center components, with operators installing, configuring, and upgrading agents on many machines and maintaining scattered configurations. Direct management can be appropriate for a small lab where only a few hosts are involved, or for an organization whose existing automation already owns the full resource lifecycle. It avoids introducing an additional IaaS control plane, but it also leaves the operator responsible for coordinating compute, storage, networking, inventory, and failure recovery.

ZStack takes a different approach. Its management nodes coordinate resources through APIs, its plugins divide orchestration into capabilities, and its workflow and cascade mechanisms address dependent operations. The CLI and web UI are intended as clients to those management nodes rather than separate configuration systems. The trade-off is that adopting ZStack means accepting a platform layer with its own deployment, plugins, networking model, and upgrade surface.

The README's Ansible integration is presented as reducing the need to install, configure, and upgrade agents on massive hardware. That can simplify fleet operations, but the README does not specify supported hypervisors, back ends, operating systems, or the exact Ansible integration contract. Those are adoption boundaries, not details that can be inferred from the existence of integration. For a platform team, the relevant comparison is whether central API orchestration and rollback justify operating a cloud control plane compared with maintaining a smaller, already automated component stack.

## Licensing and maintenance considerations

The project is licensed under Apache-2.0. The repository includes a `LICENSE` file, and the stated license permits use and modification under that license's terms, subject to its conditions. This review does not provide legal advice or interpret how the license applies to a particular deployment, distribution, or third-party component.

The repository is not archived, and the last push was on 2026-10-17. That supports treating the repository as receiving recent repository activity, but it does not establish a release cadence because the repository has no GitHub releases. The README's plugin model and Java WAR deployment make upgrade planning an infrastructure task: operators need to determine how the management nodes, plugins, network model, and client tools are upgraded together. The README does not document a migration path, version support window, or rollback procedure for upgrades, so those points require direct confirmation in the project documentation.

## Conclusion

Adopt ZStack when an organization wants an API-centered IaaS layer for compute, storage, and networking and is prepared to validate its deployment, plugin, and rollback behavior against its own infrastructure. Do not choose it solely from the README's scalability or timing claims, because those figures depend on hardware and workload conditions that the project does not define. Before adoption, verify the documented installation path for the target topology, confirm the required Java deployment environment, and test the relevant plugins and network model first.

## FAQ

### What is ZStack used for?

ZStack is an open source IaaS platform for automating data center resources, including compute, storage, and networking. Users manage those resources through APIs using a web UI or command line tool.

### How is ZStack installed?

The README says ZStack can be deployed as a Java WAR file. It links to separate Quick Installation, Manual Installation, and Multi-node Installation guides, but does not include exact installation commands or prerequisites.

### Does ZStack support multi-node deployments?

Yes. The README describes a multi-node production deployment and links to a Multi-node Installation guide and matching getting-started guide. It does not specify the hardware topology or node count required for production.

## Sources

- [Issues](https://github.com/zstackio/zstack/issues)
- [License: Apache-2.0](https://github.com/zstackio/zstack/blob/master/LICENSE)
- [README](https://github.com/zstackio/zstack/blob/master/README.md)
- [zstackio/zstack on GitHub](https://github.com/zstackio/zstack)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zstackio-zstack