The NetBird dashboard is the control plane UI for a WireGuard mesh

It is a UI for a separate management service, not the mesh itself

The scope is stated in the first line of the README: this project is the UI for NetBird's Management service, and the hosted version lives at app.netbird.io. The peer-to-peer networking lives in the separate netbirdio/netbird repository, which the README points to. That separation matters for anyone evaluating the project, because the dashboard is a client of an HTTP API rather than a component of the data plane. The README says the dashboard uses NetBird's Management Service HTTP API, so setting the management API endpoint is a required step in any deployment, and the suggested value when the API is on the same server is a local port. The intended user is therefore an operator of a NetBird deployment rather than a developer of the VPN itself, and the feature list confirms it: track the status of your peers, remove peers, manage setup keys used to authenticate new peers, list users, and define access controls.

The stack is Next.js, Radix, Tailwind and React Flow

The technologies section names the pieces, and they are worth reading together because they explain the shape of the interface. NextJS and ReactJS provide the application framework, Tailwind CSS handles styling, and React Flow is used for the Control Center, which is the graph view of the mesh and the reason a graph layout library is in the dependency list. Nginx and Docker are the serving and packaging layers, and Let's Encrypt provides certificates. The dependency list in package.json goes deeper than the README does: a long run of Radix UI primitives covers the accessible component layer, with accordion, checkbox, collapsible, dialog, dropdown menu, hover card, label, popover, radio group, scroll area, select, slider, slot and switch all present, and dagre is the layout library behind the graph rendering. The OIDC handling comes from the Auth0 React SDK, and a build step copies the service worker from that package into the public directory, which tells you the login flow runs as an OIDC client in the browser rather than through a server session.

Auth0 is the part you cannot take with you

The project is unusually honest about its one hard dependency, and the disclaimer is worth reading in full. The stated view is that a proper user management system is not a trivial task and requires quite some effort to make it right, and that the decision to use Auth0 was taken because it covers all the needs, which are user management, social login and a JWT for the management API. The last sentence of the disclaimer is the important one: Auth0 so far is the only third party dependency that can't be really self-hosted. Everything else in the stack, the React application, the Nginx proxy, the database behind the management service, is yours to host, but the identity provider is not, and that has consequences for an organisation with procurement requirements about where user data lives. The README then gives the three environment variables needed, an Auth0 domain, a client id and an audience, and points at the Auth0 React SDK guide up to the point of configuring allowed web origins.

Two container commands, with and without certificates

Running the dashboard is a docker run with a handful of environment variables, and the README gives the form without SSL first, where the ports are published directly and the Auth0 values and the management API endpoint are passed in:

   docker run -d --name netbird-dashboard \
     --rm -p 80:80 -p 443:443 \
     -e AUTH0_DOMAIN=<SET YOUR AUTH DOMAIN> \
     -e AUTH0_CLIENT_ID=<SET YOUR CLIENT ID> \
     -e AUTH0_AUDIENCE=<SET YOUR AUDIENCE> \
     -e NETBIRD_MGMT_API_ENDPOINT=<SET YOUR MANAGEMENT API URL> \
     netbirdio/dashboard:main

The second form adds certificates. An Nginx SSL port variable, a Let's Encrypt domain and an email, and the same Auth0 and management API variables, are passed to the same image, so the difference between the two commands is entirely about the certificate layer. Both publish 80 and 443, and both use the main tag of the netbirdio/dashboard image.

   docker run -d --name netbird-dashboard \
     --rm -p 80:80 -p 443:443 \
     -e NGINX_SSL_PORT=443 \
     -e LETSENCRYPT_DOMAIN=<YOUR PUBLIC DOMAIN> \
     -e LETSENCRYPT_EMAIL=<YOUR EMAIL> \
     -e AUTH0_DOMAIN=<SET YOUR AUTH DOMAIN> \
     -e AUTH0_CLIENT_ID=<SET YOUR CLEITN ID> \
     -e AUTH0_AUDIENCE=<SET YOUR AUDIENCE> \
     -e NETBIRD_MGMT_API_ENDPOINT=<SET YOUR MANAGEMENT API URL> \
     netbirdio/dashboard:main

The local development path is separate and simpler in one way and harder in another: install Node, create and update a .local-config.json file holding values that are replaced from config.json, run npm install, then npm run dev, and open http://localhost:3000. That config file requirement is the step that catches people, because the application reads its configuration at build time and a fresh checkout has nothing to run against.

The npm scripts show what the project actually tests

The scripts in package.json describe the testing setup in more detail than the README does, and it is a substantial one for a front end. There is a unit test suite under Vitest with a watch mode, and an end-to-end suite under Playwright with its own config, a UI mode and a CI variant that builds the application with APP_ENV set to test before running. There are also two shell scripts under an e2e/environment directory, one to create a test environment and one to clean it, which tells you the end-to-end tests need a real environment rather than a mocked one. Storybook is set up for component work on port 6006, and a visual regression script under .storybook/visual-regression handles screenshot comparison. The dev server is started on port 3000 by default and on 1337 for the test environment, and the build is a plain next build followed by a postbuild script. The engines field requires Node 24 or newer, which is a recent floor and worth checking against your CI images.

Bugs and features go to Discussions, not to the issue tracker

The contribution workflow is unusual and worth knowing before you file anything. NetBird uses a discussion-first workflow across all its repositories, so bug reports and feature requests for the dashboard start in the netbird Discussions area rather than as issues in this repository, and the README provides a table mapping intent to destination: issue triage for bugs, regressions and unexpected behavior, ideas and feature requests for proposals, Q&A and support for setup, configuration and self-hosting questions, and the security policy for vulnerabilities, with the instruction to never use a public thread for those. The team triages each discussion, and validated reports become issues in this repository linked back to the discussion. The reasoning behind the workflow is a link to a discussion post explaining how Discussions, Issues and Pull Requests fit together. For a contributor this means your report is triaged as a discussion first, and the issue tracker is downstream of that process.

Migration from the v1 dashboard is a three step image swap

There is a migration note for anyone coming from the older dashboard, and it is short because the change is mostly an image rename. The new dashboard ships under the netbirdio/dashboard:main image, while the old one was wiretrustee/dashboard:main. The three steps are to stop the dashboard container with docker compose down dashboard, replace the docker image name in your docker-compose.yml with the new one, and recreate the container with docker compose up -d --force-recreate dashboard. The repository also holds an AGPL-3.0 licence, a CLAUDE.md and AGENTS.md, a CONTRIBUTOR_LICENSE_AGREEMENT.md and an AUTHORS file, a Storybook configuration directory, a templates/ directory, a docker/ directory and an announcements.json file, and the last push to the repository was on 2026-10-19 with v2.95.0 released on 2026-10-15.

Editorial conclusion

The NetBird dashboard suits an operator who already runs NetBird and wants a browser interface for peers, setup keys, users and access control rather than the management API alone. It does not suit a self-hosting requirement that rules out a hosted identity provider, because the README names Auth0 as the one third party dependency that cannot really be self-hosted, and it does not suit a team wanting to replace NetBird's own UI, since the dashboard exists to drive that management service. Before adopting, read the local development steps, because the dashboard needs a config file and a running management API before it will show anything, and note that the last push to the repository was on 2026-10-19 with v2.95.0 from 2026-10-15 under an AGPL-3.0 licence.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. netbirdio/dashboard on GitHub
3. Project website
4. README
5. Releases