Domino server topology

The Domino Helm chart deploys HCL Domino as a set of servers, each with a distinct role. This topic explains what gets deployed, how the servers are named, and how the topology changes between a high-availability and a single-zone deployment.

Servers and roles

Every Domino server is a separate StatefulSet with its own data PVC and Service. Servers are grouped by role (type):

Role (`type`)	Purpose
`admin`	Bootstraps the Domino domain (One-Touch Setup), hosts the OIDC provider (`auth.<domain>`) and admin endpoints. Exactly one per deployment.
`srvmgr`	Server manager — directory and replication routing.
`files`	Serves NSF databases over NRPC and HTTPS (`files.<domain>`).
`mail`	Mail, calendar, contacts, IMAP, DRAPI, and Traveler. See Mail clusters.
`ontime`	OnTime Group Calendar (`groupcal.<domain>`).
`smtp`	Outbound SMTP gateway.
`iq`	Dedicated Domino IQ server(s).
`ldap`	LDAP proxy — NRPC and LDAPS (636).

The server set is defined under servers: in the values file. Each entry is one server.

Server names

Server names follow the pattern dom-<role><NN><zone>:

<role> — the role, for example mail or files.
<NN> — the instance number of that role, 01, 02, and so on. A new number is a new independent unit (for mail, a new mail cluster).
<zone> — a letter, a or b, identifying the Availability Zone the server belongs to. A role deployed for high availability has one server per zone: dom-mail01a and dom-mail01b are the two replicas of the first mail cluster.

The admin server is dom-admin01a. Its zone b counterpart, dom-admin01b, is the server manager (type: srvmgr), not a second admin server.

Default topology

The chart's default servers: map deploys a full high-availability topology — 18 StatefulSets, most roles paired across two zones:

Role	Servers	Count
`admin`	`dom-admin01a`	1
`srvmgr`	`dom-admin01b`	1
`files`	`dom-files01a` – `dom-files01d`	4
`mail`	`dom-mail01a`, `dom-mail01b` (cluster 01) `dom-mail02a`, `dom-mail02b` (cluster 02)	4
`ontime`	`dom-ontime01a`, `dom-ontime01b`	2
`smtp`	`dom-smtp01a`, `dom-smtp01b`	2
`iq`	`dom-iq01a`, `dom-iq01b`	2
`ldap`	`dom-ldap01a`, `dom-ldap01b`	2

Per-role resource requests, limits, and volume sizes are in System Requirements. Adjust the server list and sizes in your environment values file to match your deployment — see Scaling and adding capacity.

High availability

Application-level high availability is provided by running paired servers (a and b) across two Availability Zones. A three-zone configuration is required for Kubernetes control-plane quorum. See High Availability in the architecture topic.

The chart keeps a role's pair on separate nodes:

podAntiAffinity.enabled (default true) — prevents two servers of the same role from scheduling on the same node.
servers.<name>.requireNodeLabels — pins a server to nodes carrying a label, for example {topology.kubernetes.io/zone: zone-a} on the a server and zone-b on the b server. Anti-affinity stays active, so the pair also spreads across nodes within the zone.
servers.<name>.nodeSelector — pins a server to one specific node. Setting this disables anti-affinity for that server.

Routing across a pair is handled at the APISIX layer (failover upstreams, per-user routing via dom-router) — see Default routes.

Single-zone (non-HA) topology

For a deployment without zone redundancy, reduce the server set:

Set enabled: false on the zone b servers of each role you do not need paired (dom-files01b, dom-ontime01b, dom-ldap01b, and so on), and on the second mail cluster (dom-mail02a, dom-mail02b).
dom-admin01a and one mail, files, ontime, smtp, iq, and ldap server is the minimum functional set. srvmgr (dom-admin01b) is recommended even in a single zone.
With one node per role there are no anti-affinity guarantees to satisfy; podAntiAffinity can stay enabled (it only takes effect when a role has more than one server).

A server left with enabled: false and register: true is still pre-registered in the Domino domain, so it can be brought up later with a single helm upgrade — see Incremental deployment.

Mail clusters

A mail cluster is one replicated pair of mail servers — dom-mailNNa and dom-mailNNb — holding the same set of user mail files across two zones. Each user's mail file is homed on one cluster; mobile and web clients are routed to that user's home mail server by the dom-router plugin, with failover to the paired server.

The default topology ships two mail clusters (01 and 02). Additional clusters are added as capacity grows — see Adding a mail cluster.

Mobile access and Traveler

Traveler runs as a task on the mail servers — there is no separate Traveler server role. Mobile clients reach Traveler at mobile.<domain>/traveler and are routed to the user's home mail server the same way web mail is, with the same mail-cluster failover described above.