OSIE vs. CloudKitty: OpenStack Chargeback and Billing Compared

Running a cloud business on OpenStack means assembling several systems before you can bill a customer.

Ceilometer measures resource usage, Gnocchi stores it, and CloudKitty applies the prices you define to what each project uses. At the end of that chain, you have a priced figure for each project.

A customer, however, needs more than a number. They need an invoice for their usage, with their country’s tax, in a form their finance team can pay. CloudKitty does not generate invoices. It leaves taxes and currency conversion to billing software.

OSIE is a billing platform built for OpenStack. It prices what each customer uses with price plans you define, issues the invoice with country-specific tax rules, and collects payment. 

This blog compares what OSIE and CloudKitty each do, from pricing to payment.

CloudKitty and OSIE: An Overview

In this section, let’s look at each tool at a high level. A few OpenStack services work alongside CloudKitty to rate resource usage on OpenStack. We’ll refer to those services as the CloudKitty stack

The CloudKitty stack

CloudKitty is OpenStack’s rating project. It does not measure usage itself.

Ceilometer measures what each project uses, Gnocchi stores the measurements, and CloudKitty reads them, applies the prices you define, and stores the result as rated data for each project. In our test, InfluxDB stores the rated data.

For a closer look at what CloudKitty gives you and what it doesn’t, read our deep dive: Chargeback on OpenStack: What CloudKitty Gives You, and What It Doesn’t.

OSIE

OSIE is a billing platform built for OpenStack. It has three parts: an API, a client portal for customers and an admin portal for the provider.

A billing job applies price plans to each resource and adds the charges to an open bill, one for each billing profile and billing cycle.

The bill becomes an invoice with tax rules applied, and OSIE collects payment through account credits or a payment gateway.

The rest of the blog compares how the two tools handle pricing, and the jobs that come after it.

OSIE and CloudKitty: A Side-by-Side Comparison

This section starts with the terms you’ll come across in this post, for readers who are new to the OpenStack ecosystem or to CloudKitty.

It then compares the two tools side by side, grouped by what both do, what each does in part, and what only OSIE does.

Terms You’ll See

Term	OSIE	CloudKitty stack
What gets priced	Resource type, with several attributes	Service, which is one metric
Where a price lives	A rule inside a price plan	A mapping inside a rating module
Condition on a price	Filter or modifier	Field
Charge for existing	existence, always 1 while the resource exists	NUMBOOL mutation, which turns a metric into 1
Kind of quantity	Gauge (adds each run) or counter (overwrites each run)	No equivalent term
Who pays	Billing profile, with an open bill	No payer, only rated data per project
Price that changes with quantity	Tier: a range of the quantity with its own amount	Threshold: a level at which the price changes

What OSIE and CloudKitty Both Do

This section covers features and capabilities present in both OSIE and CloudKitty

	OSIE	CloudKitty stack
Collecting for pricing	A billing job rates each resource from OSIE’s stored copy of it, and fetches nothing from the cloud while it does. A separate job collects traffic counters every 15 minutes.	The CloudKitty processor reads Gnocchi (or Prometheus) every hour, for each project, and rates it.
What is metered	The project. Every project is billed to its organization’s billing profile.	The scope, a project
The pricing rule	A price plan rule: an attribute times an amount, with a frequency and a charge description.	A hashmap mapping: a price on a service or a field.
Charging for existence	The existence attribute, always 1 while the resource exists.	A NUMBOOL mutation that counts a metric as 1.
Units	Set per attribute: volume size in GB, bucket size in bytes.	The unit in metrics.yml is a label. A factor does the conversion.
The cost dashboard	Six widgets in the project dashboard.	The same six widgets on the Horizon Rating dashboard.

Charging for existence

Some resources are billed simply for being there, like a running instance. OSIE does this with an attribute called existence.

It is always 1 while the resource is in the customer’s account, so a price on it charges its amount every run.

CloudKitty gets the same result from a mutation. In metrics.yml, mutate: NUMBOOL counts a metric as 1. We tested this for the cpu metric on instances.

The cost dashboard

Both tools give a project the same six widgets: 

