Setting up a Seq HA Cluster

This page is an overview of setting up a new HA cluster from scratch. See Migrating Legacy DR Clusters to HA or Converting a Standalone Seq Instance into a Cluster for alternative instructions in those cases.

What you'll Need

To configure a Seq cluster you will need:

A clustering-compatible Seq subscription or trial certificate
An HTTP load balancer
Hardware or virtual machines for the Seq nodes
A cluster state database , either Microsoft SQL Server or PostgreSQL
An additional Seq instance, or hardware to deploy one, for cluster monitoring and diagnostics

We recommend that you review these instructions in full before starting to configure the cluster.

Cluster Components and Connectivity

The diagram below shows the major elements of a Seq cluster.

The Seq UI is served to users by the Cluster Load Balancer , which also handles ingestion traffic from applications. The load balancer is normally reached at a single address - for example https://seq.example.com - known as the Load Balancer URI.

In some deployment scenarios, the load balancer listens at a second address, the Load Balancer Ingestion URI - for example https://seq.example.com:45341 - which forwards to the Seq nodes' dedicated ingestion ports. See URLs for further information about Seq's ingestion port feature.

The cluster load balancer can also be used for HTTPS termination, if desired. To eliminate the load balancer as a single point of failure, a pool of highly-available load balancers can be used if required.

The load balancer forwards traffic to a pool of identical Seq Nodes . Each node listens for load balancer traffic on its Node Listen URI, which is normally the node's public HTTP or HTTPS address, for example http://node01.seq.local. Within the cluster, Seq nodes listen on, and forward HTTP traffic to one another using, their Node Internal API URI. This is normally the same as the node listen URI.

Seq nodes participate in data replication and work sharing using WebSocket connections to their Node Cluster URI, which is a ws:// or wss:// URL resembling ws://node01.seq.local:5344.

Each Seq node carries its own node-local storage. On Windows, this defaults to the C:\ProgramData\Seq folder, and under Docker/Linux this is the /data volume mount. Seq stores application data, indexes, backups, and plug in app packages in this location. Each node must have enough local storage for a full replica of the cluster data.

Node-local storage should use a high-performance block device, for example SSD/NVMe disk, or the available equivalent. Node local storage must be exclusive to the node: file shares cannot be used.

Cluster nodes store configuration data including API keys, users, signals, alerts, and dashboards in the Cluster State Database . Both Microsoft SQL Server and PostgreSQL are supported for this purpose. The database serves as a consensus broker for cluster state changes, and should therefore be located close to the cluster nodes (minimizing network latency). To eliminate the cluster state database as a single point of failure, it can be deployed in a high-availability configuration if desired.

Finally, a separate, standalone Seq instance should be deployed as the Cluster Diagnostic Instance to retrieve performance data and error reports from the Seq cluster nodes. A diagnostic instance can greatly simplify troubleshooting cluster problems and tuning performance. Traffic to the diagnostic instance is minimal: it can be deployed on a significantly smaller machine than the cluster nodes it monitors.

Configuration Worksheet

Copy the table below and fill in URI values in advance to help prevent configuration mistakes during deployment. Instructions will use bold when referring to an item name from the configuration worksheet.

Item	Description	Value
Diagnostic Instance Ingestion URI	The address at which Seq nodes can send OTLP data to the cluster diagnostic instance. For example, `https://diagnostics.seq.local/ingest/otlp`. Both cluster nodes and human operators need to be able to reach the diagnostic instance via this URI.
Load Balancer Ingestion URI	The address to which applications can send logs and traces to the Seq cluster. Usually, this will be the same as the Load Balancer URI, for example, `https://seq.example.com`. If a separate ingestion port is being configured, this will be a URI matching the ingestion port.
Load Balancer URI	The address at which applications and users of the Seq instance can access its UI, API, and regular ingestion endpoint. For example, `https://seq.example.com`.
Node Cluster URI	For each node, the cluster-internal WebSocket endpoint at which other nodes can reach it. For example, `ws://node01.seq.local:5344`. This should ideally follow a regular format based on the node name, e.g. `ws://{name}.seq.local:5344`. The `wss://` scheme should be used if TLS is configured. Nodes broadcast this value to each other.
Node Internal API URI	For each node, the cluster-internal HTTP endpoint at which other nodes can reach it. This must use a different port from the Node Cluster URI. Usually, this will be the same as the Node Listen URI, for example `http://node01.seq.local`. This should follow a regular format based on the node name, e.g. `http://{name}.seq.local`. Nodes broadcast this value to each other.
Node Listen URI	For each node, the HTTP endpoint that receives traffic from the cluster load balancer. For example `http://node01.seq.local`. This should follow a regular format based on the node name, e.g. `http://{name}.seq.local`.

In later steps you will also need to record:

Item	Description	Value
Admin Username	The username for the default administrator account. The instructions set up username/password authentication: the authentication provider can be switched afterwards.
Cluster State Database Connection String	A connection string containing credentials for Seq nodes to connect to the cluster state database.
Diagnostic Instance API Key	An API key that allows ingestion of performance data, error, and trace information from the Seq nodes into the cluster diagnostic instance.
Initial Admin Password	The initial password for the admin user account.
Secret Key	A symmetric encryption key shared by cluster nodes. The authentication key used for cluster networking is derived from the secret key.