Posted on October 6, 2025

OpenStack-Based Cloud Platforms: Why Vanilla Matters with c12n, Canonical, and Red Hat (RHOSP) Compared

When organisations evaluate private cloud platforms, they often encounter Canonical’s Charmed OpenStack, Red Hat OpenStack Platform (RHOSP), and Cloudification’s c12n. At their core, all three are OpenStack-based cloud platforms. OpenStack remains the world’s leading open-source Infrastructure-as-a-Service (IaaS) project, used by enterprises, telcos, and research institutions alike to build scalable private clouds.

But while they share OpenStack as a foundation, the approach each vendor takes to packaging, modifying, and supporting OpenStack is very different. The most important distinction:

c12n is 100% vanilla OpenStack – deployed using upstream source code with no proprietary forks or hidden modifications. And when we do the modifications and bugfixes – they are all public at both our GitHub and Dockerhub.
Canonical and Red Hat distribute their own modified OpenStack flavors, adding layers of vendor-specific tooling, licensing, and subscription models.

This difference may sound subtle, but it carries major implications for cost, freedom, and long-term viability.

Let’s break it down.

What Does “Vanilla OpenStack” Mean?

“Vanilla” OpenStack simply means using the upstream, community-driven codebase as published by the OpenInfra Foundation — without forking, removing features, or replacing components with vendor-specific equivalents.

With vanilla OpenStack, you get the full feature set, the latest innovation from the open-source community, and complete transparency. That is the source code that can be found in https://github.com/openstack repositories, which are effectively mirroring the Git repositories from https://opendev.org/openstack
With modified distributions, you may become dependent on that vendor for upgrades, patches, and lifecycle decisions, as well as be limited to the services and support that vendor provides

In other words: vanilla = freedom. Modified = risk of lock-in.

The Implications of Going Vanilla vs Vendor-OpenStack

Source code ownership:
- c12n (vanilla) → the code and GitOps deployment scripts remain with the client, even if Cloudification steps away. We also mirror container images into customer’s infrastructure to avoid any external dependencies. No black boxes, no vendor dependencies.
- Canonical / Red Hat (modified) → clients rely on vendor tooling (Juju Charms for Canonical; Red Hat’s certified stack for RHOSP which requires Red Hat OpenShift installation).
  
  Should the vendor discontinue, change, or license those components differently, the client is forced to follow.
Open source features:
- c12n delivers most of the features that upstream OpenStack supports and deploying latest release versions as they appear. However, c12n does not support unstable services which are not well maintained in the OpenInfra community.
- Canonical and Red Hat follow a similar approach supporting a wide, but incomplete range of services. The base, especially for RHOSP, is typically an older OpenStack release meaning it will take more time to use new features available in the latest releases.
  
  For example, the RHOSP 18 has been released in August 2024, but is based on OpenStack version 2023.1 “Antelope” released in March 2023. Thus RHOSP is about 1,5 years behind the upstream, vanilla OpenStack.
Future-proofing:
- When a vendor exits or shifts focus, modified distributions become risky. A cautionary example is SUSE OpenStack Cloud, which was discontinued despite hundreds of active customers. SUSE OpenStack users were left with expensive migrations and uncertainty.
- Companies with vendor OpenStack have to take the risk that in case of vendor priorities shift or licensing terms tightening, they might have to migrate over to either Vanilla OpenStack or another vendor.

Comparing the Platforms

