An ISPConfig server usually starts life doing everything: websites, mail, DNS and databases on one machine. That works until mail filtering starts competing with busy websites for memory, or a single outage takes down websites, email and name resolution at the same moment. An ISPConfig multiserver setup splits those roles across several servers, while you keep managing all of them from one web hosting control panel. This guide explains how it works, which roles are worth separating first and what to plan before the ISPConfig installation, so the split does not create new weak spots.

How an ISPConfig multiserver setup works

In multiserver mode one machine is the ISPConfig master server. It runs the control panel and holds the main ISPConfig database. Every other server runs its own ISPConfig installation that joins the setup and takes only the roles you give it, such as web, mail, DNS or database. When you create a website or mailbox in the panel, the change is written to the master database, and the server responsible for that role picks it up through a regularly scheduled job and applies it locally.

Two consequences follow. First, every joined server needs database access to the master, so that connection has to be allowed through the firewall, and only from your own servers. Second, the master is where changes are made, but it does not carry the traffic of the other servers. If the panel is down, websites, mail and DNS on the other machines keep working; you simply cannot change anything until the master returns.

Which roles to separate first

You do not need a server per role on day one. A sensible order for most small hosting companies and agencies:

  1. A secondary nameserver. DNS is the simplest role to split and the one with the clearest benefit. With a secondary nameserver in another location, domains keep resolving when the main server is down, and registrars expect at least two nameservers anyway.
  2. A separate mail server. Spam filtering with Rspamd, virus scanning and large mailboxes use memory and disk in bursts. Moving mail to its own machine keeps a spam wave from slowing websites, and gives the mail server its own IP address and sending reputation.
  3. Additional web servers. Once sites outgrow one machine, new web servers can be added and new clients placed on them. Existing sites stay where they are unless you move them.
  4. A dedicated database server, for workloads where large databases compete with PHP for memory.

Once there are three or more servers, a small panel-only machine as the master is a common choice, because panel updates then never touch a server that serves customers.

Mirrored servers for redundancy

ISPConfig can also mark one server as a mirror of another. The mirror receives the same configuration, which is the standard way to build the secondary nameserver: an ISPConfig mirror server for DNS carries every zone created in the panel automatically. Mirroring web or mail servers is possible too, but the configuration is only half of the job. Website files, databases and mailboxes also have to be kept in sync by other means, such as file synchronization and database replication, and that adds moving parts. For most small setups, a mirrored DNS server plus reliable backups of the web and mail servers is the right balance.

Planning before the ISPConfig installation

The official ISPConfig autoinstaller builds each server and can leave out roles a machine does not need, for example installing a web server without mail or DNS. Servers that join an existing setup are installed in the installer's expert mode, which asks whether the server should join a multiserver setup and for the master's database details. Before running it anywhere, settle these points:

  • Hostnames. Each server needs a fully qualified hostname such as mx1.yourdomain.com, with an A record pointing to its public IP address, and the servers must be able to resolve each other's names.
  • Private networking. If your servers sit at the same provider, let them talk over a private network and allow the master's database port only from those addresses.
  • Reverse DNS for the mail server. Its IP address should resolve back to its hostname; your hosting provider sets this.
  • Supported systems. Use a release the installer supports for the ISPConfig version you install. The autoinstaller targets Debian and Ubuntu LTS releases, and ISPConfig 3.3.1 added support for Debian 13.
  • The same version everywhere. All servers in the setup should run the same ISPConfig version.

This planning is the part of an ISPConfig installation that saves the most time later, because hostnames, networks and roles are awkward to change once clients are live.

ISPConfig configuration after the servers join

Once every server appears in the panel, ISPConfig configuration continues in the server settings: which web server receives new sites by default, which mail server handles new mail domains and which DNS server holds new zones. Then comes the checklist that makes the setup trustworthy:

  • DNS configuration with templates that point new domains at the right web and mail servers from the start.
  • SPF, DKIM and DMARC for every mail domain, so receiving providers trust the separate mail server.
  • Monitoring for each server, not just the master, including disk space, mail queue length and certificate renewals.
  • Backups on every server that holds data, with a restore tested for each role.

For updates, the usual order is the master first, then the other servers one at a time, checking in between that pending changes are processed. The panel shows changes that are still waiting to be applied, which is also the first place to look when a new site or mailbox does not appear on its server.

Frequently asked questions: ispconfig multiserver setup

Can an existing single ISPConfig server become a multiserver setup?

Yes. The existing server becomes the master and new servers join it. Moving existing websites or mailboxes onto the new servers is a separate step that needs planning, because data has to be copied and DNS records changed.

Do all servers need to be at the same hosting provider?

No, but it helps. Servers in different locations must reach the master's database over the internet, which requires tight firewall rules and encrypted connections. The secondary nameserver is the role that benefits most from being somewhere else.

What happens to websites if the master server goes down?

Websites, mail and DNS on the other servers keep running. Only the panel and changes that have not been applied yet wait until the master is back.

Considering a split, or a first ISPConfig server for your business or agency? Our ISPConfig installation and configuration service covers single-server and multiserver setups on Debian or Ubuntu, including the mail server, DNS and backups. For the DNS side on its own, see our DNS server configuration service. Contact us with a short description of your current server and what it hosts.