Overview
Running Stalwart in a clustered environment is flexible. The server was built from the start for distributed deployments, so horizontal scaling and high availability require little extra configuration.
Node ID
Each Stalwart instance in a cluster must have a unique identifier that distinguishes it from other nodes. The identifier drives coordination, logging, and internal message routing.
Coordination mechanism
Stalwart requires a coordination mechanism to enable communication between nodes in a cluster. Coordination allows nodes to exchange internal updates, detect failures, and remain synchronised during operation. For a full overview of how coordination works and the available options (peer-to-peer, Kafka, NATS, and Redis), refer to the Coordination section of this documentation.
Load balancing
By default, Stalwart derives the server hostname from the underlying system hostname during installation. The hostname appears in protocol responses, logs, and internal identification. When Stalwart is deployed behind a load balancer, all backend nodes should use a consistent hostname that matches the public-facing identity of the service. This keeps client communications and protocol-level interactions uniform, particularly for protocols such as SMTP that expose the server hostname during the handshake.
Roles
In a clustered deployment, background and maintenance tasks must run regularly to keep the system healthy and secure. To distribute this operational workload across the cluster, Stalwart models each role as a named profile applied to one or more nodes.