• Current Month, 
• Forecasted Month End, 
• Last Month, 
• Current Month Breakdown, 
• Costs Breakdown Comparison
• and Top Cost Generators.

What OSIE and CloudKitty Share in Part

OSIE and CloudKitty both offer these features, but they do not match in full. The table shows where they differ.

	OSIE	CloudKitty stack
The billable item	A resource type (instance, volume, bucket) with several attributes. A rule applies to exactly one type.	A service: one metric made billable through the API, such as image.size
Several prices on one resource	One rule can hold several prices, and OSIE adds them together. Existence at 0.1 plus `vcpus` at 0.1 charges 0.3 an hour for a 2-vCPU instance. All the prices in one rule must be gauges, or all counters.	A second quantity needs its own rating type. One metric entry in `metrics.yml` can hold several, so you don’t need a second entry.
Conditions	A filter decides whether a rule applies. A modifier changes the amount when a condition holds.	A field: an attribute collected with a service that can activate a rule.
Custom logic	Adjustment rules shape the bill as a whole.	PyScripts: a Python script does the whole rating in place of hashmap rules.
Per-customer prices	Scoped plans assigned to billing profiles.	A mapping can be tied to a specific project. In our testing, the field was empty, so the mapping applied to every project.
Rating frequency	Per minute, hour or month. Monthly amounts are pro-rated.	One period, hourly by default.
Changing a price	Edit the rule. The new price applies from the next run, and billed hours are not re-priced.	A running rule can’t be edited. Delete it and create it again.
Stored results	An open bill that accumulates.	Rated entries in a storage backend, InfluxDB by default.
API and events	An Admin API for price plans, bills, and billing profiles, with a webhooks section.	REST API v1 and v2, and the openstack rating CLI. CloudKitty’s API reference lists no webhook endpoints.

Stored results

Rating produces data that has to be kept somewhere. CloudKitty stores one entry for each resource it rates each hour, in a storage backend, InfluxDB in our testing. 

OSIE keeps an open bill for each billing profile and each billing cycle. A charge on a gauge, such as existence, is added to the bill each run.

A charge on a counter, such as traffic, is overwritten with the total so far, because the counter already holds everything since the cycle began.

The OSIE bill shown here runs from 1 October to 1 November 2026. Its one costed line is a traffic counter, so it covers 1 to 29 October, the cycle so far. A bill can be downloaded as a PDF usage report or as a CSV file.

Tiers and Thresholds: Prices That Change With Quantity

Some resources cost less per unit as a customer uses more. OSIE does this with tiers, and CloudKitty does it with thresholds. 

The two work differently. Take a price of 1.00 a unit for the first 10 units and 0.50 after that, with a customer who uses 20 units. 

Graduated tiers price the first 10 units at 1.00 and the next 10 at 0.50, so the total is 15.00. On the other hand, a whole-quantity discount applies 0.50 to all 20 units, so the total is 10.00.

OSIE uses graduated tiers. Each tier has a From value, a To value, and an amount, and it prices only the part of the quantity inside its range. The results are added together.

CloudKitty uses a threshold, which is a rule with a level and a cost. In our testing, a rate threshold at level 10 with a cost of 0.5 behaved like a whole-quantity discount.

The image.size quantity was 20.6875 MiB at 0.01 per MiB, so the normal price for the hour was 0.206875. Graduated pricing would have given 10 × 0.01 + 10.6875 × 0.005 = 0.1534375. 

Every hour rated after the threshold existed came out at 0.1034375, which is 0.206875 × 0.5. We saw it for five hours in a row. The hour rated before it stayed at 0.206875. CloudKitty halved the price of the whole hour. 

We tested only one type of threshold, rate.

Different prices for different resources

Most clouds don’t price every resource the same. A small instance costs less than a large one, and a stopped instance may cost less than a running one. 

OSIE handles this in two steps. A filter decides whether a rule applies at all, for example only instances of flavor m1.small.

A modifier then changes the amount when a condition holds, for example subtract 50% while the instance’s status is SHUTOFF.

The condition is checked on every run, so starting the instance restores the full price.

CloudKitty uses fields, which are attributes collected with a service that can activate a rule.

