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

Open
opened 2026-08-05 01:30:28 -04:00 by saavagebueno · 0 comments
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
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11685