FluxBilling.app Reviews and Details

Questions & Answers

1. How would you describe the primary audience of FluxBilling.app?

   Providers who own physical inventory. Dedicated server providers, colocation operators, VPS hosts, and resellers who have grown into their own hardware, typically running between one rack and a few hundred machines. The defining trait is not headcount or revenue, it is having racks and IP ranges of your own, and a team small enough that reconciling the billing system against the rack is nobody's actual job. Once the metal is yours, the money side and the infrastructure side have to be the same system or they drift apart, and the drift is only ever found late.

2. What makes FluxBilling.app unique?

   The IPAM and the provisioning are automated, and they run off the same database as the billing. A paid order picks a free machine out of inventory, pulls the next addresses from the correct pool and binds them to that service, sets the VLAN on the switch port, boots the machine over iPXE, installs the operating system, writes the reverse DNS, and closes the invoice. Cancellation runs the same sequence in reverse: addresses return to the pool, the VLAN comes off the port, the machine returns to available. No scripts, no tabs open across four systems, no reconciliation afterwards. Billing that knows what is in the rack, and a rack that knows what has been paid for, is the whole design.

3. Why should a person choose FluxBilling.app over its competitors?

   Because most of this category stops at the invoice. Once a payment clears, you are still expected to run something else for your racks, something else for your addresses, and something else again to install an operating system, with scripts holding the three together and a reconciliation job that never ends. FluxBilling does all four in one platform, so a paid order provisions the hardware, allocates the addresses and closes itself out without anyone touching it. Pricing works the same way: no fee per payment gateway, no fee per DCIM module, no fee per integration. Every plan includes the full platform and the visual plugin builder, so the number on the plan is the number on the invoice. Moving in is covered too, with importers that carry your clients, services, recurring invoices, products, addons, racks, U positions and IP allocations across.

4. What's the story behind FluxBilling.app?

   We built it to run our own hosting company. For years our billing lived in one system and our datacentre lived in another, joined by scripts that one person understood. The invoice said a server was sold, the rack said it was still in stock, and the IP spreadsheet said something else again. Provisioning a dedicated server meant four browser tabs, and deprovisioning meant remembering to free the addresses, which is the step everyone forgets and nobody notices until a /24 is gone. Building it properly eventually became less work than patching around it. FluxBilling has run X-Zone Servers in production since well before it was a product, and every part of it exists because something broke for us first.

5. Which are the primary technologies used for building FluxBilling.app?

   PostgreSQL for data, with one isolated database per tenant. Kubernetes, running as K3s, with each tenant in its own namespace. React and Vite for the admin and client panels. Node and Bun on the server. nginx for routing and TLS. OpenStack Ironic for bare metal lifecycle, with iPXE for network boot, and Redfish and IPMI for out of band hardware control.

6. Who are some of the biggest customers of FluxBilling.app?

   • X-Zone Servers, which runs its billing, DCIM, IPAM and bare metal provisioning on FluxBilling in production