> ## Content Index > Fetch the complete content index at: https://blog.hostly.ninja/llms.txt > Use this file to discover other available public pages before exploring further. # Meteroid: When Your Billing Provider Actually Builds With You - URL: https://blog.hostly.ninja/hostly-meets-meteroid-a-cooperation-story/ - Published: 2026-09-14T19:00:46.000Z - Updated: 2026-10-14T07:03:06.000Z - Description: How Hostly uses Meteroid for usage-based billing, metered pricing, subscriptions, and customer billing. Plus why fast support and rapid feature development made the difference. - Author: Michael Zigldrum - Tags: News Billing is one of those things you don't really want to build yourself. At Hostly, our goal is to make running Docker workloads as simple as possible, and naturally we wanted the same thing for pricing: a small number of understandable metrics, usage-based billing, and as little unnecessary complexity as possible. The problem is that simple pricing for the customer does not necessarily mean simple billing behind the scenes. For Hostly, customers pay based on four resources: CPU, memory, storage and egress. On top of that, each plan has a monthly commitment that can be consumed by any combination of those resources. We initially started building the billing logic ourselves, but it quickly became clear just how much of a product billing becomes once you go beyond creating an invoice at the end of the month. Metering, pricing, subscriptions, checkout, customer portals, entitlements and all the edge cases around plan changes add up quickly. Dont believe our pricing model is that simple? [Check our prices ](https://hostly.ninja/prices?ref=blog.hostly.ninja) At some point, the obvious question became: why are we building this ourselves if someone else has already solved it? ## Why [Meteroid](https://www.meteroid.com/?ref=blog.hostly.ninja) We evaluated a number of billing platforms, but most of them felt like they were designed around fairly rigid subscription models, with usage-based billing added on top. Meteroid was different. Their model of meters, components and plans mapped much more naturally to how we wanted Hostly's pricing to work. Instead of trying to force our pricing model into the constraints of the billing system, we could describe the resources we actually charge for and build the plan around them. That was already a strong reason for us to choose Meteroid, but there was still one important gap: our exact pricing model wasn't supported yet. ## From “not supported” to “will be released in a few weeks” Our customers have a monthly commitment that applies across all four usage metrics. A customer might consume it entirely through CPU and memory, through storage and traffic, or through any combination of the four. Meteroid already supported commitments, but not quite in this form. This is where our experience with their team stood out. Instead of simply telling us that the feature wasn't supported, we discussed the use case directly with Meteroid. They understood what we were trying to achieve, proposed how it could fit into their existing model, agreed on what needed to be built and gave us a concrete delivery timeframe. Shortly afterwards, the feature was available. For us, that was probably the strongest part of the whole integration. There was no endless support chain, no need to explain the same requirement to several different people and no vague “we'll add it to the roadmap” answer. We could talk directly about the problem with people who understood the product, agree on a solution and move forward. ## Support is part of the product It's easy to compare SaaS products by looking at feature matrices, but some of the most important differences only become visible once you actually start integrating them. Questions come up, documentation does not cover your exact situation, your architecture works slightly differently from what the product originally anticipated, and occasionally you run into something that simply needs to change. At that point, response time and access to people who actually understand the product matter just as much as the feature set itself. Our experience with Meteroid has been very good in that regard. Feedback gets understood quickly, technical questions reach people who can answer them, and when something needs changing, the conversation is usually about finding a solution rather than working around a support process. The shared commitment feature was the clearest example of this, but more generally it gave us confidence that we weren't integrating a black box that we'd have to work around later. ## Building Hostly, not billing software For us, that's ultimately the point. We want to spend our time making Hostly better: improving deployments, infrastructure, developer experience and everything around running applications. We don't particularly want to become experts in subscription lifecycle management. Meteroid lets us keep a pricing model that fits the way our infrastructure is actually consumed without having to build and maintain the billing infrastructure behind it ourselves. More importantly, when our requirements didn't quite fit what already existed, we found a team willing to understand the problem and build the missing piece with us. That's the kind of infrastructure provider we like working with. [![CTA Image](https://blog.hostly.ninja/content/images/2026/09/meteroid-black-1.webp)](https://www.meteroid.com/?ref=blog.hostly.ninja) We like to share solutions that worked for us, so if you are also building metered services, check out Meteroid! [Learn more about Meteroid ](https://www.meteroid.com/?ref=blog.hostly.ninja)