What is an Open Source Cloud Management Platform?

A platform in this category typically takes responsibility for:

• A service catalogue - what is offered, to whom, at what price or quota.
• User and project lifecycle - sign-up, approval, allocation, off-boarding.
• Workload lifecycle - create, start, stop, resize and delete across backends.
• Metering and cost visibility - what was consumed, by whom, for how long.
• Backend connectors - the adapters that speak to each cloud it operates.

That last point is the strategic one: connectors are what let one control plane sit above OpenStack, Kubernetes, VMware, bare metal and public cloud accounts at the same time.

The two terms are easy to confuse. An open source cloud platform is the infrastructure software you run to have a cloud - compute, storage and networking APIs on hardware you control. A management platform sits above clouds, whatever runs them, and handles the commercial and operational layer: catalogue, users, lifecycle and billing. A provider often runs both - the platform underneath, the management layer facing tenants.

Management platforms see your credentials, your users and your billing rules. Open source lets an operator verify what the software does with that access, host it inside their own boundary, and extend it when a backend or a business rule is not on anyone's roadmap. For a marketplace - where the operator is not a single trusted vendor but a network of participants - that auditability is not a preference, it is part of the trust model.

Every management platform in this category is built around a small set of recurring objects: a catalogue of offerings, orders that request them, the resources those orders create, and the accounting that follows those resources over their life. Waldur names them explicitly - offerings, orders, resources and accounting - because the shared vocabulary is what keeps a multi-tenant control plane legible to everyone reading it.

The point of naming them is that each object keeps a stable identity across systems: an order that becomes a resource can be followed through provisioning, usage and settlement without translating between three private schemas along the way.

• Offerings - what a provider publishes: the service, its plan and its terms.
• Orders - requests for an offering, routed through approvals when a project requires them.
• Resources - the live things an order produces, tracked until they are released.
• Accounting - the record of what each resource consumed, for chargeback or review.

That sequence is deliberately the same shape for a virtual machine, an HPC project or a SaaS entitlement: one lifecycle, many fulfilment backends.

A control plane is honest about its boundary. It schedules and records, but it does not make backends healthy: an API that provisions capacity depends on the capacity actually existing underneath, and no catalogue changes that. Operators evaluate the software and the infrastructure separately for exactly this reason.

The boundary runs the other way too. The platform holds credentials and policy, so the responsibility attached to it is proportionate - who may approve what, which backends are reachable, and how every action is recorded. On VirtEngine that record is not only internal: the chain keeps the settlement-relevant parts of the lifecycle verifiable by both sides rather than by the platform's own say-so.

VirtEngine uses Waldur as its primary marketplace and service-management integration: the open control plane where providers publish offerings and tenants consume services, connected to the chain through the provider daemon. Management-level actions become durable commands the adapter executes in Waldur, and their results flow back as chain state - so an open management platform is not a competitor to the marketplace, it is the surface the marketplace is exposed through.