Note. In the default setup, a status filter such as SHUTOFF has no matching attribute. The CloudKitty docs describe rating server status from a Prometheus metric, using the NOTNUMBOOL or MAP mutators with SHUTOFF as an example.

Changing a price

Prices change, and a billing tool has to apply the new one without rewriting the past.

In OSIE, you edit the rule and the new price applies from the next run. Hours already billed keep their old price, because the billing job never goes back and re-prices them. 

A rule that has been applied shows how many open bills it feeds and how much it has charged so far. If a price was wrong, fixing the rule stops further mispricing, but the amounts already written stay on the bill, so you also adjust the bills that were already rated.

In CloudKitty, a rule that has started running can’t be updated. You delete it and create it again with the new value. 

A new mapping has its own start date. We created two, and the hour that contained each start time stayed unpriced.

OSIE-Only Features

In this section, we cover the capabilities present only in OSIE. The CloudKitty stack has no equivalent for any of them.

Pricing structure

	OSIE	CloudKitty stack
Price plans as a container for rules	A price plan holds the rules. It is public or scoped, can be disabled, and can be limited to certain cloud providers.	No plan object. Rules belong to a module, and groups only bundle rules for management.
A payer	A billing profile, owned by an organization, with a balance and one bill per cycle. Every project is billed to one.	No payer. Rated data is reported per project.
Commitment discounts	Savings plans (beta): commit a monthly amount for 12 months or more, paid upfront or not, with tiers, aimed at resources by filter.	None known.

A payer: the billing profile

CloudKitty reports usage for each project, and it has no object for the person or company that pays. OSIE adds one, called a billing profile.

A billing profile belongs to an organization, and every project in that organization is billed to it. The profile holds the identity that goes on an invoice, one bill for each billing cycle, a balance, and any credits.

After pricing

	OSIE	CloudKitty stack
Invoices	A built-in PDF by default, or an external gateway: Stripe, WHMCS or Smartbill.	None.
Tax	Tax rules set per country and customer type. Several rates on a rule are added together, and one customer can have an override.	None. Leaves tax to billing software.
Payments and credits	Prepaid account credits with an Add funds button, promotional credits and promo codes, stored cards and bank transfers. Customers see a balance and a transactions list.	None.
Suspension	Warns customers who fall behind, suspends them and resumes them when they pay. Suspending revokes project roles, disables API users and suspends servers on every cloud the profile’s projects use.	None. It can’t limit resources in other OpenStack services.
Customer lifecycle	A customer is New, Active, Suspended, Skip or Deleted. Deleting anonymizes personal data. Purging erases billing history.	None.

Final Thoughts

CloudKitty and OSIE sit at different points in the same chain.

CloudKitty rates what each project uses. It puts a price you choose on that usage, stores the result, and stops there.

OSIE prices usage with plans you set, then goes further. It issues invoices, applies tax by country, takes payments, and suspends accounts that fall behind.

So the question that decides between them is simple. Do you charge anyone for usage?

If you only need to see what each project used and what it cost, CloudKitty covers that. If customers pay you, you need the jobs that come after pricing. You can build them around CloudKitty, or run a platform that already has them.

We hope this comparison helps you decide which jobs your cloud needs covered.

FAQs

Is CloudKitty a billing system?

No. CloudKitty is a rating-as-a-service project for OpenStack. CloudKitty reads usage from Gnocchi or Prometheus, applies the prices you define, and stores the priced result for each project. It does not generate customer bills. If you need those, you build them or use a billing platform like OSIE.

How is CloudKitty different from Ceilometer?

Ceilometer measures resource usage and publishes the measurements. Gnocchi stores them. CloudKitty reads that data, applies your prices to it, and stores the result. CloudKitty does not measure usage itself. It needs a data source such as Gnocchi or Prometheus, so you run the two together, and each does a different job in the same chain.

Is OSIE open source?

No. OSIE is a commercial product, and you run it on your own infrastructure. CloudKitty, by contrast, is an open source OpenStack project. 

Start a free OSIE evaluation: Free Edition | OSIE — All Features, $0 | OSIE – OpenStack Billing System