Cloudpods: a unified cloud platform for KVM, vSphere, baremetal and multi-cloud accounts

What Cloudpods solves, and who it is actually for

The README describes Cloudpods as "a cloud on clouds": a platform that manages on-premise KVM and baremetal alongside resources from many cloud accounts, hides the differences between providers, and exposes one set of APIs over all of them. That is the whole pitch, and it is a specific one. If you have three AWS accounts, an Azure subscription and a vSphere cluster, the value is not virtualization. It is that a single control plane and a single API vocabulary cover all of them.

The README lists the intended audience explicitly. It names people who want to virtualize a few physical servers into a private cloud, people who need automatic baremetal lifecycle management, people who want to turn a vSphere cluster into a private cloud, and people who need one portal across multiple public cloud accounts. It also names a group that is easy to miss: anyone currently on a single cloud account who does not want to lose the option of going multi-cloud later. That last case is the strongest fit, because the cost of adopting Cloudpods is mostly paid up front, and it buys optionality rather than an immediate feature.

The breadth is the differentiator and also the burden. The supported provider list runs from AWS, Azure and GCP through Alibaba Cloud, Huawei Cloud, Tencent Cloud, UCloud, Ctyun, ECloud, JDCloud, Volcengine, Baidu Cloud, Kingsoft Cloud, QingCloud, Oracle Cloud and China Unicom Cloud, plus private clouds such as OpenStack, ZStack, Nutanix and BingoCloud. Each of those is a separate driver with separate quirks. Treat the list as a claim about coverage, not as a promise that every resource type behaves identically on every provider.

The mechanism: one API in front of many provider drivers

Cloudpods is written in Go, and the module name in go.mod is yunion.io/x/onecloud, which is worth knowing because it appears in import paths and build flags. The dependency list shows the shape of the system: provider SDKs such as github.com/aws/aws-sdk-go-v2 and github.com/aliyun/alibaba-cloud-sdk-go sit next to containerd, coredns, go-iptables and cadvisor. That mix tells you this is not a thin API proxy. It includes container runtime plumbing, DNS, network filtering and host metrics, which is what you would expect from a platform that provisions and runs workloads rather than only cataloguing them.

The data flow implied by the repository layout is a service-oriented one. The cmd/ directory holds binaries, pkg/ holds the implementation, and the README points to a Swagger API document as the programmatic interface. Resources are modelled as first-class objects: servers, disks, network interfaces, VPCs, load balancers, object storage buckets, NAS file systems, RDS instances, elastic cache and DNS zones. Each of those has a lifecycle that the platform tracks, and the provider drivers translate operations into the native API calls of whichever backend owns the resource.

The AI Cloud part follows the same pattern. Inference instances for Ollama, vLLM and SGLang are managed with GPU scheduling and model mounting, and AI container applications such as OpenClaw, Dify, ComfyUI and Hermes Agent are deployed through templates and images. The README says GPU devices are detected and registered automatically, with a unified NVIDIA/CUDA environment. Whether that detection is reliable across heterogeneous hosts is exactly the kind of thing you would need to verify on your own hardware; the README states the capability without describing the failure cases.

Installation and a first real use

The README does not give install commands. It says to refer to the Getting Started document on the project site and to select the appropriate scenario for installation, which implies the steps differ by deployment shape (all-in-one, private cloud, multi-cloud). Because those steps are not in the repository, this section covers what the repository itself tells you about building from source, which is enough to confirm the toolchain.

The Makefile sets the build output under _output/bin and drives builds through build/build.sh. It injects version metadata into the yunion.io/x/pkg/util/version package via linker flags, including gitVersion, gitCommit, gitBranch, buildDate and gitTreeState. Reading that list is useful: it means a binary can report exactly which commit it came from, and a build with uncommitted changes is marked dirty.

The Makefile defines the build command as follows, with GO_BUILD_FLAGS adding -mod vendor and the linker flags:

GO_BUILD := go build $(GO_BUILD_FLAGS)

That variable is what the build script uses to produce the binaries. The Makefile also exports GOOS as linux by default and sets GO111MODULE to on, so a Linux build environment is the expected path, and the repository ships a vendor/ directory for the -mod vendor flag to consume.