Feature	c12n (Cloudification)	Canonical (Charmed OpenStack)	Red Hat OpenStack Platform (RHOSP)
OpenStack base	100% vanilla, upstream OpenStack	Modified distribution with Juju & Charms	Modified distribution tightly coupled to RHEL ecosystem
Bare-metal provisioning	MAAS, optionally with NetBox integration for advanced inventory management	MAAS	Red Hat tools, tied to certified hardware and Red Hat OpenShift
Licensing fees	Zero license fees; optional 24/7 support	Zero license fees; high installation (150k+ EUR) and support costs. Ubuntu Pro subscription for base OS is a requirement	Subscription model, license fees bound to RHEL ecosystem with per-socket pricing
Source code ownership	Client keeps full GitOps config and mirror of container images, even if Cloudification exits	Vendor-specific, albeit open source dependencies (Juju / Charms / Sunbeam)	Bound to Red Hat licensing and ecosystem; vendor owns direction
Features	All upstream features available, except for non-actively maintained OpenStack services	Features filtered through Canonical ecosystem, all core services supported	Features filtered & certified through Red Hat with delayed release cycle. Core services supported
Day-2 operations	Simplified Day-2 Ops with end-to-end GitOps, automation, monitoring and logging built on industry standard tools	Day-2 Ops tied to Canonical’s tooling (e.g. sunbeam)	Day-2 Ops tied to Red Hat lifecycle tools and ecosystem
Enterprise readiness	Can be fully managed or self-managed with optional 24/7 support. Code changes and features implemented upon request	Paid consulting and support contracts. Minimum installation on 12 baremetal servers	Enterprise support only with subscription and license fees
Risk of discontinuation	Low — community-backed upstream, no proprietary forks	Medium — open source vendor-specific tooling, where the license can change	High — potential SUSE-like risk if vendor exits or deprioritises OpenStack

What makes c12n.cloud special? Beyond Vanilla OpenStack

With c12n, you don’t just get a production-ready cloud. You get a complete, integrated private cloud platform that includes:

End-to-end observability (metrics, logging, network observability)
Logging & search via a centralized logging engine
Hardware inventory management and full bare-metal lifecycle control
Monitoring, Alerting & Dashboards across all components
State-of-the-art GitOps automation, so your configurations, versions, infrastructure changes are all declarative, version-controlled, auditable via Git PRs
Any changes to configuration have to be GPG signed to be applied providing a robust validation layer

What truly elevates c12n is the rich set of open source integrations it bundles and orchestrates. Every component is open source and free; you don’t pay a licensing fee for any piece. However, some components have paid plans allowing users to get even more advanced features should those be required. Together with extensive testing we’re performing at Cloudification, those projects create a solid, maintainable, fully production-ready cloud platform.

Let’s look what’s under the hood of c12n:

Performance and Scalability

OpenStack is built for scale. It’s the engine behind massive private clouds like those run by CERN, Walmart, and Deutsche Telekom. If you need to manage hundreds and thousands of nodes with multi-tenancy, fine-grained RBAC, advanced networking, and complex automation – OpenStack excels.

OpenNebula, while more lightweight, is optimized for smaller or edge environments. It can still scale effectively, but its simpler architecture means it’s more suited for organizations that don’t need all the features of OpenStack or would like to keep things simple.

Domain	Integrated Technologies	How c12n Leverages Them
Cloud / Core Stack		Gardener is used to provide Kubernetes-as-a-Service on top of OpenStack, enabling managed K8s clusters in your private cloud. Gardener also supports well-known hyperscalers should you be looking for running a hybrid cloud.
		Opensearch is used for centralized logging / search / audit logs across all services (OpenStack, Kubernetes, base OS logs).
		Hubble gives network visibility, flow observability and security insights in Kubernetes clusters. In particular, c12n can enable Hubble when using Cilium CNI in Gardener’s networking extension.
		Prometheus + Grafana provide monitoring, alerting, dashboarding across infrastructure, OpenStack services, and Kubernetes workloads. Alerts are commonly integrated into Slack or other messengers and on-duty tools such as OpsGenie or PagerDuty.
		OpenStack forms the solid IaaS foundation (compute, network, storage) — vanilla upstream.
Data / Storage / Messaging		OpenEBS may be optionally used for container-native storage on Kubernetes workloads (for DB and RabbitMQ PVs, etc.)
		Ceph is the default, robust, scalable storage backend (block, object, share) integrated into both OpenStack and Kubernetes.
		RabbitMQ supports messaging / queuing needs (e.g. OpenStack services, component communication). C12n deploys independent RabbitMQ clusters for all components to avoid bottlenecks and allow scaling to 100-s of nodes from the start.
		Percona (MySQL / database engines) are used for backend/stateful components (e.g. OpenStack database, metadata, component state). PXC is managed by the state of the art Kubernetes operator.
