Beyond Horizon: OpenStack Dashboard and Billing Integrations for Real-World Clouds in 2026
From Internal Chargeback to Commercial Cloud Services: Why Billing and Usage Visibility Matter
When organizations first evaluate OpenStack, the discussion often revolves around hypervisors, storage backends, networking models, or Kubernetes integration. The platform is approached primarily as an infrastructure replacement, a way to move beyond traditional virtualization and gain automation and flexibility.
However, once the platform is deployed and end-users begin to use it, a different set of needs quickly emerges. We need to know what is being used, for how long, and perhaps most importantly, we need to keep the platform sustainable as adoption grows over time.
Unlike traditional virtualization environments, a cloud platform enables self-service via APIs. Developers, researchers, admins and business units can provision infrastructure independently and almost instantly. This is exactly what makes a cloud valuable, but it also removes some of the controls that previously limited resource consumption.
For this reason, dashboards and billing integrations are not merely convenience features. They are operational tools and the primary interface between users and the cloud. They are expected to cover three main areas:
- Day-to-day resource management (VM, Volume, Network provisioning, etc)
- Visibility into usage and consumption
- Cost transparency, billing, or chargeback
At Cloudification, we work with organizations across the spectrum – from enterprises managing internal resource allocation to service providers building commercial (public) cloud offerings. And while OpenStack offers solid building blocks in this area, the reality is that no single OpenStack upstream component provides a complete, end-to-end dashboard and billing solution. This gap has led to a diverse ecosystem of dashboards, rating engines, and third-party billing platforms; each solving part of the problem.
In this article, we examine how these pieces fit together, when the native OpenStack services are sufficient, and when additional 3rd party components become necessary, particularly in private cloud environments such as c12n.
Understanding the Different Needs and Use Cases
The moment infrastructure becomes self-service, cost responsibility moves away from IT and toward the users of the platform. While a traditional virtualization environment behaves like a shared pool, a cloud behaves like a utility.
Once users can create instances on demand, three questions immediately appear:
- Who created these resources?
- How long are they running?
- Who pays for them?
OpenStack itself does not enforce a financial model or billing. It exposes projects, quotas, and partial usage data — but what organizations do with that information depends on their operational model.
We typically see three very different usage patterns.
1. Enterprise Private Cloud — Internal Chargeback & Capacity Planning
In large enterprises, the cloud is not sold externally. Instead, multiple internal departments share available cloud resources for:
- Dev teams
- Non-technical teams
- QA, UAT, PROD environments
- Subsidiaries and sister companies
Here, billing is not about invoices or credit cards; it is about accountability, and finance departments want to understand:
- Why does the marketing department use more storage than engineering?
- Why do development environments run 24/7?
- Why does a POC project consume GPU capacity for 6 months?
- And so on…
Without metering and visibility, the cloud becomes a black hole of resources. It becomes hard to plan hardware procurement, and management cannot understand real operational costs per unit of resource. In these environments, billing tools are used primarily for:
- Internal budgeting (“showback” or “chargeback”)
- Capacity forecasting
- Preventing resource sprawl
- Justifying infrastructure expansion
For this use case, the official OpenStack projects such as Ceilometer & CloudKitty are often sufficient, even when real invoicing and payments do not take place.
2. Research, Universities, or Public Sector — Quotas and Grants
Another very common OpenStack user group is research organizations and universities. Here, usage is often tied to:
- Limited project funding and thus hardware available
- HPC or GPU allocation for long running simulations and tasks
- Slow procurement of new hardware and possible resource crunches
The platform operators are not charging money, but they must track consumption precisely because resources are allocated based on funding or project approval.
In these environments, billing becomes allocation accounting und metering rather than financial billing. For example, a project might receive 200 vCPUs, 20 TB storage for 3 months runtime. After that, the project must request an extension or give up the resources.
Again, usage tracking is important, but payment integration is not. For such cases OpenStack Ceilometer and CloudKitty together with the standard Horizon dashboard will typically do the job.
3. Cloud Service Providers & Managed Cloud — Lots of Customers
This scenario is completely different: the cloud is a product itself.
Hosting providers, cloud providers, MSPs, and some integrators sell OpenStack capacity to their customers. Now the platform must behave more like AWS, Azure, or a VPS provider.
So users expect:
- A web-based customer portal
- Pricing per hour or even minute
- Automated invoicing at the end of billing cycle
- Various payment methods (cards, bank transfer, PayPal)
- Balance tracking and upfront charging
This is the tipping point where native OpenStack components are no longer enough. OpenStack was designed as an IaaS platform and not an e-commerce platform. This is exactly why a separate ecosystem of commercial dashboards has appeared around OpenStack over the past years.
Let’s take a look at the options we have!
The Core OpenStack Toolkit: Open Source Components with Powerful Foundations and Commercial Limitations
License: Open source (Apache 2.0)
Cost: Free
Horizon has been the default OpenStack dashboard for over a decade. It is based on the popular Python Django framework and provides a broad service coverage and tight integration with OpenStack APIs. For administrators and power users, it remains a reliable tool for managing projects, users, quotas, and resources.
That said, Horizon clearly reflects its age. The UI feels very dated, customization is limited, and there are bugs that have been around since years. More importantly, Horizon does not include billing or payment functionality, and only offers very limited visibility into usage metrics.
Horizon works well as an administrative and provisioning interface, but it was never designed to be a customer-facing billing portal. It also doesn’t provide 100% coverage of the APIs so do expect to use OpenStack CLI for some actions that are impossible to do via Horizon.
Furthermore, Horizon supports themes and branding natively. You can override colors, images, logos, templates, and even inject custom CSS or JavaScript by defining your own theme and configuring it in local_settings.py. This allows you to:
- Replace the default OpenStack logos
- Add your own organization’s logo on the login screen and header
- Change color palettes, fonts, and layout styles
- Customize text like site title or footer
Theming in Horizon is flexible because it is built on a theme directory structure that can override static assets and templates. Detailed instructions can be found in the official docs.
License: Open source (Apache 2.0)
Cost: Free
Skyline is a much newer project that was introduced to address Horizon’s usability and design limitations. Built with a modern stack based on ReactJS and Python FastAPI, Skyline offers a cleaner UI and a more responsive user experience.
However, Skyline currently supports only a subset of OpenStack services. Even today, it does not fully replace Horizon, and like Horizon, it does not attempt to solve billing or chargeback topics. In practice, some companies run Skyline alongside Horizon rather than instead of it.
As of today, Skyline can be viewed as a UI modernization effort, not a complete dashboard solution or a replacement of Horizon. With that being said, there are several contributors that have stepped up the efforts over the past release cycles and we hope that Skyline will be able to match Horizon feature-wise very soon.
Skyline’s dashboard also supports custom UI themes as of the 2024.1 release of Skyline. You can configure a custom theme in its configuration file (config.yaml oder local_config.yaml) to replace the default look with your own color scheme and appearance. Skylines docs state:
- Theme setting in the config (e.g., theme: custom)
- Default and custom theme options
- Color and visual adjustments
You can find more information here. This means Skyline can now be visually aligned with your branding, much like Horizon, making it more suitable for end-customer portals.
License: Open source
Cost: Free
Ceilometer was introduced when operators realized a serious gap: OpenStack could allocate resources, but could not measure them historically. This is where OpenStack Ceilometer was born to fill the gap.
Ceilometer collects metrics such as:
- Instance runtime
- CPU usage
- Network traffic
- Storage consumption
With those metrics Ceilometer helps to answer the question: “What happened in the particular OpenStack project?”. However, it does not interpret those numbers or does actual billing.
License: Open-source software released under the Apache License 2.0.
Cost: Free
Ceilometer was good at collecting metrics, but it was never designed to store massive amounts of time-series data efficiently. Larger clouds (30+ servers and 1000+ VMs) generate an enormous number of measurements, and storing raw telemetry in traditional SQL databases (as Ceilometer did) became slow, inefficient, and difficult to query.
This is where Gnocchi came in!
Gnocchi is a purpose-built time-series database and resource indexer created specifically for OpenStack telemetry workloads. Instead of treating metrics like generic database records, Gnocchi treats them as what they actually are: continuously arriving metrics over time.
Gnocchi:
- Stores metrics in an aggregated and compressed format
- Indexes OpenStack resources (instances, volumes, networks)
- Allows efficient long-term retention of historical measurements
- Enables fast queries across very large cloud environments
Instead of only knowing an instant VM CPU usage at a specific moment, operators can now know what the average CPU usage of a project was during the previous month, which tenants constantly overuse storage, when network traffic spiked, etc. While Ceilometer is what made telemetry possible, Gnocchi made it usable and efficient at scale.
License: Open source
Cost: Free
CloudKitty was created specifically to add meaning to Ceilometer data. On top of raw usage metrics, CloudKitty applies rating rules. For example:
- 1 vCPU hour = € 0.10
- 1 GB storage hour = € 0.05
- 1 GB outbound traffic = € 0.01
CloudKitty therefore answers: “What would this usage cost?” However, it deliberately stops there.
That means CloudKitty does not generate invoices, collect payments, handle taxes, or notify customers. This design was intentional — OpenStack avoided embedding financial systems into infrastructure software.
These three are often used together. Ceilometer collects usage metrics (on its own, it only provides raw data), typically storing them in Gnocchi, which handles the historical time-series storage. CloudKitty builds on top of this by applying rating rules to those metrics. It can calculate costs based on predefined formulas and pricing rules (e.g. tiered, volume or customer- based discounts) and store rated data for later processing.
This combination is powerful but incomplete:
- Ceilometer answers “what was used?”
- Gnocchi answers: “how did usage evolve over time?”
- CloudKitty answers “how much would that usage cost?”
Yet neither answers “how do we invoice or charge the customer?”
The Core OpenStack Toolkit: Open Source Components with Powerful Foundations and Commercial Limitations
| Component | Purpose | UI | Billing / Payments |
|---|---|---|---|
|
Horizon |
Cloud Resource management, |
Yes |
No |
|
Skyline |
Modern web UI alternative for Horizon |
Yes |
No |
|
Ceilometer |
Usage measurement |
No |
No |
|
Gnocchi |
Metric storage & time-series aggregation |
No |
No |
|
CloudKitty |
Cost calculation, rating |
Via Horizon plugin |
No |
Those services together provide showback und chargeback, but not the commercial billing.
Commercial & Third-Party Solutions
Because of these limitations, many organizations turn to third-party solutions when OpenStack is used as the backend for commercial or public cloud offerings.
Type: Proprietary
Cost: Subscription (usually per node or per tenant; pricing not public)
OSIE is a proprietary OpenStack dashboard and billing system designed specifically for Public-Cloud-Anbieter. It appeared several years ago and was created specifically for companies who wanted to offer OpenStack as a public or hosted cloud. OSIE is actively developed with regular releases and support for all latest OpenStack versions. The changelog can be found here.
OSIE features include:
- Modern customer-facing UI
- Configurable pricing per resource unit
- Integrated payment providers (including different currencies, credit cards, etc.)
- Balance, credit, and invoice handling
- Discounts and promotional credits
- Automatic suspension of users, KYC handling via iDenfy
Unification of multiple independent OpenStack installations as regions under one OSIE interface
Type: Proprietary
Cost: Licenses with different modules (few thousand € upfront + yearly support fees)
HostBill is a long-standing solution that comes from the hosting industry and integrates OpenStack as one of many supported platforms. It focuses heavily on:
- Billing automation
- Invoicing and payments (integration with Stripe and other providers)
- Selling cloud resources alongside traditional hosting services
- Support of various IaaS providers including OpenStack, VMware, Proxmox and CloudStack
HostBill is strong when OpenStack is only part of a bigger hosting business, such as selling VPS, domains, backups, or email hosting. Its strength is billing automation, not infrastructure awareness.
The OpenStack integration is less “native” compared to OSIE, but HostBill might be an interesting option for hosting providers that either have a broad range of IaaS or want to sell additional packages (e.g. domains and backups).
Type: Proprietary
Cost: Subscription licensing (hundreds €/month depending on number of hypervisors and features; public cloud pricing tiers depend on deployment size)
Fleio is built specifically for OpenStack and it provides a billing and customer portal in one. Similar to OSIE, Fleio was created around OpenStack itself and integrates directly with OpenStack services and concepts (projects, flavors, volumes, floating IPs, images, etc.).
Fleio includes:
- a customer self-service cloud panel
- usage-based billing
- prepaid and postpaid billing models
- invoices and balance tracking
- credit limits and suspension policies
- integration with payment gateways (e.g. Stripe, PayPal)
- pricing per hour, per month, or per resource unit
Unlike CloudKitty, Fleio does not just rate usage. It performs the full commercial lifecycle from resource creation to invoicing and payment.
Technically, Fleio collects usage data from OpenStack (often using telemetry data) and translates it directly into billable items. Because it understands OpenStack resource types natively, operators do not need to manually map infrastructure metrics into customer products.
Fleio is often used by managed private cloud providers, regional cloud providers, and companies offering OpenStack-based IaaS to customers. It acts as the business layer on top of OpenStack, sitting above the infrastructure stack and below the customer.
Type: Proprietary
Cost: Annual license for WHMCS + paid module for OpenStack integration (module pricing varies; typically a few hundred euros per year depending on provider)
WHMCS (Web Host Manager Complete Solution) is a long-standing billing and automation platform in the web hosting industry. For many years it has been the de facto standard for small and medium-sized hosting providers because it combines domain billing, support ticketing, product provisioning, and customer management in a single suite.
Out of the box, WHMCS does not know anything about OpenStack, it is agnostic by design. However, commercial modules such as OpenStack VPS Cloud for WHMCS extend WHMCS to provision and bill OpenStack resources. These modules typically allow:
- VM provisioning via the OpenStack API
Resource pricing per flavor, image, network, or floating IP - Automated invoice generation
- Payment gateway integration (Stripe, PayPal, etc.)
- Customer self-service
Because WHMCS was designed for general hosting, its OpenStack integration is less native than Fleio or OSIE. The module acts as an adapter: it translates WHMCS service definitions into OpenStack API calls. This works well for simple VPS setups, especially for providers that already use WHMCS for other products (domains, shared hosting, etc.).
WHMCS can be a very cost-effective entry point for providers who already use WHMCS in their stack and want to expose OpenStack VMs as products alongside traditional hosting, or do not need deep multi-tenancy awareness.
However, because WHMCS was not originally designed for OpenStack’s multi-tenant IaaS model and broader cloud ecosystem, there are limitations around representation of projects and users, complex pricing rules, nested resources (e.g., quota, volume billing) and telemetry integration beyond basic usage.
Table of Comparison for Commercial Solutions
OSIE, HostBill and Fleio all provide a customer portal and billing layer on top of OpenStack, but each takes a different approach. Fleio stays closer to OpenStack concepts, making it feel more like a cloud control panel for OpenStack environments. OSIE, with its rich features, focuses on end-to-end setup (KYC, multi-region support, invoicing, etc.) for selling cloud resources as products and plans, suiting providers who prefer to sell predefined services and easily integrate their OpenStack deployments. HostBill, by contrast, comes from the broader hosting world and is designed for multi-service environments with not just OpenStack. Hostbill automates invoicing and payments across cloud, VPS, and domain offerings, and is less focused on exposing OpenStack features directly.
Choosing between them depends on whether a cloud operator wants customers to interact with infrastructure capabilities, consume ready services, or manage a mixed environment hosting business.
| Component | Purpose | UI | Billing / Payments | OpenStack Integration |
|---|---|---|---|---|
|
OSIE |
Cloud Resource management, |
Yes with both provider and customer dashboard and customization options |
Yes |
Strong |
|
HostBill |
Billing automation, invoicing, payment and multi-service hosting integration |
Yes, but limited cloud features with the focus on the VPS hosting and billing |
Yes |
Moderate |
|
Fleio |
Usage-based billing, invoices, customer accounts, payment integration, cloud self-service panel |
Yes with support for main OpenStack services |
Yes |
Strong |
|
WHMCS |
Billing automation, subscriptions, payment gateways, hosting customer management |
Limited cloud UI (billing-centric portal) |
Yes |
Moderate |
Putting It Together: Choosing the Right Model
In practice, the decision depends a lot on the business model or the use-case of the OpenStack cloud.
| Use Case | Recommended Approach |
|---|---|
|
Private cloud in enterprise |
Horizon/Skyline + Ceilometer + Gnocchi + CloudKitty |
|
Internal cloud for research or non-profit scenarios |
ModeraHorizon/Skyline + Ceilometer + Gnocchi + CloudKittyte |
|
Managed private cloud for external customers |
OSIE or Fleio |
|
Public IaaS provider with multiple regions |
OSIE |
|
Traditional hosting provider adding OpenStack to their other IaaS |
HostBill or WHMCS |
There is no universal answer, and the “right” solution depends heavily on how OpenStack is used:
- Internal private clouds: Horizon or Skyline combined with Ceilometer, Gnocchi, and CloudKitty can often be sufficient. It might not be the prettiest UI, but will do the showback or chargeback providing deep integration with OpenStack.
- Cloud service providers and hosting: Third-party platforms like OSIE, Fleio, HostBill or WHMCS are usually unavoidable, as they handle invoicing, payments, and customer lifecycle management.
- Large public cloud providers: at no surprise, big OpenStack based providers such as OVH, Open Telekom Cloud or StackIT have a completely custom, own dashboard and billing solutions developed internally to provide best possible integration and UX for their offerings.
At Cloudification, we see this pattern repeatedly: OpenStack excels as an infrastructure platform, but billing is an open topic where the answer depends on the need.
Why This Matters for Cloud Adoption
In many discussions about cloud platforms, dashboards and billing are treated as secondary features, something to consider after the infrastructure is running. In practice, we repeatedly observe the opposite during c12n private cloud deployments: the moment a platform becomes production, questions about usage ownership and cost transparency appear very often.
In old, traditional virtualization environments, infrastructure is centrally controlled by few admins. Virtual machines are requested through tickets, administrators create them manually, and resource consumption grows slowly and visibly. In a cloud platform, especially if public, the resources can be provisioned instantly and independently by multiple teams or customers.
Without visibility, new challenges will quickly become a part of Day-2 cloud operations:
- Test or dev environments are often forgotten and never deleted
- Temporary projects silently become permanent workloads
- Capacity planning becomes reactive
For this reason, one of the most important early design decisions in an OpenStack deployment is not only how users access the cloud, but also how they understand the impact of using it.
In enterprise environments, this rarely means charging departments real money. Instead, organizations implement showback or internal chargeback models. Departments receive monthly usage reports that translate resource consumption into understandable cost units. The goal is not profit but accountability and planning. Being aware of the impact of keeping unused instances or oversized volumes leads to behavior changes that can improve sustainability.
This is also why we typically combine native OpenStack components rather than immediately introducing commercial billing portals. Ceilometer, Gnocchi, and CloudKitty allow organizations to build transparency first, while Horizon or Skyline remain the operational interface. Only when the cloud is offered as a managed service to external customers does a full customer-lifecycle and payment integration become necessary.
At Cloudification, we help design sustainable operating models around c12n.cloud, combining dashboards, usage tracking, and billing to ensure transparency, accountability, and capacity planning.
Want to know how c12n can be tailored to your organization’s operational needs? Give us a call!
