A client orders a dedicated server at 2 AM. In a manual workflow, an on-call engineer gets paged, logs into several systems, allocates hardware, assigns IPs, kicks off an OS install, updates the billing system, and emails the client their credentials. Even when everything goes smoothly, the round-trip takes a long time — and the more steps there are, the more places something can go wrong.
This is how many hosting providers still operate. Manual provisioning is slow, error-prone, and does not scale. Every new client means the same repetitive steps. Every mistake generates a support ticket and a frustrated customer.
FluxBilling automates this entire workflow. From the moment a client places an order to the moment they receive their server credentials, every step can run without human intervention.
The Problem with Manual Provisioning
Manual server provisioning has three core problems:
It is slow. Even experienced engineers take meaningful time per server. During sales surges or when multiple orders come in overnight, clients wait hours or even days for delivery.
It is error-prone. Copy-pasting the wrong IP, selecting the wrong OS image, or forgetting to update the inventory — these mistakes happen when humans perform repetitive tasks, and each one generates a support ticket.
It does not scale. Hiring more engineers to handle more orders is expensive and creates training overhead. Every new team member needs to learn your specific provisioning workflow, which is often undocumented and lives in someone''s head.
How FluxBilling Automates the Full Lifecycle
FluxBilling breaks server provisioning into discrete steps, each of which can be automated independently. The full lifecycle looks like this:
1. Order Placement and Payment
The client selects a product, chooses their configuration options (OS, control panel, additional IPs), and completes payment. FluxBilling creates the service record and triggers the provisioning flow.
2. Automatic Server Allocation
FluxBilling''s allocation engine matches the ordered product against available inventory. The matching rules are configurable per product:
- CPU requirements — Match by model, core count, or equivalence groups (e.g., an E-2388G can substitute for an E-2386G when you configure them as equivalent)
- RAM requirements — Minimum and exact matching
- Storage requirements — Match by type (NVMe, SSD, HDD), capacity, and configuration
- Location — Datacenter and rack preferences
If a matching server is available, it is automatically assigned to the service. If no match is found, the system can queue the order for manual fulfillment or trigger an out-of-stock notification.
3. IP Address Allocation
Once a server is assigned, FluxBilling''s IPAM system allocates IP addresses automatically based on rules configured per product:
- Primary IPv4 — Allocated from a designated subnet, respecting gateway and broadcast exclusions
- Additional IPs — If the client ordered extra IPs, they are allocated from the same or a specified subnet
- IPv6 — A /64 block from the appropriate pool
- VLAN assignment — The IP is associated with the correct VLAN for the datacenter and rack location
The allocation is atomic. If any part fails (subnet exhausted, VLAN misconfigured), the operation rolls back and the admin is notified. No half-configured servers.
4. OS Installation
FluxBilling supports multiple provisioning backends through its visual plugin system:
- Bare Metal module — Physical server provisioning backed by open-source bare metal management tooling, with support for PXE and Redfish virtual media boot
- IPMI/Redfish — Direct hardware control for power management, boot order, and console access
- Custom flows — Any provisioning system with an API can be integrated using the visual plugin builder
The OS installation runs unattended. The client''s selected operating system is deployed with their SSH key or initial password configured. Post-install scripts can run additional setup like installing control panels or security hardening.
5. Client Notification
Once provisioning completes, FluxBilling sends the client their access credentials via email. The email template is customizable and includes:
- Server IP address and hostname
- SSH credentials or key confirmation
- Control panel URL (if applicable)
- Quick start documentation links
The client can immediately see their server details in the client portal, including power controls, reinstall options, and bandwidth graphs.
The Visual Plugin System
The automation described above is powered by FluxBilling''s visual plugin system. Instead of writing PHP modules or shell scripts, provisioning workflows are built as visual flows using a drag-and-drop node editor.
How It Works
Each flow is a directed graph of nodes:
- Trigger nodes start the flow (e.g., "Service Created", "Payment Received")
- Action nodes perform operations (e.g., "API Call", "Set Variable", "Send Email")
- Logic nodes control flow (e.g., "If/Else", "Switch", "Loop")
- Data nodes transform data (e.g., "Map Fields", "Parse JSON", "Template")
You connect these nodes to create a complete provisioning pipeline. For example, a Proxmox VPS provisioning flow might look like:
- Trigger: Service Created
- API Call: Create VM on Proxmox node
- Wait: Poll VM status until running
- API Call: Get VM IP address
- Update Service: Save IP and credentials to service record
- Send Email: Client notification with access details
Supporting Multiple Providers
Each provisioning provider has its own visual flow. When a client orders a product, FluxBilling runs the flow associated with that product''s category. This means you can support multiple infrastructure types simultaneously:
- VPS products use the Proxmox flow
- Dedicated servers use the bare metal flow
- Game servers use the Pterodactyl flow
- Custom services use custom flows
Adding a new provider is a matter of building a new visual flow, not writing and maintaining code.
A Real Provisioning Workflow
Here is what a fully automated dedicated server delivery can look like end-to-end when every step is configured:
- Minute 0 — Client places order and pays
- Minute 1 — FluxBilling matches the order to an available server in inventory
- Minute 2 — IPAM allocates primary IP, additional IPs, and IPv6 block
- Minute 3 — The bare metal provisioning flow begins PXE boot and OS installation
- Installation completes — Post-install scripts run
- Service record updated with IP, credentials, and access details
- Client notified — Email with server access information is sent
- Client logs in — Portal shows the server ready to use
Zero manual intervention. The client orders and receives a fully configured dedicated server without anyone on your team lifting a finger.
Advanced: IPAM Auto-Allocation Rules
FluxBilling''s IPAM allocation rules are configured per product and support sophisticated scenarios:
- Subnet selection — Choose which subnets to allocate from based on datacenter, rack, or VLAN
- Gateway handling — Automatically skip gateway and broadcast addresses
- Sequential or random — Allocate the next available IP or randomly select from the available pool
- Reservation — Reserve IP ranges for specific clients or purposes
- Auto-allocatable flag — Mark subnets that should be used for automatic allocation vs. manual-only
The allocation rules integrate directly with the provisioning flow. When a visual plugin flow requests an IP allocation, it uses these rules to select the right address without any manual decision-making.
Getting Started with Automated Provisioning
Setting up automated provisioning in FluxBilling involves three steps:
- Configure your inventory — Add your servers, racks, and network devices in the DCIM section
- Set up IPAM — Create your subnets, VLANs, and allocation rules
- Build or import provisioning flows — Use the visual plugin editor to create flows for your infrastructure, or import pre-built templates
FluxBilling includes template flows for common provisioning scenarios. For custom infrastructure, the visual editor makes it straightforward to build flows without coding.
Start your free trial to explore the provisioning automation features. See also our EasyDCIM comparison for how the integrated DCIM powers these workflows.
Proxmox, Virtualizor, SolusVM, Pterodactyl, and any other third-party product names mentioned in this article are trademarks of their respective owners. FluxBilling is not affiliated with or endorsed by any of these companies. Feature information about third-party products is based on publicly available documentation as of February 2026 and may not reflect recent changes.
