From bea4702501a352b52d91736e7500ae90fd7f50cc Mon Sep 17 00:00:00 2001 From: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com> Date: Wed, 23 Sep 2026 18:18:45 +0200 Subject: [PATCH] docs: separate the PostgreSQL prerequisite from the data migration step --- .../scaling/high-availability-from-installer.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/pages/selfhosted/maintenance/scaling/high-availability-from-installer.mdx b/src/pages/selfhosted/maintenance/scaling/high-availability-from-installer.mdx index 4395ca8e..41fd85f4 100644 --- a/src/pages/selfhosted/maintenance/scaling/high-availability-from-installer.mdx +++ b/src/pages/selfhosted/maintenance/scaling/high-availability-from-installer.mdx @@ -42,7 +42,7 @@ The example uses these names. Replace them with your own throughout: Have these ready before you change anything on node 1: -1. **A highly available PostgreSQL endpoint, version 17 or later**, with an empty database and a user that owns it. The installer runs PostgreSQL 17, and its backup does not restore into an older version. Building a highly available PostgreSQL is outside this guide: use a managed service or your database team's platform, as described in [Step 1 of the High Availability guide](/selfhosted/maintenance/scaling/high-availability#step-1-make-postgre-sql-highly-available). +1. **An empty, highly available PostgreSQL service to migrate into, version 17 or later**, with an empty database and a user that owns it. Step 1 moves your data there. The installer runs PostgreSQL 17, and its backup does not restore into an older version. Building a highly available PostgreSQL is outside this guide: use a managed service or your database team's platform, as described in [Step 1 of the High Availability guide](/selfhosted/maintenance/scaling/high-availability#step-1-make-postgre-sql-highly-available). 2. **Redis and a three-node NATS cluster**, as described in [Steps 2 and 3](/selfhosted/maintenance/scaling/high-availability#step-2-set-up-a-redis-ha-endpoint) of the High Availability guide. 3. **A load balancer** that supports HTTP/2 and gRPC, and a way to give it a TLS certificate for `app.example.com`, through its own ACME support or a certificate you upload. You configure its routing in Step 4. 4. **A second host with Docker** for node 2. @@ -60,9 +60,9 @@ cp .env .env.single-node Do not `source` the installer's `.env` file in your shell. One of its values contains spaces, and the shell stops with `profile: command not found`. Read single values with `grep` instead, as the commands below do. -## Step 1: Move the database +## Step 1: Migrate your data to the shared PostgreSQL -The installer stores everything in its own PostgreSQL container, except the embedded identity provider, which keeps users and login sessions in an SQLite file, `idp.db`. This step moves both into your PostgreSQL endpoint. NetBird is down on node 1 until the step ends, which usually takes a few minutes. +The installer's PostgreSQL runs in a container on node 1, so it goes down with node 1. It holds everything except the embedded identity provider's data: users and login sessions sit in an SQLite file, `idp.db`. This step copies both into the PostgreSQL service you prepared, and points NetBird at it. NetBird is down on node 1 until the step ends, which usually takes a few minutes. 1. Stop the NetBird server so nothing writes during the copy: