HostPane documentation

Overview

HostPane is a modern hosting control panel. You install it on a single Linux server, and it turns that machine into a complete hosting platform — serving websites, email, DNS, databases and file storage from the same box, all managed through a clean web interface.

HostPane ships three panels, each with its own concerns:

• Administrator panel — the operator's view of the whole server: create hosting accounts, control every subsystem, watch monitoring and alerts, run backups and read the audit log.
• Reseller panel — delegated account management with white-label branding, so a reseller runs their own slice of the server under their own name.
• Customer panel — the account owner's self-service surface: websites, email, DNS, databases, files, backups and more.

Under the hood HostPane manages proven, open-source software — Caddy for automatic HTTPS in front of NGINX or Apache, a full Exim and Dovecot mail stack, authoritative DNS, MariaDB and PostgreSQL — so you're never locked into a proprietary black box. Your configuration lives on your own server as plain, readable files.

All three panels are available in English, German, Spanish and French; each person picks their own language. The in-panel help guides for operators and resellers are in English.

Requirements

HostPane targets a single dedicated server or VPS. You'll need:

• A 64-bit (x86_64) Linux server running one of the supported releases: Ubuntu 22.04, 24.04 or 26.04 LTS, Debian 12 or 13, AlmaLinux 8, 9 or 10, or Rocky Linux 8, 9 or 10. HostPane refuses a release it does not recognise rather than guessing at its package names.
• Root access (or full sudo) to the machine.
• A public IPv4 address routed to the server. IPv6 is optional; when the server has one, new zones get AAAA records too.
• A domain name whose DNS points at that server (you'll use it for the panel and for your nameservers).

Recommended baseline: at least 2 GB RAM (4 GB+ if you'll run the spam scanner and databases under load) and 20 GB disk to start, growing with your customers' sites and mailboxes. A freshly installed OS with nothing else competing for ports 25, 53, 80 and 443 is ideal.

AlmaLinux and Rocky Linux 8 are supported chiefly so existing servers on them can be converted in place. Their distribution does not package restic, so backups there need it installed separately; for a new server, prefer 9 or 10.

Installation

HostPane ships as one prebuilt bundle that installs on every supported distribution — the same artifact on Ubuntu, Debian and Enterprise Linux. Its compiled dependencies are already built, so there is no toolchain to install on a production server and no package index to reach at install time; a server with no outbound internet access installs exactly the same way. As root:

# 1. Download and unpack (replace <version> with the release you downloaded)
tar xzf hostpane-<version>-linux-x86_64.tar.gz
cd hostpane-<version>-linux-x86_64

# 2. Check the bundle is intact, then see what the installer would do
sha256sum -c SHA256SUMS
sudo ./install.sh --check

# 3. Install
sudo ./install.sh

The installer picks an interpreter the bundle carries wheels for, installing Python 3.11 from your distribution if the system Python is too old (Ubuntu 22.04, AlmaLinux and Rocky 8 and 9). Re-running it upgrades in place and restarts what is already up, so there is no separate upgrade path to remember.

During install HostPane sets up two systemd services that form its security spine:

• hostpane-api — the web application, running as an unprivileged user. It serves all three panels and holds your sessions. It never touches system files directly.
• hostpane-host — a small root helper that listens on a local socket and performs the privileged work (creating Linux users, writing service configs, reloading daemons) on request.

The installer only reports success once both are actually serving — the socket exists and the panel answers on its port — not merely once systemd says they were started. A third unit, hostpane-convert, is installed but not enabled; it is only for converting a server that runs another panel.

First-run setup

The panel listens on 127.0.0.1 until you give it a hostname, so reach it the first time over an SSH tunnel:

ssh -L 8080:127.0.0.1:8080 root@<server>
# then open http://127.0.0.1:8080 in your browser

1. Sign in as root with the server's own root password. Members of the hostpane-admin Linux group can sign in with their Linux passwords too. If you prefer a panel-only administrator, create one with sudo hostpane create-admin --username admin.
2. Install the hosting stack — on a new server, open System → Install server. It installs and configures the web, mail, DNS and database services one step at a time, checks that each step achieved what it was meant to, and can be resumed if it is interrupted.
3. Set the server identity — in Basic setup, the panel hostname and the mail hostname the server presents to the world.
4. Set your nameservers — ns1 and ns2 (and optionally ns3/ns4). These are shown to your customers and used when HostPane builds DNS zones, so point them at this server's IP at your registrar.
5. Run the Setup check and Readiness wizard — they score how ready the server is to host live sites and offer one-click installs for any missing subsystem (spam scanner, DNS backend, database engines and so on).
6. Enter your licence key on the License page — see Licensing.

When the readiness score is green, the server is ready to host. Turn on two-factor authentication for your own sign-in from Settings straight away.

Panel addresses

Once a panel hostname is set, Caddy serves each panel on its own pair of ports, reusing the hostname's certificate. The numbers follow the familiar hosting-panel convention, so customers moving from another panel type what they already know — even port plain HTTP, odd port HTTPS:

The short paths work on the panel hostname and on every customer domain, so theirdomain.com/cpanel takes a customer to their sign-in page — redirected to the panel hostname, the name the certificate is valid for. The bare hostname shows a neutral page rather than announcing which panel runs there. If you would rather the plain-HTTP ports never carry a password, set them to redirect to their HTTPS partner.

The conversion tool is separate: it listens on 127.0.0.1:8090 and is reached over an SSH tunnel (see Migrating in).

Accounts & packages

A package is a reusable plan — disk and bandwidth quotas, a set of enabled features (email, databases, DNS, backups, cron, shell access, applications), and optional CPU, memory and process limits. A hosting account is one customer, created from a package.

The usual flow:

1. In the administrator panel, open Packages and create a package. Set the quotas and toggle the features it includes.
2. Open Accounts and create a hosting account. Give it a username and primary domain, and pick the package.
3. HostPane provisions the Linux user, the home directory, and the account's metadata, then indexes it for fast search.

To help a customer, use “Log in to account” — an operator can step straight into any account's customer panel without knowing their password. You can also suspend an account (its sites and mail stop, but nothing is deleted) or terminate it, which requires a typed confirmation to prevent accidents.

• Resource limits — give a package a CPU percentage, a memory ceiling or a process limit and every account on it runs inside its own systemd slice, PHP and cron included. A package without limits leaves its accounts untouched.
• Bandwidth — counted exactly from the access logs, which HostPane also rotates; turn on enforcement to suspend an account when it reaches its package's limit, and reset its cycle in a click.
• Disk location — move an account's files to another mounted disk; its paths stay the same, so nothing that refers to it changes.
• Convert an addon domain to an account — split a domain out into its own account, with its site, mailboxes, forwarders, zone and the databases you choose.

Websites & apps

From the customer panel's Websites section, add a domain and HostPane does the rest in one step: it creates the DNS zone, writes the web server virtual host, and requests an automatic HTTPS certificate — no manual certificate juggling.

• Web server — sites run on NGINX by default. The operator can switch the server to Apache for customers whose applications rely on .htaccess; every site is rendered for Apache and config-tested before anything live changes, and the switch is undone if Apache does not come up. Caddy stays in front either way.
• PHP version — 7.4 through 8.5, a version per domain, each account running in its own PHP-FPM pool as its own user. Operators add a version from PHP versions with one click.
• Subdomains, aliases & redirects — add as many as you need; subdomains and parked/alias domains reuse the same one-step provisioning.
• Web application firewall — ModSecurity with the OWASP Core Rule Set, on NGINX or Apache, in detection or blocking mode, with a per-site opt-out.
• Site options — directory indexing, custom error pages, compression, hotlink and directory-password protection, and per-domain PHP settings.
• One-click apps — WordPress, Joomla, MediaWiki, phpBB and Nextcloud install onto an empty site with their own database. Each download is checked against a pinned checksum, and the app's own installer runs as the account, so a site is never left on a public setup page.
• Node.js and Python applications — the Application Manager runs an app as a systemd service under the account and proxies a URL path to it. It uses the Node.js or Python already installed on the server, and is enabled per package.
• Site security — each website gets an A–F grade from a read-only scan for files that should never be public, PHP in upload folders, outdated WordPress and PHP, and the panel's own protections, with the fix for each finding.

Certificates are issued and renewed automatically as long as the domain's DNS points at the server, so HTTPS “just works” once a site is live.

Email

Every account can run a full mail service. In the customer panel's Email section:

• Create mailboxes with per-mailbox quotas, plus forwarders, catch-all addresses, autoresponders and mail filters. Mailbox quotas are enforced by Dovecot.
• Set up authentication — HostPane manages DKIM keys and publishes the SPF and DMARC records for each domain, and a Deliverability check tells you at a glance what still needs publishing.
• Choose the spam engine — the operator selects either SpamAssassin or Rspamd server-wide; thresholds can be overridden per domain and per mailbox, with a Spam folder and optional auto-delete for each mailbox.
• BoxTrapper — a mailbox can accept mail only from its whitelist and hold the rest until the sender confirms. Confirmation requests are never sent for bounces, mailing lists, auto-replies or failed SPF, so the feature doesn't spray mail at forged senders.
• Email routing — tell HostPane when a domain's mail is hosted elsewhere (or that this server is its backup MX), so messages sent from the server itself — contact forms, order notices — reach the real inbox.
• Open webmail — customers read their mail in the browser, and one-click sign-in opens the right mailbox without re-entering a password.

For the operator: the mail queue, delivery tracking and sent-mail statistics, greylisting, DNS blocklists, a country filter for inbound mail, a per-domain hourly limit on outgoing mail, and where root's and the system users' mail goes.

DNS

HostPane runs authoritative DNS for the domains it hosts. The operator chooses the backend — BIND or PowerDNS — from server settings; one zone renderer feeds both, so the choice is invisible to customers.

• Edit records (A, AAAA, CNAME, MX, TXT, NS, SRV and CAA) from the customer panel's DNS editor; the apex SOA and NS records are generated for you, and the operator decides the starter records every new zone gets.
• Every change is validated before it goes live and rolled back if the zone doesn't check out.
• DNSSEC can be enabled per zone on either backend; HostPane signs the zone and shows you the DS records to publish at your registrar. On BIND, turning it off goes through an insecure phase first, so a DS record still at the registrar does not break the domain.
• An account with a dedicated IPv4 or IPv6 address gets its records repointed for you; secondary name servers you list receive zone transfers.

If you host DNS elsewhere, you can still run HostPane's web and mail features — just create the matching records with your external provider.

Databases

Customers create databases from the Databases page, backed by MariaDB and PostgreSQL.

• Create databases and database users, then grant a user access to a database — or do all three in one step with the database wizard. Names are automatically prefixed with the account to keep tenants separate.
• A web-based database admin tool is available for browsing and running queries in the browser.
• Remote database access can be granted to specific hosts when an application connects from another machine; the operator turns on remote connections for MariaDB on the Database server page.

For the operator, Database server shows and ends running connections, edits one validated settings file per engine, upgrades MariaDB (and PostgreSQL) with a full backup taken first and every step reported, adopts databases that were created outside the panel, and can place customer MariaDB databases on a separate database server.

HostPane never stores your plaintext database passwords; credentials are generated for you and shown once at creation time.

Backups

Backups use restic, so they're deduplicated and encrypted at rest. From the administrator panel's Backups page you configure destinations and schedules; customers can also back up and restore their own account.

• Configure local and/or remote destinations. The repository password is a server secret and is never exposed in the interface.
• Schedule regular runs; each run's success or failure is recorded as a time series you can watch on the dashboard.
• Restore any snapshot — pick a point in time and roll an account back to it.

Resellers

A reseller gets their own branded panel and a share of the server inside limits you set: how many accounts, domains and mailboxes, how much disk, and which actions they may take (create, suspend, terminate, modify, reset passwords, manage packages, edit branding).

• White-label — their name, logo, accent colour, page background, support details and their own nameservers in every zone of their customers.
• Their own tools — packages, reports, API tokens, their customers' DNS zones and mail queue, and the dedicated IPs you delegate to them.
• Sub-resellers — if you allow it, a reseller can create resellers of their own, one level down, whose caps and permissions always fit inside the parent's.

Migrating in

There are two routes in, and which one you want depends on whether you are moving a server or an account.

Converting a whole live server, in place

If the machine is already hosting customers under cPanel & WHM, DirectAdmin, CWP or Plesk, HostPane adopts it where it stands — no OS reinstall, no second server, and no customer data copied anywhere. cPanel, DirectAdmin and CWP keep accounts under /home/<account>, the layout HostPane uses too; Plesk keeps sites under /var/www/vhosts and mail in its own store, and HostPane serves them from where they already are. Either way adoption is bookkeeping rather than a file copy.

The work is split into two phases with your decision in between, and that split is the safety property:

1. Prepare is entirely additive. HostPane identifies the running panel, reads every account, domain, mailbox, database and DNS zone it owns, stages its own records, installs any missing packages and leaves them stopped, and copies every config it will later replace. Your existing panel keeps serving customers the whole time — you can run this in the middle of a working day and walk away having changed nothing.
2. The dry run examines the server and scores it: disk and memory, who holds ports 25, 53, 80 and 443, the real web, mail and DNS config tests, whether anything has changed since prepare, nameserver delegation, cron jobs that call the old panel's own tools, and the DNS TTLs your customers' domains publish — because a four-hour TTL means a rollback takes four hours to be visible, not four minutes. Findings carry a severity, and a blocker genuinely refuses the cutover; it is a gate, not a report.
3. Cutover is the one step that moves live traffic, so it is confirmed separately — twice, with the server's own hostname and then a phrase that states what is about to happen. Services switch in blast-radius order (DNS, then web, then mail), and the old panel is stopped and disabled so a reboot cannot bring it back alongside HostPane.

Mailbox passwords move across wherever the old panel stored them as hashes, so those customers keep the password they have. Plesk stores most mailbox passwords in a recoverable form rather than as a hash; HostPane does not carry those, keeps the mail, and tells you how many customers will need to set a new password.

Run it from the standalone converter rather than the panel itself. On a live server the old panel holds ports 80 and 443, so HostPane is not reachable from outside yet — and the cutover restarts the web tier, which would drop a wizard served through it at exactly the step you most want to watch. The converter listens on 127.0.0.1:8090:

sudo systemctl start hostpane-convert
sudo journalctl -u hostpane-convert        # prints the access link with its one-time token
ssh -L 8090:127.0.0.1:8090 root@<server>   # then open the printed link

Importing accounts from a backup

To move one customer rather than a whole machine, HostPane's importer reads a cPanel, DirectAdmin, CWP, Plesk or ISPConfig account backup and recreates the account, its domains, mailboxes and databases.

1. Copy the backup onto the HostPane server, under /var/hostpane/imports.
2. In the administrator panel open Migration, choose the source format and point it at the backup path, then Preview. HostPane parses the archive and shows exactly what it will create, along with any warnings.
3. Click Import. HostPane creates the account and provisions each domain, mailbox and database through the same validated, audited operations used everywhere else, then copies the site files, the mail and the database dumps in, where the backup format carries them. Fresh passwords are generated and shown once.

Contents are copied only from that staging folder, never following a link out of the account, and every file ends up owned by the account. Database dumps are restored with a temporary login that can reach only that one database. To move many accounts at once, the whole-server transfer discovers every account in a dump and imports them in one run, recording the outcome per account so one awkward account never abandons the rest.

Automation & billing

• REST API — everything under /api/v1, with bearer tokens for operators, resellers and customers. A token reaches only what its owner may: a reseller's token sees only that reseller's accounts.
• WHMCS — a server module ships with HostPane: create, suspend, unsuspend and terminate accounts, change password and plan, single sign-on into the customer panel through a one-time link, and disk and bandwidth usage updates.
• AI agents — turn on Agent access and an MCP client can use a fixed set of tools with a bearer token. Every tool that changes something accepts dry_run, which returns the checks, the steps and the exact request without touching the server. Terminals, restores, firewall changes and conversions are deliberately left out.
• Event webhooks — signed deliveries when accounts, domains, mailboxes, backups and alerts change, retried with back-off if your endpoint is down.
• Fleet view — add your other HostPane servers with read-only fleet tokens and see them all on one page.

Updating HostPane

Upgrading is the same command as installing — unpack the new bundle and run it. As root:

# Unpack the new bundle, verify it, and run the installer again
tar xzf hostpane-<version>-linux-x86_64.tar.gz
cd hostpane-<version>-linux-x86_64
sha256sum -c SHA256SUMS && sudo ./install.sh

# Check the installed version at any time
hostpane --version

The installer restarts the daemons that were already running, so the version you just installed is the version being served — a server that keeps answering on the old code while reporting the new one is the failure this avoids.

Service configuration is regenerated safely: HostPane writes new configs to a temporary location, validates them, swaps them in atomically, and reloads the affected service — reverting to the last-good version if anything fails validation. A config change can't leave your web or mail server running a broken config.

Signing in

• Operators — root and members of the hostpane-admin Linux group sign in with their Linux passwords. The password is checked by the root helper without ever crossing to the web application in plain text, and repeated failures pause that user. Panel-only administrators can be kept or switched off.
• Single sign-on — connect the panel to Google Workspace, Microsoft Entra ID, Okta, Keycloak, Authentik or any OpenID Connect provider. An identity signs in only to the panel user it has been linked to, and the panel's own two-factor check still applies.
• Customers sign in with their account's password — the same one they use for FTP and SSH — and resellers with their own.
• Two-factor authentication (TOTP) is available to everyone, and the sign-in pages share one brute-force firewall.

Security model

HostPane is built around a two-process architecture, and understanding it explains most of how the product behaves.

• The web application runs unprivileged. It holds your sessions and renders the panels, but it can't write system files or run privileged commands directly.
• A separate root helper listens on a local socket and accepts requests only from the web app's user. It performs every privileged action, and it re-validates every input — it never trusts what the web layer sends.
• Changes are validate-then-apply: a new config is checked against a temporary copy before the live file is replaced, with automatic atomic rollback to the last-good version on failure.
• Every state-changing action is written to an audit log, and tenant isolation is enforced so one account can never read or touch another's data.

Passwords are hashed before they ever cross the internal socket, external commands never run through a shell, and user input only reaches a config through single-path validators. The result is a panel that stays honest even if one layer is compromised.

Licensing

Enter your licence key on the administrator panel's License page. HostPane then fetches a lease from the licence server (license.hostpane.com): a short statement, signed by us, that your licence is active on this server until a given time. The panel checks the signature itself with a key built into the release, so it needs nothing else to trust it.

• A lease lasts seven days and is refreshed twice a day. If our licence server is unreachable, the lease you already hold keeps working — an outage on our side changes nothing for a week, and the panel warns you three days before a lease would run out.
• Without a valid licence, only the administrator and reseller panels lock (to the License page). Customer panels, websites, email, DNS and webmail keep running — your customers never notice a licensing problem.
• A licence is bound to one server. To move it to new hardware, release it from the customer portal — where you can also see and pay invoices — or ask us.

Getting help

Stuck, or want a hand planning a migration? We're happy to help.

• Contact us — reach the team for support, sales and onboarding questions.
• The blog — release notes, deep-dives and how-to walkthroughs.
• The built-in Help & Guides hub inside every panel — searchable, task-focused guides right where you're working, with an explainer on each feature page.
• For your customers, the support assistant at the top of their Help page answers questions from what the panel can check about their own account, and says plainly what it could not check.

Every panel also links its own guide from each feature, so the answer is usually one click from the thing you're trying to do.