[GH-ISSUE #5724] Feature Request: Extend getting-started.sh with high-availability (HA) configuration mode #11915

Closed
opened 2026-08-05 01:31:38 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @renne on GitHub (Mar 28, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5724

Summary

The current infrastructure_files/getting-started.sh script sets up a fully functional single-node NetBird deployment (combined management + signal + relay). However, it provides no guided path for users who need a production-grade, high-availability setup. This feature request asks for an HA mode to be added to the script (or a companion script/template) that configures multiple redundant nodes for all critical components.

Motivation

Users running NetBird self-hosted in production face the following gaps today:

  • The getting-started script deploys a single combined server — one process handles management, signal, and relay. Any restart or failure causes a full outage.
  • There is no documented or scripted path from single-node to HA without manually editing docker-compose files and reverse proxy configuration.
  • The embedded database (SQLite via the combined server) is not suitable for multi-instance deployments — shared state is required.
  • Teams that want zero-downtime updates or node-level fault tolerance currently have to figure out the entire HA topology from scratch.

Proposed Solution

Extend the getting-started script with an optional HA deployment mode, selectable via a flag or interactive prompt (e.g. --mode ha), that configures:

1. External shared database (PostgreSQL)

  • Prompt for or accept a PostgreSQL DSN (NETBIRD_STORE_ENGINE=postgres, NETBIRD_DATADIR pointing to shared storage)
  • Provide a bundled postgres service in the generated docker-compose for single-machine HA testing, and document how to point it at an external managed database

2. Multiple management instances

  • Generate a docker-compose with netbird-management scaled to N replicas (configurable, default 2)
  • All replicas share the same PostgreSQL backend and object store
  • Requires stateless management — verify this is already the case or flag any blockers

3. Multiple relay instances

  • Generate relay containers with distinct NB_RELAY_AUTH_SECRET (shared secret, different bind addresses)
  • Document that clients discover all relay addresses from management and auto-failover

4. Multiple signal instances (if horizontally scalable)

  • Generate netbird-signal replicas
  • Document statefulness constraints if signal cannot be horizontally scaled today

5. Load balancer / reverse proxy with upstream groups

  • Extend the Traefik / Nginx / Caddy configuration generation to define upstream groups pointing at all management and relay replicas
  • Traefik: use loadbalancer.servers with multiple entries
  • Nginx: use upstream blocks with multiple server directives
  • Caddy: use reverse_proxy with multiple backends

6. Health checks and graceful drain

  • Add healthcheck entries to docker-compose for each component so the load balancer removes unhealthy instances
  • Document rolling update procedure (drain → update → re-add)

Example Invocation

# HA mode with 2 management replicas and external PostgreSQL
curl -sSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash -s -- \
  --mode ha \
  --management-replicas 2 \
  --relay-replicas 2 \
  --postgres-dsn "postgres://netbird:secret@db.example.com:5432/netbird"

Or interactively: the script prompts Deploy in HA mode? [y/N] and collects the required parameters.

Minimum Viable Scope

If full scripted HA is too large for a single PR, a useful intermediate step would be:

  • Document the required environment variables and docker-compose structure for an HA deployment in a docs/ or infrastructure_files/README-ha.md file
  • Add a docker-compose.ha.yml template that users can adapt
  • Note any current architectural blockers (e.g. signal statefulness, object storage requirements)
Originally created by @renne on GitHub (Mar 28, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5724 ## Summary The current `infrastructure_files/getting-started.sh` script sets up a fully functional single-node NetBird deployment (combined management + signal + relay). However, it provides no guided path for users who need a production-grade, high-availability setup. This feature request asks for an HA mode to be added to the script (or a companion script/template) that configures multiple redundant nodes for all critical components. ## Motivation Users running NetBird self-hosted in production face the following gaps today: - The getting-started script deploys a **single combined server** — one process handles management, signal, and relay. Any restart or failure causes a full outage. - There is **no documented or scripted path** from single-node to HA without manually editing docker-compose files and reverse proxy configuration. - The embedded database (SQLite via the combined server) is not suitable for multi-instance deployments — shared state is required. - Teams that want zero-downtime updates or node-level fault tolerance currently have to figure out the entire HA topology from scratch. ## Proposed Solution Extend the getting-started script with an optional **HA deployment mode**, selectable via a flag or interactive prompt (e.g. `--mode ha`), that configures: ### 1. External shared database (PostgreSQL) - Prompt for or accept a PostgreSQL DSN (`NETBIRD_STORE_ENGINE=postgres`, `NETBIRD_DATADIR` pointing to shared storage) - Provide a bundled `postgres` service in the generated docker-compose for single-machine HA testing, and document how to point it at an external managed database ### 2. Multiple management instances - Generate a docker-compose with `netbird-management` scaled to N replicas (configurable, default 2) - All replicas share the same PostgreSQL backend and object store - Requires stateless management — verify this is already the case or flag any blockers ### 3. Multiple relay instances - Generate relay containers with distinct `NB_RELAY_AUTH_SECRET` (shared secret, different bind addresses) - Document that clients discover all relay addresses from management and auto-failover ### 4. Multiple signal instances (if horizontally scalable) - Generate `netbird-signal` replicas - Document statefulness constraints if signal cannot be horizontally scaled today ### 5. Load balancer / reverse proxy with upstream groups - Extend the Traefik / Nginx / Caddy configuration generation to define **upstream groups** pointing at all management and relay replicas - Traefik: use `loadbalancer.servers` with multiple entries - Nginx: use `upstream` blocks with multiple `server` directives - Caddy: use `reverse_proxy` with multiple backends ### 6. Health checks and graceful drain - Add `healthcheck` entries to docker-compose for each component so the load balancer removes unhealthy instances - Document rolling update procedure (drain → update → re-add) ## Example Invocation ```bash # HA mode with 2 management replicas and external PostgreSQL curl -sSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash -s -- \ --mode ha \ --management-replicas 2 \ --relay-replicas 2 \ --postgres-dsn "postgres://netbird:secret@db.example.com:5432/netbird" ``` Or interactively: the script prompts `Deploy in HA mode? [y/N]` and collects the required parameters. ## Minimum Viable Scope If full scripted HA is too large for a single PR, a useful intermediate step would be: - [ ] Document the required environment variables and docker-compose structure for an HA deployment in a `docs/` or `infrastructure_files/README-ha.md` file - [ ] Add a `docker-compose.ha.yml` template that users can adapt - [ ] Note any current architectural blockers (e.g. signal statefulness, object storage requirements) ## Related - `infrastructure_files/getting-started.sh` — current single-node script - `infrastructure_files/migrate.sh` — database migration helper - NetBird docs on self-hosting: https://docs.netbird.io/selfhosted/selfhosted-guide
Author
Owner

@braginini commented on GitHub (Mar 29, 2026):

There is a comprehensive guide in the docs that covers most of the requested functionality: https://docs.netbird.io/selfhosted/maintenance/scaling/scaling-your-self-hosted-deployment

FYI: The open source version of Management and signal only supports active-passive HA mode that you can easily configure with an external Postgres database.

If you are looking for active-active setup then you should refer to the enterprise commercial license. See here: https://netbird.io/pricing#on-prem

P.S. Some of the added functionality of the proposed script is interesting (like providing Postgres dsn). We will see what we can do about it

<!-- gh-comment-id:4150051841 --> @braginini commented on GitHub (Mar 29, 2026): There is a comprehensive guide in the docs that covers most of the requested functionality: https://docs.netbird.io/selfhosted/maintenance/scaling/scaling-your-self-hosted-deployment FYI: The open source version of Management and signal only supports active-passive HA mode that you can easily configure with an external Postgres database. If you are looking for active-active setup then you should refer to the enterprise commercial license. See here: https://netbird.io/pricing#on-prem P.S. Some of the added functionality of the proposed script is interesting (like providing Postgres dsn). We will see what we can do about it
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11915