Edward
c6aa6c232e
* add readme section and support file * [doc] Document anonymize levels in README and SUPPORT Reviewer feedback: mention both --anonymize-level values, not just -A. Wording follows the flag help in client/cmd/root.go. * Apply suggestion from @cubic-dev-ai[bot] * Update SUPPORT.md * adjust parameter descriptions * [doc] Fix duplicated sentence in SUPPORT.md The cubic suggestion replaced only part of the -U sentence, leaving the original line orphaned above it and dropping the blank line before the docs links. * [doc] Tighten anonymization claims in README and SUPPORT Strict mode keeps labels under netbird.io, so naming "the NetBird domains" overstated what it masks. Name the three peer domains instead. Anonymization is not full redaction: internal ranges survive at the default level and interface details are never masked, so say that rather than implying the bundle is safe to post unread.
6.3 KiB
Getting help with NetBird
Where to go depends on what you need. If you are not sure, start with Q&A / Support and we will move it.
Before you post
- Search existing discussions and issues, including closed ones.
- Check the documentation and the troubleshooting guides for clients and self-hosted deployments.
- Remove or anonymize sensitive information from logs, screenshots, and configuration.
If a discussion already covers your problem, upvote it and add your details there rather than opening a duplicate. Extra reproduction detail, affected versions, and deployment notes are useful even on an existing thread.
Community support
Free, for everyone. Covers the NetBird client, open source self-hosted deployments, and general questions.
| What you want to do | Where to go |
|---|---|
| Report a bug, regression, or unexpected behavior | Issue Triage |
| Request a feature or share an idea | Ideas & Feature Requests |
| Ask about setup, configuration, or self-hosting | Q&A / Support |
| Chat with the community | Slack |
Paid support
For NetBird Cloud customers and commercial-license self-hosted deployments, covering the dashboard, control plane, billing, and subscriptions, see reporting bugs and issues.
Security
Do not report security vulnerabilities in public issues or discussions, and do not post secrets, private keys, internal hostnames, or sensitive logs. Use the security policy.
What makes a report we can act on
For a bug, the most useful reports include:
- NetBird version, and component versions where applicable
- Operating system or environment
- Deployment type: NetBird Cloud, self-hosted, Kubernetes, Docker, or local development
- Current behavior and expected behavior
- The smallest set of steps that reproduces the problem
- Logs, status output, screenshots, or a debug bundle when relevant
- Whether this worked before, and the last known working version
For client reports, these commands usually give us what we need:
netbird version
netbird status -d -A
netbird debug for 1m -A -S -U
-A (--anonymize) replaces sensitive values consistently across every file in the bundle, so
it stays readable while masking most identifying details. It is not a guarantee of full redaction:
internal address ranges survive at the default level, and interface names, indexes, MTUs, and
flags are never anonymized. Read the bundle before posting it publicly. Two levels are
available:
| Level | How to select | What it masks |
|---|---|---|
default |
-A / --anonymize, or --anonymize-level default |
Public IP addresses, IPv6 ULA addresses, MAC addresses, and domains other than netbird.io, netbird.cloud, netbird.selfhosted, and netbird.stage. IPv4 private, CGNAT, and link-local ranges are kept, and interface names are not anonymized |
strict |
--anonymize-level strict (implies -A) |
The above, plus IPv4 private, CGNAT, and link-local ranges, peer names in front of netbird.cloud, netbird.selfhosted, and netbird.stage, and WireGuard public keys. Labels under netbird.io are kept, since it only hosts infrastructure |
Use strict when internal addressing or peer naming is itself sensitive. Either way, private
keys and SSH keys are never included, and the packet capture (capture.pcap) is left out of
anonymized bundles because it holds raw decrypted packets.
-U (--upload-bundle) uploads the bundle and returns a file key you can paste into the thread
instead of attaching an archive. Retention is controlled by the upload service; check its policy
before uploading, and configure cleanup for self-hosted deployments.
For more detail, see troubleshooting client issues, which explains what a debug bundle contains, and the CLI reference.
Intermittent problems are still worth reporting. They just need enough detail to investigate: trigger, frequency, timing, timestamps, and any related logs.
For a feature request, describe the problem before the solution: what you are trying to accomplish, who is affected and how often, why the current behavior or workaround is not enough, and what you would like to see instead.
What happens after you post
Our team, maintainers, or community members may ask for missing details, link related threads, merge duplicates, move your post to a better category, or try to reproduce the problem.
Not every discussion becomes an issue. Some are answered in Q&A, some turn out to be configuration problems, and some need more information before engineering can act. A well-answered discussion is still a useful outcome.
When a report is confirmed and actionable, a maintainer opens a validated issue linked back to the discussion, in whichever repository the fix belongs to. You do not need to know which repository that is. Routing is part of triage.
A note on issues
Issues in this repository are maintainer-curated work items. Every open issue is something a maintainer or contributor can pick up and act on. Issues opened without a linked validated discussion may be closed and redirected here.
Maintainers can still open issues directly for work found internally, such as regressions caught during development, planned maintenance, or release blockers.