Blog ·
FOSSBilling Pterodactyl integration: what actually exists
FOSSBilling says it will not build a Pterodactyl integration. That leaves three ways to sell game servers through it, and they fail in different places.
By Provibr
If you are searching for a FOSSBilling Pterodactyl integration, the first thing worth knowing is that the project has answered the question directly, and the answer is no. That is not a gap waiting to be filled in the next release; it is a stated scope decision. What follows is what that leaves you with: three routes, what each one really costs, and which parts of ours are proven and which are not.
FOSSBilling's own position
FOSSBilling's documentation lists five supported server managers (CWP, Plesk, DirectAdmin, HestiaCP and WHM/cPanel) and states that FOSSBilling does not support Pterodactyl and that the core project does not plan to build or maintain an integration. It points developers who want one at its own guide on creating a server manager.
The FOSSBilling FAQ repeats the position: it does not provide an official Pterodactyl integration and the core project does not currently plan to build or maintain one, while noting that community members are welcome to develop their own.
Read the list in that first claim again, because it is the useful part. Every supported server manager is a web hosting panel. FOSSBilling's server-manager abstraction was shaped around accounts with domains, mailboxes and disk quotas. A game server has none of those and has things none of them have: an egg, a startup command, environment variables, port allocations, and a console the customer expects to actually use. The absence is structural, not accidental.
Three routes, and where each one breaks
| Route | What it costs you | Where it breaks |
|---|---|---|
| A community module from GitHub | Nothing up front | You now depend on one volunteer's spare time for the code that suspends non-payers. Check the last commit date before, not after |
| Write your own server manager | Weeks, then forever | The billing side is the easy half. The Pterodactyl API has traps that only show up in production, listed below |
| Put a provisioning platform between them | A per-unit price | FOSSBilling stops knowing about Pterodactyl at all, which is the point, but it is another moving part |
Community modules for this do exist and are easy to find. We are not going to name a version or vouch for one we have not run. But the question to ask about any of them is not "does it work today", it is "who fixes it when Pterodactyl changes something". A module that provisions is a convenience; a module that suspends is load-bearing.
The Pterodactyl traps any of these routes inherits
We measured these against a running panel while building our own integration, and every one of them produces a wrong result rather than an error, which is why a first implementation looks fine.
- There is no
GET /api/application/eggs/{id}. You have to walk the nests to find an egg, which means "let the admin pick an egg" is a two-level fetch and not a lookup. - Egg variables have no
requiredfield. The requirement lives in Laravel validation rules, so a create can fail on a variable your form never showed anyone. limits.io: 0is not unlimited. It is a weight, and zero is not a valid one./resourcesis cached for twenty seconds. A dashboard that polls faster is showing you the same numbers with a fresh timestamp.
The full write-up, with what Pelican changed about each, is in five Pterodactyl API traps. Whichever of the three routes you take, someone has to have solved these. The only question is whether that someone is you.
What the Provibr module for FOSSBilling actually does
We build the third route, so treat this section as an interested party describing its own work, with the limits stated, which is the only way that is worth reading.
The module is a plain zip you install yourself. It is a FOSSBilling Service module: it unpacks into modules/, you activate it under Extensions, and activation creates its own table and registers a new product type. It was built and measured against FOSSBilling 0.8.5 on PHP 8.3, and it does not touch FOSSBilling's core files or load a second autoloader.
Setting it up is three screens:
- Settings. Paste a Provibr API key scoped to the calls the module makes, and press Test connection.
- A product of the new type. Its Configuration tab lists your Provibr plans (VPS, hosting and game, each with its name and a summary) and your integrations, and you pick one of each.
- Nothing else. Ordering runs through FOSSBilling's normal order flow from there.
The lifecycle maps onto FOSSBilling's own hooks: a paid order provisions, a suspension suspends, an unsuspend resumes, a cancellation removes. The client area reads the live status back from Provibr rather than showing what the last write believed.
One design decision is worth stating because it changes what your order list looks like. If provisioning is still running when the module's wait budget expires, activation returns success, not failure. The order was accepted, the record exists, the address is assigned and the instruction is with the agent. Throwing there would mark the order failed_setup while the machine is being built. A command that genuinely fails does throw, and the reason lands in the status history.
The part where the egg comes from, and what is not proven yet
This is the mechanically interesting bit for a game product, and it is also where the honest caveat lives.
FOSSBilling never picks an egg. The product points at a Provibr game plan, and the egg lives on that plan: per integration, the plan carries the nest, the egg, and optionally the Docker image, the startup command, the environment variables and the location. The order body FOSSBilling sends is essentially "this game plan, on this integration"; everything about what the server is comes from the plan definition on our side. That is deliberate: it means the same FOSSBilling product can point at a different panel later without the product changing, and it means an egg id never has to be typed into a billing system.
And here is what has not been proved. Of the three order kinds the module can build, only the web hosting path has been taken end-to-end through the whole chain. VPS and game are wired (the plan dropdown lists them, the order body knows the fields), but they have not been carried through a full order, provision and cancellation in the way the hosting path has. Saying otherwise would be worth nothing until you can watch it work.
Three more things that are simply not there yet, and are worth knowing before you plan around the module: there are no power buttons in the FOSSBilling client area, there is no usage graph and no console through it, and changing a plan is not a single API call at our end. The console and the power controls exist in Provibr's own panel; they are not exposed through the module.
Who owns what, if you go this way
| Layer | Owns |
|---|---|
| FOSSBilling | The catalogue, the invoice, the payment, dunning, and the customer's login |
| Provibr | The plan and its egg mapping, capacity and per-unit price, the agent inside your network, the audit trail, the console |
| Pterodactyl | The node, Wings, the allocation and the game server itself |
The reason to draw that line at all is that it is the same line whatever you sell next. A Pterodactyl node and a Pelican one and a hosting panel all sit behind the same plan-and-capacity layer, so adding the second kind of product does not mean a second provisioning integration inside your billing system. If you are still choosing between panels, Pterodactyl vs Pelican is the comparison, and FOSSBilling next to WHMCS is the billing one.
Read next
- Five Pterodactyl API traps: the measurements behind the list above.
- The FOSSBilling module: what it is, the requirements, and the download.
- Pterodactyl setup: the two key types, nodes and allocations, and importing servers that already exist.
- The public API: the endpoints the module calls, with scoped keys and a per-request audit trail.
FOSSBilling's position on Pterodactyl was read from docs.fossbilling.org on 1 September 2026 and is quoted with its sources above. The Pterodactyl API behaviour was measured against a running panel while building the Provibr integration. The module's own limits are described from its source, including the paths that have not been proven end-to-end.
