How to sell web hosting with ISPConfig

Most control panels manage one server. ISPConfig manages a fleet: one install standing in front of separate web, mail, DNS and database machines, with the sites and mailboxes distributed across them and a single interface over the lot. It has been doing this for a very long time, it is open source, and it costs nothing.

It is also the panel in this category with the most complete idea of what a customer is. ISPConfig has clients, resellers, limits and templates as first-class objects, which is more than most of its competitors can say. What it does not have, and this is the whole reason a page like this exists, is any notion of a customer who pays you.

What ISPConfig already gives you

Three things, and they are unusually good ones.

Clients, not just accounts. An ISPConfig client is a person or a company that owns things: websites, mailboxes, DNS zones, databases. That is the shape a hosting product actually has, and you do not have to invent it.

Limits, and templates to apply them. Every client carries limits: how many web domains, how many mailboxes, how many databases, how much space. Client templates let you define a set of limits once and apply it to many clients, which is exactly a product catalogue by another name. A limit of -1 means unlimited, which is worth knowing before you read a template and conclude that something is broken.

Resellers. ISPConfig understands that a client can themselves have clients. If you sell to agencies who sell to their own customers, that hierarchy exists in the panel rather than in a spreadsheet you maintain next to it.

Between them, those three cover the parts most panels make you build yourself.

The unusual part: one panel, several machines

This is what genuinely separates ISPConfig from DirectAdmin, cPanel, CloudPanel and the rest.

A single ISPConfig install can drive dedicated web servers, a separate mail server, separate DNS servers and a separate database server, configured as a multiserver setup, with mirroring available for the parts that need redundancy. When you add a website, ISPConfig writes it to whichever machine is meant to carry it.

For a hoster, two consequences follow. The good one: growth means adding a machine behind the panel, not standing up a second panel and splitting your customers across two systems that do not know about each other. The one to plan for: your idea of "a server" and ISPConfig's idea of "a server" stop being the same thing. An account is no longer pinned to a box you can point at, which is fine, but any inventory you keep above ISPConfig has to be comfortable with a customer whose website is on one machine and whose mailboxes are on another.

The remote API, and the two things to know about it

ISPConfig automation goes through its Remote API, available in SOAP and JSON flavours. Two properties shape everything you build on it.

It is session-based, not token-based. You call login with a remote user's name and password, get a session_id back, and pass that with every subsequent call. The session is valid for a limited time. That is a different lifecycle from the bearer tokens most modern panels hand out: your client has to hold a session, notice when it has expired, and log in again. It should not do that by retrying blindly, because a login loop against wrong credentials is how you end up locked out of something.

Permissions are per function, and they are checked. You create a Remote User in the panel (System, then Add Remote User) and tick the categories of call it may make. ISPConfig verifies that permission on every call it receives.

That second property is genuinely valuable and worth using properly. It means the credential sitting in your automation does not have to be able to do everything ISPConfig can do. Give it the functions your provisioning actually calls and nothing else, and a mistake in your own code cannot reach the parts of the panel you never intended to touch. Very few panels in this class let you draw that line at all.

The functions themselves read the way you would hope. Clients are created with client_add. Websites are sites_web_domain_add, sites_web_domain_update, sites_web_domain_get and sites_web_domain_delete. And critically for anything commercial, there is sites_web_domain_set_status. That is a real, supported way to switch a website on and off, the single verb that hosting billing revolves around and that several competing panels simply do not have.

What it still does not do

Everything above is infrastructure. None of it is commerce.

ISPConfig will not take an order, will not take a payment, will not produce an invoice, will not chase one, and will not decide on the thirty-first day that this client has stopped paying and should be switched off. It has the lever (set_status) but nothing that decides when to pull it. There is no catalogue with prices, no signup flow, no dunning schedule, and no view that tells you what your fleet is costing you against what it is earning.

That is not a criticism. A control panel that also tried to be a billing system would be worse at both. But it does mean the interesting work in selling ISPConfig hosting is entirely in the layer above, and that layer is the same one you would need for any other panel:

• An order form and a catalogue, with plans that map onto client templates.
• A payment that triggers provisioning in seconds.
• A dunning path (overdue, warned, suspended, restored) wired to set_status at the right step.
• Capacity you can see, so you know how many accounts you carry across all those machines and what they cost.
• An audit trail, so "who changed that limit" has an answer.
• A permission model for your own staff, so support can act without being able to delete a client.

Where Provibr fits

ISPConfig support is live. An agent inside your own network talks to the panel's remote API, so nothing on your panel has to face the internet and no ports have to be opened. Creating a client with a website and a package, suspending it, resuming it, changing the package and removing it all work, accounts that were already there can be imported, and disk and traffic show up in the graphs. Around that sits the layer above: plans and capacity with a per-unit price, a permission model for your team, an activity trail, and a REST API and WHMCS module so the platform you already bill with can drive it.

The credential in the agent's vault can be much narrower than an administrator, because ISPConfig grants remote permissions per function: the remote user is scoped to exactly the calls Provibr makes and nothing beyond them. Which of your machines ISPConfig places a site on stays ISPConfig's decision, the account actions are the same either way, and each account counts as one web server in your capacity regardless of which machine ends up running it.

What the integration will not do is touch accounts you did not create through it: those are left alone until you import them, and you pick which ones. One practical note about the connection itself: a fresh ISPConfig install is self-signed, so its TLS fingerprint is worth pinning when you add the integration.

What it will not do

Managing accounts is not managing the panel. Installing ISPConfig, updating it, adding servers behind it, configuring mail routing and looking after DNS all stay with you, in ISPConfig, where they belong. A customer editing their own mailbox does so without anything above the panel knowing or caring.

You do not have to standardise on one panel to keep one overview. Provibr runs its control panels, hypervisors and game panels side by side today. They share one inventory, one permission model and one activity trail. A multi-server open panel for the customers who want mail and DNS included, something else for the ones who ask for cPanel by name, and one place where you can see both.