SELF-HOSTING.md

@@ -202,6 +202,36 @@ relay reads an older database and brings it forward. Take a dump first anyway,
 not true, and an older relay against a newer database is not a supported
 direction.
 
+### One step by hand for older SQLite relays
+
+This is for a relay on SQLite (no `FN_POSTGRES_URL`) that was already running
+before 25 September 2026. Postgres relays can skip it, and so can a SQLite relay
+first started after that date.
+
+When email verification was added, the upgrade was meant to mark every account
+that already existed as verified, so that switching verification on later
+would lock nobody out. On SQLite that step failed without an error and marked
+nobody. Nothing changes until you set `FN_EMAIL_VERIFICATION_REQUIRED`. Once
+you do, everyone who signed up before that upgrade is turned away and asked for
+a code from an email that was never sent.
+
+The relay now does this correctly, but each upgrade step runs once, and a relay
+that already ran the broken one will not run it again. Stop the relay, copy
+`relay.sqlite` somewhere safe (it is wherever `FN_DB` points, if you set it),
+open it with `sqlite3 relay.sqlite`, and run:
+
+```sql
+UPDATE users SET email_verified_at = CURRENT_TIMESTAMP
+WHERE email_verified_at IS NULL
+  AND (created_at IS NULL OR created_at <= (
+    SELECT created_at FROM _fluent_migrations
+    WHERE name = 'FlamenetRelay.AddEmailVerification'));
+```
+
+It marks only the accounts that existed before verification arrived. Anyone
+who signed up since still has to confirm their address. Running it a second
+time, or on a relay that never needed it, changes nothing.
+
 ## Telling your users about updates
 
 The Android app asks *your* relay whether a newer build exists, not an address