Update forces bootstrap reinstall

Issues
1

Issue Description

When I grab the latest release with foundationdb, I rename it to stalwart, as the old binary was for some reason, ensure its executable, it starts and makes me have to go through the entire bootstrap process again. Had to roll back to earlier snap shot. Already on 16.x

Expected Behavior

Upgrade just fine

Actual Behavior

Bootstrap

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

FoundationDB

Blob Storage

S3-compatible

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Bootstrap mode is only entered when Stalwart cannot find config.json at the path it’s told to load, not because of the binary itself. Renaming a downloaded release binary to stalwart and dropping it in place doesn’t change any config, so if you’re hitting the bootstrap wizard on every upgrade, the running process almost certainly isn’t being pointed at your existing config.json.

A few things worth checking:

  • Confirm you’re starting the binary the same way the installed systemd service does. The default install places the config at /etc/stalwart/config.json and starts the service with --config=/etc/stalwart/config.json (see the systemd unit in the Linux install docs). If you’re running the new binary manually (e.g. testing it before swapping the service binary) without passing --config (or the CONFIG_PATH env var), Stalwart won’t find your existing file and behaves as a fresh install.
  • Since you’re on FoundationDB, make sure you’re actually running the FDB-enabled build, and that the FDB client library your system has installed matches what the binary expects. Stalwart ships a separate FDB build specifically because client library mismatches across versions can break existing FDB-backed deployments, so a plain non-FDB binary swapped into an FDB install would fail to reach the store and could appear to “reset.”
  • Verify the stalwart user still has read/write permission on /etc/stalwart/config.json and the FDB cluster file after the binary swap; permission or ownership issues from the rename/copy process can also make the file effectively invisible to the process.

If after checking the exact --config path, the FDB build, and file permissions the wizard still appears with all three verified correct, that would point to a genuine bug worth flagging, but the documented trigger for bootstrap is strictly “no readable config.json at the path the process is started with.”

Reference: Bootstrap mode | Stalwart and Linux / MacOS | Stalwart

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Everything is setup as the bot said

4

Bootstrap re-runs only when Stalwart can’t open its existing config store at startup, so what’s happening is that the new binary isn’t being pointed at the same configuration and data it had before. Two things to check.

First, start it the way the service does, pointing at the same config: it needs --config /etc/stalwart/config.json (the systemd unit passes this for you). Running the renamed binary by hand with no --config or CONFIG_PATH is what drops it into a fresh bootstrap. Replace the binary in place and start it through the same service unit, and leave /etc/stalwart/config.json, /etc/stalwart/stalwart.env and /var/lib/stalwart/ untouched.

Second, make sure you downloaded the FoundationDB build (the stalwart-foundationdb artifact), not the default binary. The default has no FoundationDB support and can’t open your data store, which also sends it straight into bootstrap.