What a dedicated-server host has to automate between a paid order and a working machine, what breaks at each stage, the tooling options, and where FluxBilling's Bare Metal module fits.
Mario Marin12 min readBare metal provisioning is the automated chain that turns a paid dedicated-server order into a running machine: choose a free server that matches the plan, assign its IP addresses, open its switch port, boot it over the network or BMC virtual media, write the operating system and hand over credentials and out-of-band access. Every stage can fail, so the recovery path matters as much as the happy path.
How this was written. FluxBilling publishes this guide and sells billing software for hosting providers with a Bare Metal module. Third-party tools are described from their own websites as read on 12 October 2026; no prices are compared.
Nine stages, in order:
Inventory records what hardware reports; plans state what you sell. A “480 GB” SSD reports about 447 GB, a 128 GB server can show 122 GB after firmware takes its share, and one Xeon gets spelled three different ways. An exact-match allocator rejects good machines for this, so you need equivalences: 447 counts as 480, 122 as 128, these two CPU strings are one part.
Treat location, CPU and RAM as hard checks, and turn fixable gaps (an extra disk, a faster NIC) into added lead time instead of a rejection. Sell only machines that are racked, cabled and have working BMC credentials. Getting accurate specs into inventory is covered in auto-discovering hardware and network ports over SNMP, IPMI and Redfish.
Check address availability before taking a machine. If the location’s pool is exhausted, the right outcome is a clean failure with nothing reserved, not a server bound to an order it cannot serve.
Per-customer VLANs or routed subnets mean a switch change on every delivery and termination. Automate it, but start in a dry-run mode so you can read the exact configuration before it touches production switches. Keep the provisioning network and its DHCP range clear of anything your IPAM for hosting providers hands out. If addresses still live in a spreadsheet, start with what an IPAM should track.
PXE is network boot built into server firmware. After a one-time boot override set through the BMC, the NIC asks DHCP for an address and a boot file, then fetches a small loader over TFTP. Most setups chain-load iPXE at that point so the kernel and ramdisk come over HTTP, which is faster than TFTP for large files.
An installer path then boots the distribution’s own installer with an answer file: kickstart for AlmaLinux, Rocky Linux and CentOS Stream, preseed or autoinstall for Debian and Ubuntu — which is all a classic “CentOS PXE server” is. An image path boots a small agent that writes a ready-made OS image, which is quicker and more repeatable.
The alternative is virtual media: the BMC mounts an ISO and the server boots from it like a local drive. It needs no DHCP, which suits a colocation rack you do not control, but large images stream slowly. For that case FluxBilling publishes a free 3 MB boot ISO, the FluxBilling OS Installer, which takes a static IP at the console and installs one of 19 server OS entries unattended. So far it is tested end to end only on Ubuntu 24.04 with Dell iDRAC.
“The installer exited cleanly” is not delivery. First confirm the machine booted from disk rather than back into network boot, answers on its public address and reports the right hostname. Then stamp the delivery date and send credentials. If a person checks new hardware models first, give that queue an owner.
When a customer breaks networking or a bootloader, the only way in is the BMC. Offer power control over IPMI or Redfish (the DMTF’s newer management standard), a browser KVM console, serial-over-LAN and, ideally, a rescue boot.
Do not hand out raw BMC credentials: a BMC administrator can change boot order, users and network settings you depend on, and some BMCs allow only one or two console sessions. Proxy the console through your panel, scoped to the customer’s server, and withdraw it on suspension.
A reinstall is the install stage without allocation: same machine and addresses, new OS, data gone. Require confirmation, use the customer’s current SSH keys, and refuse it while the service is suspended.
Termination reverses delivery: power off, port down, addresses back to IPAM, machine back in stock. Decide in advance whether you erase disks between customers (a metadata wipe is fast, a full overwrite slow) and whether released IPs rest before reuse, so nobody inherits a predecessor’s blocklist entries.
The money is taken and the machine does not exist. That gap, covered in when provisioning fails after payment, is where hosts lose customers:
| Stage | What can fail | How to detect it | What the customer sees |
|---|---|---|---|
| Allocation | No matching machine in that location; specs worded differently from the plan | No candidate returned; log which check rejected each machine | A paid order “being prepared” with no progress |
| Addressing | Pool exhausted; request only partly satisfied | Check before reserving hardware; alert on pool thresholds | The same, with nothing left half-reserved |
| Switch / VLAN | Wrong port mapping, bad credentials, config rejected | Per-port job log with the pushed config and result | A server that installs but is unreachable — it looks delivered |
| Boot | BMC unreachable, override ignored, DHCP on the wrong segment | Timeout on the loader fetch; BMC power state | A delay with no visible progress |
| Install | Image download, RAID, missing disk or driver, answer-file error | Installer error callback; a time limit on the install | A delay, then a failed status |
| Post-install | Boots back into the network, wrong NIC configured, no route | Ping or SSH probe on the public address; hostname check | Credentials that do not work |
| Hand-over | Email bounced, password missing | Delivery log; credentials visible in the portal | A ticket asking for credentials |
| Termination | Power-off or port-down failed; addresses not released | Reconcile billing state against switches and IPAM | Nothing — the next customer gets a machine or address still in use |
Three rules keep it manageable: release whatever a failed attempt took, so a retry starts clean; retry a bounded number of times, then alert a person with the step and error; and tell the customer yourself, before an unexplained “failed” becomes a chargeback.
The hard part is the join: something must connect “paid” to “install”, “overdue” to “power off” and “cancelled” to “release the addresses”. In a two-product stack, that is code you own. The billing side is covered in billing software for bare metal and dedicated server providers.
FluxBilling is billing, DCIM and IPAM software for hosting providers; its Bare Metal module runs this pipeline in the system that issues the invoice:
Every plan includes bare-metal servers — 5 on Lite, 25 on Starter, 50 on Professional, 75 on Business — and each extra server is €0.50 a month ($0.59 for US accounts). Setup is in the Bare Metal documentation; the order-to-active flow for every product type is on the automated provisioning page.
Where FluxBilling does not fit, plainly. It is pre-1.0 software. If you only need provisioning — an internal fleet, a lab — and your billing works, MAAS, Foreman or Tinkerbell is free, has a longer track record and covers ground FluxBilling does not, such as MAAS’s hardware commissioning tests. The Bare Metal module needs a dedicated provisioning network with PXE support and BMCs reachable from the site’s agent. Only Dell iDRAC has a dedicated driver; other vendors use generic Redfish or IPMI, so test one machine per model before selling it. And termination has no disk-erase step: the server returns straight to Available, so if your policy requires an erase, move it to Maintenance and wipe it yourself.
Plans start at €4.95 a month (see pricing) with a 14-day refund on subscriptions, or try the Bare Metal screens in the public live demo first.
It is the automated process of taking a physical server from racked and powered to running the customer’s OS on their addresses, with nobody at the console. For a hosting provider it runs from payment to delivered credentials and console access.
The BMC sets a one-time network boot; the NIC gets an address and boot file from DHCP, loads a loader over TFTP, usually chains to iPXE, and pulls an installer or imaging agent over HTTP. Once the OS is written, the machine reboots from disk and cloud-init finishes configuration.
From racked, cabled stock on a working provisioning network, automated delivery takes minutes to hours, not days. When a machine needs a part first it is days, and the order page should say so. FluxBilling’s own delivery estimate defaults to a 30-minute base, adding two or three days per upgrade a partial match needs.
The charge stands and the service shows as failed. A good pipeline releases what the attempt reserved, retries a few times, then alerts staff with the step and error. The customer should hear from you first, with a cause and a time.
Yes, if it has a provisioning module that reaches the hardware, through a provisioning framework or by driving BMCs and switches itself. Check the whole lifecycle: customer power and console, reinstall, suspension that powers off, and termination that reclaims addresses.
Canonical, MAAS, Foreman, Tinkerbell, Redfish, Dell, iDRAC, Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS and Windows are trademarks of their respective owners. FluxBilling is not affiliated with or endorsed by any of them. Third-party tools are described as published on 12 October 2026 and may have changed since.
Selling physical machines breaks assumptions that shared-hosting billing platforms are built on. Seven questions to ask, what each vendor answers, and the four scenarios to test before you buy.
A hosting business sells across bare metal, virtualization, web hosting and domains, and most run three or four systems to do it. This is the goal, how far along it is, and the list of what is still missing.
The payment succeeded, the provisioning failed, and the invoice says paid. It is unavoidable — the question is whether your platform notices, or the customer does first.
How modern hosting providers automate provisioning end-to-end — the API patterns, idempotency, error handling, and webhooks that turn an order into a live server.
Dedicated pricing usually gets set by copying a competitor or adding a percentage to hardware cost. Both are wrong in ways you will not notice for a year.