What you should see after a build is a set of binaries in _output/bin. What you will not find in the README is a description of what to run next, which ports the services listen on, or how the components are wired together. That information lives in the website documentation, not in the repository. If you are evaluating Cloudpods rather than deploying it, the honest first step is to read the Getting Started scenarios and the Swagger API page before building anything.

Where Cloudpods is the wrong tool

The clearest limitation is documentation depth in the repository itself. The README is a feature inventory and a set of links. Install steps, upgrade steps and rollback are all deferred to the website. The README does not document rollback at all. For a platform that manages baremetal lifecycle and cloud account credentials, that is a meaningful gap: the components that touch hardware and credentials are the ones where a bad upgrade hurts most, and the repository gives you no procedure to fall back on.

Second, the vendor directory and the dependency surface mean the build is not lightweight. You are compiling containerd, coredns, cadvisor and a long list of provider SDKs. Teams that expect a small binary they can drop on a host will be surprised. The Makefile's -mod vendor flag also means dependency updates arrive with the repository rather than through your own module resolution, which is a deliberate trade-off: reproducible builds in exchange for control over when you pick up a fix.

Third, consider the scope mismatch. If you run one cloud account and one region, Cloudpods is a large amount of machinery for a problem you may not have. The README itself frames the single-account case as a hedge against future multi-cloud needs, not as an immediate benefit. If you only need to virtualize a handful of servers, the KVM path is the relevant part, and the rest of the provider drivers are weight you carry without using.

OpenStack and Cloudpods compared as control planes

OpenStack is the obvious alternative, and the difference is architectural rather than feature-by-feature. OpenStack is a collection of independent services (Nova, Neutron, Cinder, Glance and others) that you assemble into a cloud, with each service owning its own API and database. Cloudpods is a single Go codebase with one API surface that fronts many providers, including OpenStack itself, which appears in the README's private cloud list.

That distinction matters for operations. With OpenStack you are building and running the cloud; the provider abstraction for external clouds is not the point, and multi-cloud management is a separate concern. With Cloudpods you are managing clouds that already exist, whether they are public accounts or a vSphere cluster, and the abstraction is the product. The README's positioning as "a cloud on clouds" is accurate on this axis.

The trade-off is depth versus breadth. A dedicated OpenStack deployment gives you control over every service and its upgrade path. Cloudpods gives you one API over many backends, but the behaviour of any individual resource depends on the driver for that provider, and the README does not document per-driver differences. If your requirement is deep control over one private cloud, OpenStack is the more direct fit. If your requirement is one view over several clouds you do not want to rebuild, Cloudpods is aimed at exactly that.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-15, so the codebase is being changed. The README also points to a Changelog and Release Notes on the project site, which is where version history lives. Note that no releases were retrieved for this review, so the release cadence and the version you would actually deploy are things to check on the project site rather than assume.

The licence is Apache License 2.0, stated in the README and present as a LICENSE file at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant and requires that you retain notices and state changes. It does not impose copyleft obligations on your own code. That is a summary of the licence text, not legal advice; if you are embedding Cloudpods in a product, have your own counsel read the LICENSE file.

Upgrade cost is the weakest documented area. The README offers no upgrade procedure, no rollback procedure and no compatibility statement about version-to-version changes. The build metadata injected by the Makefile (gitVersion, gitCommit, buildDate, gitTreeState) at least lets you identify precisely what is running, which is a prerequisite for any upgrade discipline. Beyond that, plan on reading the Release Notes and Changelog pages before moving a production deployment, and treat the absence of a documented rollback path as a risk you are accepting rather than one the project has addressed.

Editorial conclusion

Adopt Cloudpods if you are consolidating several cloud accounts or virtualizing a few physical servers and want a single API and portal over both. Skip it if you need a small, single-provider wrapper, or if you cannot accept that the README points to the website for install steps and does not document an upgrade or rollback path. Before deploying, open the Getting Started page, pick the scenario that matches your hardware, and confirm the release notes for the version you intend to run.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. yunionio/cloudpods on GitHub