The "Policy exists but connection is still blocked" entry told readers to look
for "blocked due to posture" or "no matching policy" entries in Traffic Events.
Those entries do not exist: a failed posture check or group mismatch is resolved
on the management server and never produces a Traffic Event. Drop the bullet;
the remaining checks (policy and posture checks under Access Control, group
membership under Peers) are the accurate guidance.
* Reference the config-file bootstrap workflow from install and peer pages
Link Bootstrap peers via config file from the setup-key sections of the
Linux, Windows, macOS, and Docker install pages, from the Setup Keys
page, and from the Kubernetes routing-peers guide. The page was only
reachable from the sidebar, so this surfaces the unattended deployment
workflow where headless and at-scale enrollment is already discussed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Clarify the Kubernetes example demonstrates setup-key enrollment
The manifest passes a setup key but does not mount a pre-populated
config, so reword the cross-link: the example enrolls with a setup key,
and the bootstrap guide covers the additional config-file step.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Clarify in "Step 3b: Configure access control" that access restrictions
of different types (IP CIDR, country, CrowdSec) are combined with a
logical AND by default: a connection must satisfy all of them.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The per-browser export steps led each bold browser label with an em
dash. Switch to a colon so each bullet reads as a clean
label-then-instruction, consistent with the other bullet lists in the
docs. Wording is otherwise unchanged.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Document the two failure modes when the NetBird CLI SSO login can't bind
its loopback callback port on Windows: bind forbidden (WSAEACCES, port
inside a Hyper-V/winnat reserved range) and address in use
(WSAEADDRINUSE, a stale process). Note that the redirect port is a
configured, IdP-registered set (default 53000, often 54000), not a
single hardcoded value, and cover cases where AV/EDR or other software
blocks the bind invisibly.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Link the existing "WireGuard port conflict on Domain Controllers"
guidance (on /manage/dns/internal-dns-servers) from two pages a
troubleshooting-hub user could not previously reach it from:
- Windows client troubleshooting: a bullet under Windows DNS scenarios
for the "NetBird won't start on a DC" symptom.
- DNS troubleshooting: a note after the AD/DC issue, disambiguating the
client-running-on-the-DC case.
No content duplicated; both are pointers to the one existing section.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Surface the existing /manage/reverse-proxy/troubleshooting page in the
Troubleshooting section: add it to the Connectivity sidebar group, and
move its hub chip from the Self-hosted card to Connectivity & networking
so the hub and sidebar agree.
The page covers reaching services exposed through routing peers, which
is a connectivity concern rather than self-hosted control-plane infra.
No new page and no duplicated content: both are pointers to the one
existing page.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
New /help/recording-a-har-file how-to under Troubleshooting > Report a
bug, covering HAR capture in Chrome, Edge, Firefox, and Safari with the
"preserve log" gotcha and a security warning about tokens in HAR files.
Nest Community/NetBird Support under the Report a bug "Overview" item so
the new page reads as a sibling of the reporting cluster rather than a
fourth flat peer. Cross-link the HAR page from the two support pages and
the Report bugs overview, next to the existing debug-bundle mention.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: lazy connections are no longer experimental
Lazy connections have graduated from experimental status. Remove the
"experimental" framing from the feature guide, the zero-trust use case,
and the CLI flag reference.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* remove outdated routing peer limitation
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Document the community.ansible_netbird collection for managing NetBird
resources (users, groups, setup keys, policies, networks, DNS, posture
checks) declaratively via the REST API. Adds a new Infrastructure as
Code subsection under Self-Host NetBird with room for future entries.
Cross-links from the Automated Setup PAT bootstrap page since the
collection is the natural next step after obtaining the first token.
Enable Next `output: 'standalone'` and rewrite the Dockerfile to package only the traced standalone server + .next/static + public on node:20-slim (glibc, matching the runner), running `node server.js`. No in-image npm ci, no full source or dependency tree. Cuts the image ~52%, so docker push and the server pull get much faster.
Also fixes a latent entrypoint bug (${VAR:"none"} -> ${VAR:-"none"}) that busybox sh tolerated but Debian dash (node:20-slim /bin/sh) rejects, which would otherwise crash the container on boot.
Smoke-tested via isolated build + docker run: boots in 37ms, all routes 200, redirects still bundled (/slack-url -> 307), static + public assets served, DocSearch env-injection intact.
Move `npm run build` out of the Docker image onto the runner, where actions/cache persists .next/cache across runs (the in-Docker build discarded it every time). The image now just packages the prebuilt .next and serves it with `next start`; runtime and the DocSearch entrypoint injection are unchanged.
Also: checkout full history (fetch-depth: 0) so per-page dates are correct, guard buildGitDateMap against shallow clones (correct-or-absent, never wrong), modernise the Docker actions (build-push-action v6, provenance: false), and add a path-filtered pull_request trigger so pipeline changes are validated before merge.
Smoke-tested via isolated build + docker run: serves /, /introduction, /api, sitemap, static assets (200); DocSearch placeholder injection intact.
Switch pr-build and the Docker image from `npm install` to `npm ci` (`npm ci --omit=dev` in the image), and enable setup-node's npm cache. Deterministic installs from the committed lockfile; CI now fails fast on an out-of-sync lockfile.
Depends on the lockfile being tracked (PR #838) — npm ci requires a committed package-lock.json.
Stop gitignoring the lockfile and commit a freshly regenerated one so CI and Docker builds install a pinned dependency tree instead of re-resolving `^` ranges on every run. Fresh resolution matches the versions already building (no version changes). Document the convention in CLAUDE.md. Enables `npm ci` as a follow-up.
Replace ~314 `git log` spawns per gen script with a single `git log --name-only` pass, memoised per process. Cuts gen:last-updated + gen:sitemap from ~15s to ~1.5s.
Output is byte-identical to the per-file version; still degrades to no-dates when git is unavailable (e.g. the Docker image).
* docs: add routing peer sizing guide
Add a Sizing Routing Peers page under Networks covering the four-step
sizing method, a per-peer capacity table, the tuning levers that matter,
and how to scale out by sharding load across identical Networks.
Cross-link it from How Routing Peers Work (HA note + related tile) and
the Networks overview, and add it to the docs navigation.
* docs: refine wording in routing peer sizing guide
Generalize the Acme example to remote users, correct the encrypt/decrypt
framing and reach the local network rather than the datacenter, use
'routing peer' instead of 'gateway', and rename the recap to Summary.
* docs: tighten and correct HA behavior in routing peer sizing guide
Correct the high-availability description: a single Network does not
balance load across its peers — different metrics give failover (one
peer carries all), equal metrics give latency-based nearest-peer
selection, which splits traffic by geography but never evenly. Shard
into more Networks to split load deterministically.
Also collapse redundant restatements, drop the secondary worked
example (the capacity table covers it), and slim the commodity-hardware
guidance.
* docs: add 1- and 2-vCPU rows to the routing peer capacity table
Extend the capacity table down to 1 and 2 vCPUs, drop the 'or more' from
the interface column, and adjust the methodology note so the interface
column reads uniformly as the minimum NIC to pair with each size.
* docs: add userspace WireGuard table and when-to-use cases
Add a userspace-mode capacity table showing wireguard-go does not scale
across cores (download plateaus ~6.8 Gbps, only ~4-5 cores used), and
the cases where a routing peer runs userspace: missing/broken/conflicting
kernel module, no TUN device (netstack, incl. rootless Docker), non-Linux
peers, and forcing userspace to capture policy IDs and blocked traffic
events. Name the exact benchmark CPU (Xeon Platinum 8375C).
* docs: replace 'sharding' with plain wording in sizing guide
Rename the Scaling out heading and reword the body, description, and
recap to talk about splitting load across more Networks instead of
sharding. Update the in-page anchor link to match the new heading.
* docs: clarify download/upload direction bullets in sizing guide
Lead each direction bullet with Download:/Upload: and say the routing
peer encrypts/decrypts, tying the pulling/pushing distinction to the
capacity table's column names.
* docs: replace 'shard' with plain wording in HA note
* docs: add jumbo frames section to routing peer sizing guide
* docs: align jumbo upload figure with capacity table, mark 16-vCPU line-rate as projection
* docs: use consistent numerals for MTU byte sizes
Adds the how-to under the reorganized /use-cases/remote-access group
(stacked on the Use Cases reorg). Walks through the decision ladder for
two sites sharing one internal IP, ending with the per-site TCP proxy
pattern on each routing peer.
* docs: consolidate scenario guides under /use-cases with redirects
Move 11 pages: feature-nested use cases from manage/networks,
manage/network-routes, manage/reverse-proxy, and the Kubernetes
integration into /use-cases/remote-access, /use-cases/cloud, and
/use-cases/security; the site-to-site decision page becomes
/use-cases/remote-access; the MikroTik guide becomes an install
guide at /get-started/install/mikrotik.
Add one redirect per moved page and flatten existing redirect
chains so every legacy URL resolves in a single hop. The
deprecated Routes site-to-site recipe stays put.
* docs: rebuild sidebar navigation for use-cases reorg
Remove the four nested Use Cases sublists from Manage NetBird;
keep the deprecated Routes recipe as a direct 'Site-to-Site
(legacy)' link. Rebuild USE CASES with Remote Access, Cloud &
Kubernetes, Security groups and a flat Homelab link. Add MikroTik
to Get Started > Platforms.
* docs: rebuild use-case index pages and refresh feature landing links
Turn /use-cases into an "I want to..." scenario finder. Retitle
the site-to-site decision page to Remote Access and point its
links at the new sibling URLs. Add the Kubernetes service and
private-proxy guides to the cloud and security indexes, refresh
the homelab landing links, and update the Networks, Routes,
Reverse Proxy, and Kubernetes landing pages to the new use-case
URLs.
* docs: update internal links to new use-case URLs
Point cross-links across the docs at the consolidated
/use-cases URLs. Links to the deprecated Routes site-to-site
recipe and all image paths under public/docs-static are left
unchanged.
* docs: shorten sidebar label to Site-to-Site
* docs: move Kubernetes into its own Use Cases section
Pull the entire Kubernetes integration out of Manage > Integrations
into a dedicated Kubernetes group under Use Cases at /use-cases/
kubernetes, and move the two Kubernetes cloud guides there too.
Rename the Cloud group (was 'Cloud & Kubernetes'); Integrations
keeps the MDM deployment pages. Add redirects for every moved page
and flatten existing chains.
* docs: drop 'NetBird on' prefix from cloud sidebar labels
* docs: alphabetize Remote Access use cases in sidebar
* ❯ add mikrotik to install index
* docs: fix duplicated word in remote-access link label on TV install pages
---------
Co-authored-by: Brandon Hopkins <brandon@techhut.tv>
* docs: recommend Linux routing peers for file-share workloads
Add performance guidance to the Active Directory use case (Step 1
placement choice) and a performance trade-off note to Reach Services
on the Routing Peer: Windows/macOS peers process the data path in
userspace, and self-access delivery is slowest for reads, so a
dedicated Linux routing peer is the fast default for SMB/DFS.
* docs: platform-split the self-access performance note
Linux kernel-mode service hosts deliver to their own LAN IP at full
speed; the read-direction penalty is specific to Windows/macOS
userspace hosts.
* docs: scope the AD self-access caveat to Windows file servers
* docs: drop read-direction specifics from performance notes
The directional asymmetry is a suspected client defect under
engineering escalation, not durable documented behavior. Keep only
the kernel-vs-userspace guidance.
* docs: address review — dedupe performance guidance, fix note placement
- AD page: performance point stated once (Step 1 note, linking
how-routing-peers-work for the mechanism); bullets and recap trimmed;
Step 1 bullet now carries the Windows qualifier
- reach-services: note compressed to consequence + links, moved below
The scenario where LAN IP and the shape are defined
* Add OpenWRT install steps
* Add images
* Fixes and caveats
* minor fixes
* docs: call it "the NetBird client", not "the NetBird client (agent)"
---------
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>
Document running a BYOP proxy in private mode with no public inbound
ports by disabling proxy ACME, issuing the wildcard TLS certificate
externally over DNS-01, and serving it as a static certificate that the
proxy hot-reloads on renewal.
Adds the page under reverse-proxy/use-cases with a new Use Cases nav
group, plus cross-links from the Bring Your Own Proxy page (port-443
prerequisite + TLS table) and the Reverse Proxy overview (static cert
mode).
* docs: add 'Choosing a pattern' overview to K8s getting started
Add a decision table and rules of thumb covering routing peer vs client
sidecar vs API server proxy vs Gateway API, so readers can pick the right
operator pattern. Clarifies that a sidecar (not a routing peer) is the
answer when a pod needs its own identity or to originate traffic onto the
overlay.
* docs: name the NetworkRouter CRD and clarify its DNS zone in the pattern table
* docs: add Highly Available Routing Peers use-case page (Kubernetes operator)
Add a standalone use-case page under a new Use Cases group in the Kubernetes
nav, covering how to run the operator's routing peers in HA: NetworkRouter
workloadOverride.replicas (default 3), the auto-created PodDisruptionBudget
(maxUnavailable: 1), equal-metric automatic failover, and spreading replicas
across failure domains via workloadOverride.podTemplate. Models least-privilege
(named destination group + access policy) rather than the All group.
* docs: add topology diagrams to HA routing peers page
Two SVG topology diagrams: replicas on a single node (single point of
failure) and replicas spread one-per-node via topologySpreadConstraints.
Embedded in Step 1 and the failure-domains section.
* docs: correct HA scheduling framing; drop single-node diagram
kube-scheduler spreads a Deployment's replicas across nodes by default
(best-effort, via built-in PodTopologySpread defaults). The earlier text/
diagram wrongly implied replicas co-locate by default. Reframe: multi-node
spread is the default; topologySpreadConstraints turns it into a guarantee
(or spans zones). Remove the single-node diagram (non-HA case, out of scope).
* docs: add Friendly DNS names appendix to HA routing peers page
Document exposing a service under a cleaner name via a CNAME in a custom
zone pointing at the operator's <service>.<namespace>.<zone> record (verified
end-to-end). Placed as an appendix for now; can move to a shared location later.
* docs: use ScheduleAnyway in spread example; note DoNotSchedule rollout deadlock
Multi-node verification: default scheduling already spreads replicas one-per-node;
the operator merges workloadOverride.podTemplate.topologySpreadConstraints into the
Deployment. DoNotSchedule with replicas == schedulable nodes deadlocks rolling updates
(surge pod can't place). Switch the example to ScheduleAnyway (verified clean rollout)
and document DoNotSchedule + the node-count/maxSurge caveat for a hard guarantee.
* docs: clarify custom-zone records are per-name (no whole-domain shadowing)
Verified on the lab: a NetBird custom zone serves only the records you add; other
names under the domain fall through to upstream DNS. Reusing a real internal domain
for friendly names is safe except for exact-name collisions.
* docs: expand into full 'Route to a Kubernetes service' how-to
Restructure the HA use-case page into an end-to-end guide covering the whole
journey: create the custom DNS zone, groups, and access policy (dashboard) ->
deploy HA routing peers (NetworkRouter, replicas:3) -> expose a Service
(NetworkResource) -> verify + failover. Generic, human-readable example names
(k8s.company.internal, kubernetes-clients/-services, network 'kubernetes',
nginx). Keeps the failure-domains diagram + ScheduleAnyway/DoNotSchedule note
and the friendly-DNS appendix. Adds <img> slots for 5 dashboard/terminal
screenshots (to be supplied). Renames the page + nav entry to
route-to-a-kubernetes-service; old slug removed.
* docs: add dashboard/terminal screenshots to the K8s how-to
Four screenshots (DNS zone, access policy, the kubernetes network with HA +
3 routing peers, kubectl pods-across-nodes). Drop the groups screenshot and
renumber the <img> refs to match.
* docs: swap in cleaner pods-across-nodes screenshot for Step 5
* docs: make node-spread central to the HA guide
Node-spread is the point of an HA guide, not a tail-end section. Move the
topology diagram up to 'What you'll achieve', fold the node-spread story into
Step 3 (deploy HA routing peers) - leading with the verified fact that the
scheduler spreads replicas across nodes by default (HA out of the box), with
topologySpreadConstraints as optional hardening - and drop the orphaned
'Spread across failure domains' section.
* docs: clarify the custom zone is created empty (operator fills the record)
Step 1 showed the auto-created A record without saying you don't enter it.
Note that you create only the zone (no hostname/IP/TTL by hand) and the
operator adds <service>.<namespace>.<zone> -> ClusterIP (5-min TTL) in Step 4.
* docs: replace Excalidraw topology with a custom dark-mode SVG
Hand-authored dark-background topology diagram (NetBird overlay -> routing
peers one-per-node -> Service) that matches the dark docs theme, replacing the
light Excalidraw-derived SVG. Removes the orphaned ha-routing-peers-spread-nodes.svg.
* docs: add CNAME dialog screenshot to the friendly-DNS appendix
Show the Add DNS Record dialog (CNAME 'app' -> nginx.default.k8s.company.internal)
and align the example hostname to 'app' to match.
* docs: drop maxSurge:0 workaround (not configurable via the operator)
The operator's workloadOverride only exposes annotations, labels, podTemplate,
and replicas — there is no hook for the Deployment's strategy.rollingUpdate.maxSurge.
Keep the achievable workaround (more schedulable nodes than replicas).
* docs: drop manual topology spread guidance (operator handles it by default)
* Restructure Troubleshooting into a hub with per-area pages
- Add a Troubleshooting hub (/help/troubleshooting) with icon/chip cards and a "Still stuck?" CTA
- Split NetBird Client troubleshooting into an overview + per-OS pages (Linux, Windows, macOS, Android, iOS)
- Split Self-hosted troubleshooting into an overview + per-area pages (installation, IdP, dashboard, certificates, connectivity, database)
- Split "Report bugs and issues" into Community Support and NetBird Support pages
- Add Troubleshooting resource connectivity and a NetBird Cloud pending-approval page
- Add DNS troubleshooting Issue 8 (Windows NRPT rule blocked by a lingering GPO)
- Cross-reference the new pages from networks, DNS, and reverse-proxy docs; update nav
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address review: client terminology, dead props, labels, cross-links
- Use "client" instead of "agent" across the client troubleshooting pages (headings, prose, anchors)
- Remove unused source: props from the Troubleshooting hub tiles
- Relabel the "NetBird Cloud" grouping to "Cloud & identity" (SSO/provisioning also apply to self-hosted)
- Add a Tiles title on the report-bug landing; add reverse-proxy -> resource-connectivity cross-link
- Fix comma splices introduced by the em-dash cleanup in relayed-connections
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Add client-side hash redirect for moved self-hosted anchors
Old deep links like /selfhosted/troubleshooting#debugging-turn-connections now
forward to the per-area page, since next.config redirects can't act on the URL fragment.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Apply docs-skill review: conventions + reshape area pages
- "open source" (no hyphen), expand NRPT on first use, descriptive alt text + captions on TURN images
- Fix inherited "Netbird" casing in the client glossary
- Reshape the six self-hosted area pages to Symptom -> likely causes (ordered) -> Fix -> Confirm, preserving anchored headings
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Fix two typos in client glossary (CodeRabbit)
- "nunning" -> "running" in the glossary
- possessive "it's" -> "its" in the routing-table sentence
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: fix two broken links in troubleshooting pages
- database: point the "upgrade path" link at /selfhosted/maintenance/upgrade;
selfhosted-quickstart has no #upgrade anchor so the old link landed at page top
- client: add HashRedirect so old #net-bird-agent-status deep links forward to
the renamed #net-bird-client-status section on the same page
* docs: address review follow-ups (deep-link redirects + client casing)
- self-hosted troubleshooting: extend the HashRedirect map with the per-issue
(###-level) anchors from the old single page, so old deep links land on the
exact sub-section of the new area page rather than just the page top
- client glossary: lowercase "NetBird client" in the peer-a/peer-b entries
(house convention) and fix "linux" -> "Linux"
* docs: review polish — fix image class + first-use acronym glosses
- connectivity: fix bad CSS class imagewrapper-nig -> imagewrapper on the
TURN-test screenshot (the typo'd class matched no style and broke zoom)
- gloss acronyms on first use: GPO (DNS Issue 8), IdP/SSO (identity-provider),
ACME (certificates), CORS (dashboard)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>
