Cluster and cloud servers

#Overview

Both features live under Server Admin → System and are available to the server administrator only:

The Community edition does not include the cluster or cloud servers. If a Pro license lapses, an existing cluster keeps working: DNS sync and health checks continue, and members can be removed. Linking new servers, creating and moving accounts in the cluster, database placement and sending configuration need a valid Pro license. See Pricing to compare editions.

#How a cluster is organized

The server that adds the others is the primary server; the servers it adds are members. The primary manages roles, the links between members, configuration sync and account placement. Members also connect directly to each other, and each member pushes its own DNS changes to every server with the DNS role.

Each server gets one or more roles:

Default roles are suggested from what the server can do (for example dns when a nameserver is installed). The Cluster page has these tabs: Servers, DNS cluster, Configuration, Database servers, Accounts and Log.

#Adding a server

Servers are linked with API tokens in both directions over HTTPS with certificate pinning:

1. On the server to add, open Cluster → Link this server to a cluster → Create key. The link key is single-use and valid for 1 hour; the same screen shows that server's certificate fingerprint.
2. On the primary, choose Add a server to the cluster, enter the Server Admin address of the other panel (for example https://server2.example.com:2087, no path) and click Read certificate to see its SHA-256 fingerprint.
3. Check that the fingerprint matches the one shown on the other server, enter the key, a display name and the roles, then click Add to cluster.

Pinning means self-signed certificates are safe to use: if the certificate does not match the pinned fingerprint, the connection is closed before any data is sent. When a certificate is renewed, the new fingerprint is announced to members over the authenticated channel. On an unexpected change the server is flagged as "certificate changed", and you compare and confirm the new fingerprint on the Servers tab.

#Health checks

Servers are polled every minute; version, load, memory, free disk, account count and service status appear on the Servers tab. After two failed checks in a row a server is marked unreachable and a notification is raised.

#DNS cluster

The zones of every server are served authoritatively on all members with the dns role. Zone changes go out within about 10 seconds, with an additional sync every 5 minutes and a full sync every hour. There are two methods:

The secondary-zone component is optional and is installed from Server Admin → System → Components; when the requirements are not met, that pair of servers falls back to API push. If a zone already belongs to an account on another server, the receiver leaves it alone and records a conflict. Zones of suspended accounts are not sent. For DNS on a single server see DNS.

#Configuration sync

The primary can sync these setting groups to members: packages, feature lists, DNS zone templates and nameservers, security settings (brute-force protection, admin IP allow list, mandatory 2FA for admins, password age), PHP defaults, and branding.

• Pick the Setting groups to sync and save; with Send changes automatically on, changes go out on their own.
• The first sync to a member is previewed with Show differences and confirmed with Apply.
• Individual items can be opted out per member on the primary, or locally by the member's own administrator.
• Members validate every value themselves and skip anything invalid in their environment (such as a PHP version that is not installed), returning a warning. Branding is applied only on members whose license includes white label.

#Remote database servers

When the cluster has a server with the database role, the Database servers tab sets, per engine, which server holds an account's MySQL or PostgreSQL databases, and databases can be moved between servers. Database users can connect only from the IP addresses of the matching web server, and each server can manage only the objects of its own accounts.

Users manage these databases in the user panel under Databases → Remote Databases, which appears when the cluster includes a database server and the feature is enabled in the package. Remote databases are included in account backups. More in Databases.

#Account placement and moves

The Accounts tab lists every account in the cluster with its server. From the primary, Create an account in the cluster opens an account on any server with the web role, and accounts can be suspended, unsuspended or terminated from the same list.

To move an account, the source server takes a full backup (files, databases, email, DNS, panel records); the target pulls the archive over the pinned connection, recreates the account under the same name and replaces the source server's IP address in its DNS records with its own. The target must have the web role. Afterwards the source account is suspended (default), deleted or left as it is, depending on your choice. For single-server backups and migrations from other control panels see Backups and migration.

#Removing a member

The primary can remove a member, and a member can leave the cluster on its own. If a server hosts database objects for other servers, or its accounts keep databases on another server, the action stops and asks you to move those databases first. A forced removal from the primary deletes the records while the data stays on that server. The cluster log is kept for 30 days.

#Cloud servers

Server Admin → System → Cloud Servers creates servers on Hetzner Cloud, DigitalOcean, Vultr, Linode and AWS EC2. Its tabs are Servers, Provider accounts, SSH keys and Settings. Provider tokens are stored encrypted. The page only calls the providers' APIs, so it works on native server installations as well as Docker/Railway container installations.

#Creating a server

Choose the provider account, region, size (with its price), OS image, server name, fully qualified host name (FQDN), admin email and an SSH key (existing or newly generated). Images: Ubuntu 24.04 and 26.04 LTS, Debian 12 and 13, AlmaLinux 9 and 10, Rocky Linux 9 and 10.

On first boot, cloud-init runs the bipanel installer unattended while the panel tracks install progress and waits for the new panel to respond. When it finishes, the initial admin password is changed and the login details are shown. For the install flow itself see Installation.

#Joining the cluster automatically

With the join option on, the new server receives a single-use join token valid for 48 hours plus this panel's certificate fingerprint. After installation it contacts this panel, and the normal linking steps complete without entering a key by hand. The option is unavailable while this panel is a member of another cluster.

#Server actions

Created servers can be started, stopped, rebooted, resized, snapshotted and deleted (the details of resizing and snapshots vary by provider). Deleting requires typing the server name; you can also keep the server at the provider and only remove it from the list.