Orchestration / Control / Networking		Cilium provides advanced CNI for Kubernetes, network policy, flow-level visibility, and secure networking.
		Helm is used to package and manage internal services, charts, versioning for many components in a modular way.
		Argo (ArgoCD / Argo workflows) is central to the GitOps automation: from GPG-signed config changes to deployments, rollouts, upgrade pipelines, drift detection, rollback, etc
		Kubernetes is the core element deployed on bare metal. It manages OpenStack API services, control plane components, and all tools. The user Kubernetes clusters (KaaS) run on K8s clusters provisioned via Gardener.
Bare Metal / Infrastructure Lifecycle		Ansible is used to drive initial OS configuration and tasks such as NTP configuration or base OS user and keys creation.
		MAAS (Metal-as-a-Service) handles bare-metal provisioning, hardware testing and inventory, commissioning, decommissioning, power cycling, etc. This gives the control layer for bringing hardware into the cloud automatically
		Ubuntu is typically the OS base for all bare metal nodes in the cluster. With c12n we are flexible in terms of base OS selection.

Why Organisations Choose c12n

What makes c12n different comes down to freedom, cost transparency, and long-term security:

No license fees – you only pay for the services you actually need, not for software licenses.
Optional 24/7 support – premium SLA-backed support is available, but you’re in control of whether and when to use it with a minimum commitment of only 3 months.
You own the code and configs – it stays with your Git repositories, always. Even if Cloudification is no longer involved, your cloud keeps running.
No vendor lock-in – built on upstream OpenStack and latest industry standards, c12n avoids the risks of proprietary tooling or vendor roadmaps.
Day-2 Ops simplified – integrated observability, monitoring, and automation reduce the burden of running the cloud day-to-day. Scaling or updating your cloud has never been easier thanks to GitOps automation.
Enterprise ready, end-to-end automation – from bare-metal provisioning with MAAS to full-stack deployment, scaling, and operations.
Vanilla OpenStack, enterprise ready – no forks, no hidden tools, just the upstream platform hardened for enterprise use.
Future-proof – by sticking to vanilla OpenStack, you’re aligned with the global open source community, not dependent on a single vendor’s roadmap and business decisions.

Together, these factors mean c12n provides all the power of OpenStack with greater independence and lower TCO compared to solutions from long standing OpenStack vendors such as Canonical or Red Hat.

When to Choose What

Every organisation has different priorities, and the choice between c12n.cloud, Canonical, and Red Hat often comes down to context:

When to Choose c12n (Vanilla OpenStack)

You want 100% open source with no hidden modifications.
You value ownership of code and configuration, even if the vendor relationship ends.
You need to avoid license fees and prefer predictable, transparent costs.
You want simplified Day-2 operations (GitOps, observability, automation) out of the box.
You need an end-to-end private cloud solution that’s enterprise ready but still gives you enough flexibility.

When to Choose Canonical (Charmed OpenStack)

You are already heavily invested in Ubuntu/Juju ecosystems and want to extend that stack.
You already pay for Ubuntu Pro subscription.
You’re prepared for higher up-front costs (installation starts from 150k EUR) and support fees.

When to Choose Red Hat OpenStack Platform (RHOSP)

You are an enterprise already deeply committed to the Red Hat ecosystem.
You have strict compliance or certification requirements tied to RHEL-certified hardware.
You are willing to accept subscription-based licensing costs for vendor-backed SLAs.
You prefer deep integration with other Red Hat products (such as OpenShift).

⚠️ Keep in mind: choosing vendor-modified OpenStack comes with lock-in risks and the potential for discontinuation, as the case of SUSE OpenStack Cloud showed in the past. Vanilla solutions like c12n remain community-aligned and future-proof.

Our Take at Cloudification

All three platforms — c12n, Canonical, and Red Hat — are OpenStack-based. The real difference lies in whether you want vanilla OpenStack (c12n) or a vendor-modified OpenStack (Canonical/Red Hat).

For organisations evaluating their next private cloud platform, the question isn’t whether to adopt OpenStack — it’s whether to trust a vendor-solution, or to stay with vanilla OpenStack adapted for enterprise use.

👉 Ready to see how c12n can simplify your private cloud journey? Get in touch with our team to schedule a consultation or demo.