InterWorx ships native clustering — a feature cPanel still does not match — which lets you front a single SiteWorx tenancy across multiple servers, replicate DNS, and split mail or web load across nodes. The setup is short but the choices around quorum IP and Cluster Manager role carry through the lifetime of the cluster, so it is worth getting right on day one.

This guide designates a Cluster Manager, walks through the quorum IP decision, generates a node API key, and joins a second node. Migrating from cPanel? Cluster after the import is done, not during.

Architecture in one paragraph

InterWorx clustering is Cluster Manager (CM) plus N nodes, not multi-master. The CM holds authoritative configuration and pushes to nodes; nodes serve traffic. DNS replicates automatically; web and mail can be split per node or co-located. If the CM goes down, nodes keep serving existing traffic but you cannot make config changes until it returns. Plan for CM recovery accordingly — snapshot the CM VM, or keep a warm standby ready to promote.

Designate the Cluster Manager

Pick the server that will hold authoritative state. This is typically the server you already use as the primary, with the most existing accounts. In NodeWorx on that server, go to Server → Clustering → Cluster Manager and click Make This Server the Cluster Manager.

InterWorx prompts for the quorum IP.

Choosing the quorum IP

The quorum IP is the address every node uses to confirm "the cluster is healthy and the CM is reachable". Two rules:

It must be stable — the same IP for the life of the cluster.
It must be reachable from every node over the management network at all times.

In almost every deployment the right choice is the CM's primary management interface IP — the one you SSH to. Do not use:

A floating or VRRP IP that may move between hosts (the quorum check is exact-match on the IP, not the hostname behind it).
A public IP if your nodes communicate over a private LAN (the check goes over whichever interface routes to the IP).
A NAT'd IP (the CM sees one address, nodes see another).

Pick the LAN-side, statically-assigned, never-changing IP of the CM. Enter it and save.

Generate a node API key

For each server you intend to join, the CM needs to issue an API key. In NodeWorx on the CM go to Server → Clustering → Nodes → Add Node. Enter the joining node's hostname and a friendly label. InterWorx generates a key — a long random string. Copy it.

Generate one key per joining node. Do not reuse keys across nodes — revoking a key (when retiring a node) should not orphan other nodes.

Join the new node

On the joining server install InterWorx as normal but do not import accounts onto it yet. Activate its own InterWorx license — cluster nodes each need a license.

In NodeWorx on the new node go to Server → Clustering → Join Cluster and enter:

Cluster Manager hostname — FQDN of the CM
Node API key — the value copied above
Quorum IP — the same IP set on the CM

Submit. The node negotiates with the CM over HTTPS, validates the quorum IP is reachable, and joins. Within ~30 seconds it appears in the CM's Nodes list with status Online.

Verify cluster health

From the CLI on the CM:

nodeworx -u admin -n cluster -a status

Expected output lists each node with state: online. Anything else — unreachable, quorum_failed, key_invalid — is a network or config problem, not a transient state.

DNS replication runs immediately. Create a test zone on the CM, then on the node check:

ls /etc/bind/zones/   # or wherever your build keeps them

The zone should appear within seconds.

Split services across nodes

By default a joined node serves the same workload mix as the CM. To split — for example, mail-only on one node, web-only on another — set the node's role in NodeWorx Server → Clustering → Nodes → [node] → Roles. Disabling a service stops it on that node; the CM stops directing traffic for that service to it.

Common patterns:

CM serves admin and DNS; web nodes serve HTTP/PHP; a dedicated mail node serves SMTP/IMAP.
CM also serves web; second node serves only as a hot DNS replica.

Limitations to design around

CM is a single point of failure for control-plane operations. Existing traffic continues if the CM goes down, but no new accounts, DNS changes, or config edits until it returns. Treat CM uptime as critical.
No automatic CM failover. Promoting a node to CM is a manual procedure — document it as a runbook before you need it.
Cluster size practical limit is small. InterWorx clusters scale to a handful of nodes well; beyond ~8-10 nodes the CM becomes a bottleneck. For larger scale, partition into multiple clusters.

What IP should I use as the InterWorx quorum IP?+

The Cluster Manager's stable LAN-side management IP — the address you SSH to. Do not use a floating/VRRP IP, a NAT'd address, or any IP that could move between hosts. Changing the quorum IP later requires rejoining every node.

Does InterWorx clustering give me automatic failover?+

No. The Cluster Manager is a single point of failure for control-plane changes (new accounts, config edits). Existing web and mail traffic on nodes keeps serving if the CM goes down, but promoting a node to CM is a manual procedure.

Do I need a separate InterWorx license for each node?+

Yes. Every server in the cluster — Cluster Manager and each node — needs its own license. There is no aggregated cluster license discount as standard, though volume pricing applies.

How many nodes can an InterWorx cluster support?+

There is no hard cap, but the practical sweet spot is up to 8-10 nodes per cluster. Beyond that the CM becomes a configuration bottleneck — partition into multiple clusters instead of scaling one further.

Next steps

Compare clustering availability across panels: InterWorx vs cPanel.
Bring existing accounts onto the cluster: migrate cPanel to InterWorx.
Activate licenses for additional nodes from the InterWorx license page.

Set up InterWorx clustering with a Cluster Manager