Stalwart - two node setup with foundationdb - is it possible?

Questions
1

Your question

I have configured a foundationdb cluster across two different geographic regions. The same for a GarageHQ S3 solution for blob.

I configured one Stalwart node, and pointed it to the foundationdb and S3 nodes on that site.

However, when I want to install the second node, the bootstrap installer says the data store already was initialized.

Can I overcome this and have the second node working? Or do I need to have the second node as part of a Stalwart cluster?

I thought it was possible to use autonomous nodes pointing to the same storage…

2

The “bootstrap already initialized” error is actually expected and correct behavior – it means your storage is already set up and the second node should not run the bootstrap installer again. You just need to point the second Stalwart node at the same FoundationDB + S3 storage backends and configure it as a cluster member.

Here’s the correct approach:

  1. Skip bootstrap on the second node. The bootstrap wizard only needs to run once for a fresh data store. Since node 1 already initialized it, node 2 should be configured directly (via config/WebUI) to point to the same FoundationDB and S3 endpoints.

  2. Ensure unique hostnames. Each node must have a unique OS hostname (or set the STALWART_HOSTNAME environment variable). When a node starts, it acquires a node-ID lease using its hostname – two nodes sharing the same hostname will conflict and cause data inconsistencies.

  3. Configure a coordination mechanism. Multiple Stalwart nodes sharing the same storage also need a coordination layer so they can exchange real-time state (IMAP IDLE, push notifications, security blocks, TLS cert distribution, etc.). Stalwart supports peer-to-peer (via Eclipse Zenoh, no extra infra needed), NATS, Kafka/Redpanda, or Redis. For a two-node setup, peer-to-peer is the simplest option. This is configured via the Coordinator object (Settings > Cluster > Coordinator in the WebUI).

So in short: yes, autonomous nodes pointing at the same storage is the intended design, but they do need the coordination layer to behave correctly as a cluster. The bootstrap error is not a blocker – it’s just telling you the store is already ready.

Relevant docs:

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

3

But I want to use different S3 and directory nodes for each of the cluster nodes…

4

The architecture documented for Stalwart clustering treats the storage backends (FoundationDB, S3/blob) as shared, cluster-wide singletons – all nodes point to the same logical storage layer. The docs don’t describe a per-node storage configuration where different nodes use entirely separate, isolated S3 or FoundationDB instances.

What you’re describing – geographically separate S3 and FDB clusters with each Stalwart node using only its local region’s storage – is not a supported configuration pattern in the current docs. The clustered deployment diagrams consistently show all nodes converging on a single shared storage tier (metadata + blobs). FoundationDB’s own multi-region support (which you’re already using) is the intended mechanism for distributing data across geographic regions at the storage layer, while all Stalwart nodes still point to the same FDB cluster endpoint.

For the blob store specifically, GarageHQ is explicitly called out in the docs as a self-hosted option well suited for multi-site, fault-tolerant setups – and GarageHQ itself handles geo-replication internally. So the intended design is: one logical GarageHQ cluster (multi-region internally) + one logical FoundationDB cluster (multi-region internally), with all Stalwart nodes pointing to those shared endpoints.

If your goal is to have Stalwart node 1 write blobs only to region-A S3 and node 2 write only to region-B S3, that would require a configuration the current docs don’t cover.

Relevant docs:

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.