Skip to content

Add NetBird self-hosted VPN stack - #53

Open
xrhstosmour wants to merge 2 commits into
mainfrom
feature/netbird-vpn
Open

Add NetBird self-hosted VPN stack#53
xrhstosmour wants to merge 2 commits into
mainfrom
feature/netbird-vpn

Conversation

@xrhstosmour

Copy link
Copy Markdown
Owner

What:

  1. Adds a self-hosted NetBird mesh WireGuard VPN stack at networking/vpn/netbird, following the existing docker-compose.yml + template.env pattern, mirroring upstream's infrastructure_files/docker-compose.yml.tmpl structure adapted to this repo's conventions: five services (dashboard, signal, relay, management, coturn), env-driven ports throughout.
  2. Wires management's storage to the shared postgresql container via NETBIRD_STORE_ENGINE_POSTGRES_DSN, instead of its default embedded store. No depends_on on postgresql (separate compose project); overrides entrypoint: (not command:, which would just become extra args to the image's own ENTRYPOINT) with a bash//dev/tcp wait-loop, since the base image is plain ubuntu without nc.
  3. coturn runs with network_mode: host (required for it to actually relay peer traffic), the one service in this repo not on the shared internal network.
  4. Ships trimmed-down configuration/management.json and configuration/turnserver.conf, hand-edited like Traefik's configuration/*.yml, with placeholder values for the parts a real self-hosted setup would customize (OIDC endpoints, TURN credentials, TLS certs).

Why:

Pre-staging VPN tooling for a future VPS install. Chose NetBird over wg-easy per a prior discussion: mesh connectivity with no port-forwarding needed, plus built-in SSO/MFA/ACLs, over a classic hub-and-spoke WireGuard server.

Testing:

  1. docker compose config validates with no errors.
  2. Started the shared postgresql container locally and brought up all five services: dashboard, signal, relay, and coturn reach Up cleanly; management connects to Postgres (no connection errors) and gets as far as fetching its configured OIDC discovery endpoint.
  3. Confirmed that specific failure point is genuinely just "no real OIDC provider configured" and not a bug: swapped the placeholder OIDCConfigEndpoint for a real reachable HTTPS URL and observed management make the actual outbound request and fail on a real 404, rather than any earlier wiring problem. A full end-to-end login needs a real OIDC identity provider and public domain, which is out of reach for a local test and will be verified once this is deployed with a real domain on the VPS.
  4. docker compose down -v cleans up with no leftover state.

@xrhstosmour xrhstosmour added the enhancement New feature or request label Aug 6, 2026
@xrhstosmour xrhstosmour self-assigned this Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant