* docs: add MDM fleet rollout use case
The MDM reference pages cover installing the client and enforcing its
settings separately, per OS and per vendor, but nothing walks through a
whole rollout. This use case ties install, SSO enrollment, policy, and
update ownership together, with an end-to-end Intune example for Windows
and macOS, and links out to the reference pages for detail.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JM8WrDg3kV1PQriXwjmzCb
* docs: move MDM rollout under a Deployment use-case group
Group the MDM rollout guide under a new Deployment section in the Use
Cases sidebar. Reuse existing Intune, desktop app, and Intune compliance
screenshots in the walkthrough. Drop the iOS section and the "What this
does not do" section to keep the guide focused on Windows and macOS
laptops.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JM8WrDg3kV1PQriXwjmzCb
* docs: tighten MDM rollout use case for clarity and scan
Polish the fleet rollout page: shorter preamble, clearer policy and update guidance, Related tiles, and a plain checklist without the redundant recap.
* docs: align Intune Ignore app version with update owner
The rollout guide requires Yes when NetBird owns updates and No when Intune does. Document both options on the Intune deploy page so the two guides do not conflict.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Brandon Hopkins <brandon@techhut.tv>
* docs: document the MDM keys added since the page was written, and iOS
The reference table listed 18 of the 23 keys the client recognises, and
claimed a count of 16. Six keys were missing from every downloadable
template as well, including lazyConnection, which the page already
documented:
- lazyConnection, disableAdvancedView, enableLocalMetrics,
localMetricsAddress, allowRemoteJobs and debugBundleUploadURL are now
in the reference table and in netbird.admx/.adml, io.netbird.client.plist,
netbird-macos.mobileconfig, netbird-macos.sh and netbird-policy.reg.
- Notes call out the two pairs that read as related but are not:
disableMetricsCollection (anonymous telemetry) versus
enableLocalMetrics (the client's own Prometheus endpoint), and
disableAdvancedView being UI-only, so unlike its neighbours it never
causes a request to be rejected.
iOS and tvOS now have a section of their own. The channel is Apple's
Managed App Configuration against bundle id io.netbird.app
(io.netbird.app.tv on tvOS), with a new netbird-ios-appconfig.plist
template and per-provider instructions. The section states what the
policy reaches today: the app locks its interface and refuses
configuration changes, while the tunnel engine runs in a Network
Extension that does not receive the app configuration, so keys the
engine applies to the connection are not enforced there yet.
Two template defects found on the way:
- netbird-macos.mobileconfig was not well-formed XML. Its header
comment contained a double hyphen, which XML forbids inside a
comment, so plutil -lint and any strict parser rejected the file an
admin downloaded.
- netbird-policy.reg had one LF-terminated line among CRLF ones;
normalised, with the UTF-16LE encoding reg import requires preserved.
Verified with npm run build and npm run lint:mdx, plus XML well-formedness
on all five XML templates, bash -n on the shell template, and a
cross-reference check that every string and presentation the ADMX
references is defined in the ADML.
* docs: iOS enforces every key; document when a change reaches the tunnel
The iOS section was written while the policy stopped at the app: the
network extension that runs the engine has its own preferences domain,
and Apple's app-configuration channel does not deliver there. The app
now mirrors the configuration into the shared App Group and tells the
extension when it changes, so the keys the engine applies to the
connection are enforced too.
What replaces the old warning is a timing caveat, which is what an admin
actually needs in order to plan a rollout. The hand-off happens only
while the app is running: in the foreground a change reaches the tunnel
within about 30 seconds or immediately on activation, but iOS suspends a
backgrounded app, so a policy pushed — or withdrawn — in that window
applies the next time the app is opened. A tunnel brought up by VPN On
Demand or the widget therefore runs on the last policy the app saw.
tvOS keeps the old behaviour and now says so: the hand-off needs a shared
app group, which does not work between the tvOS app and its extension, so
only the interface is enforced there.
Also corrected: blockInbound, wireguardPort and lazyConnection are no
longer listed as having no effect but as having no control to lock, and
debugBundleUploadURL moves out of the ignored list, since the engine
applies it when a remote job produces a bundle. The app-config template
carries the same three keys and the same timing note.
* docs: list allowRemoteJobs among the keys iOS enforces without a control
The key is enforced on iOS like the other engine-applied ones: a peer
whose policy withholds it refuses management-requested jobs. What is not
there yet is the lock on the Troubleshoot toggle, which arrives with the
iOS client PR that introduces that toggle — so promising it in the table
of what the user sees would describe a screen that does not exist.
Moved to the group of keys the engine applies with nothing on screen to
mark, next to blockInbound, wireguardPort, lazyConnection and
debugBundleUploadURL. It moves back to the table once the toggle ships.
* docs: sign macOS profiles with CMS, and scope the iOS claims properly
Three review findings, all correct.
`productsign` signs installer packages, not configuration profiles, and
an Apple Developer ID certificate cannot sign a profile at all — Apple's
own guidance is that a `.mobileconfig` is a CMS signed-data message. The
instruction predates this branch but the commit that fixed the malformed
XML comment rewrote it, so it is fixed here rather than carried forward.
It was also misleading in a second way: a profile delivered through an
MDM is signed by the MDM channel, so a managed rollout has nothing to
sign by hand. The step now says that, and gives `security cms -S` for the
case where the profile is handed out some other way.
"Every key is enforced on iOS" contradicted the list of
platform-inapplicable keys three paragraphs below it; it now reads "every
key that applies to the platform", and points at that list.
The engine-applied group — blockInbound, wireguardPort, lazyConnection,
allowRemoteJobs, debugBundleUploadURL — was stated without qualification
under a table headed "iOS / tvOS", while the warning just above says the
tvOS engine never receives the policy. Marked as iOS, with the tvOS case
pointed back at that warning.
* docs: group MDM policy keys by job and split delivery into per-platform pages
Rewrite /client/mdm-integration as the concept page and key reference:
a running example (a three-key baseline), the "pinned switches" model
(present means pinned, even as false), and the 23 keys grouped by the
job they do, each with its own anchor and the mistake it invites.
Correct claims that disagree with the client source (v0.80.0):
- disableClientRoutes stops the device using routes (resources, exit
nodes); it was described as not routing for others
- blockInbound also stops the SSH server and routing; not a kill switch
- since v0.75.0 the app hides managed settings, no "(MDM)" tag
- a policy change restarts the connection
- splitTunnel* have no effect today (Android has no MDM channel yet)
- managementURL pins the server, not the account, on NetBird Cloud
- the pre-shared key is readable by local users on Windows and macOS
Move Windows, macOS and iOS delivery into their own pages under
MDM Deployment, add them to the nav, and point inbound links at the
new per-key anchors.
* docs: fix MDM accuracy points found in review
- integer booleans are ignored on macOS (plist decodes as uint64); say so
- disableAutostart and disableAdvancedView lock nothing; qualify the lock claim
- managementURL: drop the disableProfiles advice, no key pins the account
- drop the unverifiable restart duration and a disableAdvancedView claim
- macOS page: fix 'never write the file' vs the shell-script channel
- Windows page: warn that the sample .reg pins every key
- tighten wording
* docs: say what disableAdvancedView hides (Peers and Resources tabs)
* docs: make clear disableNetworks removes the choice, not the networks
* docs: add recommended MDM policies by device role
* docs: lazyConnection follows the account setting, on by default since v0.74.0
* docs: drop the open-an-issue line from MDM troubleshooting
* docs: make remote jobs optional for every device role
* docs: make disableNetworks and disableAdvancedView optional for laptops
* docs: rename Recap to TL;DR on the MDM pages
* docs: TL;DR on the main MDM page only, drop the lead-in
* docs: list MDM Integration first under MDM Deployment in the nav
* docs: second review pass on the MDM pages
- macOS integer booleans are locked as well as unapplied; say so
- the lock-nothing keys are not desktop-only (disableAdvancedView on iOS)
- drop Linux from disableAutostart (no MDM channel there)
- blockInbound: drop the redundant routed-network clause
- encryption intro: Rosenpass permissive does not need to match
- troubleshooting: check macOS boolean types, no warning is logged
- wording fixes
* docs: correct MDM timing and CLI claims from a macOS lab run (v0.80.0)
- netbird debug config reads the policy file on each call; the daemon
applies a change at its next reload and logs 'MDM policy changed'
- netbird up --flag on a connected client ignores its flags; the
rejection examples now say login --flag or up on a disconnected client
- settings-field locks apply immediately; the disableUpdateSettings,
disableProfiles and disableNetworks gates apply at the next reload
- the restart on a policy change takes a second or two
* docs: MDM results from the Windows and macOS profile labs (v0.80.0)
- netbird logout works under every key and deregisters the peer; with
managementURL, disableProfiles and disableUpdateSettings pinned, logout
plus up --setup-key moves a device to another account on the same URL
- a profile-installed macOS policy file is a binary plist, root:wheel 644
- a REG_BINARY (or other unread type) value is not listed as managed
- the policy key inherits Authenticated Users read access
* docs: tighten four MDM statements to what the labs and source show
- no key blocks netbird logout of the active profile (source: only a
non-active profile logout is gated, by disableProfiles)
- the engine-restart log line appears only while the client is connected
- macOS: binary plist is what a configuration profile produces; the shell
script writes the same owner and mode
- Windows: the observed fact is that the NetBird key inherits Authenticated
Users read access, not a statement about the parent key
* docs: address CodeRabbit review on the MDM delivery pages
- iOS: the app must be managed by the MDM, not necessarily installed by
it (Apple supports taking over a user-installed app); same in the
iOS app-config template
- macOS: Jamf's Application & Custom Settings takes the bare plist, so
point Jamf at io.netbird.client.plist (and note the signed .mobileconfig
upload route); JumpCloud's MDM Custom Configuration Profile takes a
.mobileconfig per JumpCloud's docs, so drop the bare-plist claim and
its troubleshooting entry
- Windows: ADMXInstall only ingests the template; values are set through
Policy/Config/NetBird~Policy~NetBird/<PolicyName>; drop the
unverified Registry CSP path
* docs: address CodeRabbit's second review of the MDM templates
- netbird-macos.sh: managementURL, allowServerSSH and wireguardPort now
default to $NULL like every other key; the old defaults pinned them
(allowServerSSH=true pinned the SSH server allowed) on any run that
did not edit those lines
- drop the claim that disableMetricsCollection governs anonymous usage
telemetry from the mobileconfig, the bare plist, the script and the
ADML help text; the client recognizes the key but nothing reads it
* docs: correct the Mosyle path for the macOS MDM profile
Mosyle takes the .mobileconfig under Management > Management Profiles >
Certificates / Custom Profiles; there is no Custom Settings option with a
preference domain (per Orb and SI Prep deployment guides; Mosyle's own
docs need a login). Drop Mosyle from the bare-plist template header, and
align the mobileconfig header with the Jamf advice on the page.
* docs: drop the profiles-command install tip from the macOS template
macOS 11 and later cannot install configuration profiles with the
profiles command (man profiles, profiles tool 8.0+); point local testing
at a double-click and System Settings > General > Device Management, the
path the lab used.
* docs: make the Windows MDM page Intune-first, with a registry reference section
The page now leads with the Intune workflow: import the NetBird ADMX/ADML
once, create an Imported Administrative templates profile, assign it to a
device group, sync and verify, then the OMA-URI fallback and Intune
troubleshooting. Group Policy, .reg files, JumpCloud and the value-type
table move to a Registry reference section with its own troubleshooting.
New, from Microsoft Learn (Import custom ADMX templates): the current
portal paths, en-us ADML only, and that re-importing an updated template
fails until the profiles and the old template are deleted. netbird.admx
has no namespace dependencies and no combo boxes, so it imports alone.
The Intune install page stays separate; both pages now link to each
other. Main-page links follow the renamed anchors (#value-types,
#intune-troubleshooting).
* docs: move the enforce-settings link to the end of the Intune deploy page
* docs: group the Windows page's Intune steps under one heading
Mirrors the Registry reference section, so the page's table of contents
shows the Intune/registry split. Heading texts and anchors are unchanged.
* docs: rename the first MDM key group to Set the server and startup
The old heading named only managementURL; the group also holds
disableAutoConnect and disableAutostart.
* docs: add a use case to the Lock the client app section
What a developer on a locked Acme laptop sees (app tabs, the two CLI
errors, what still works), plus the finance team's disableNetworks and
Auto Apply exit node variant. Every behaviour is from the macOS and
Windows labs (v0.80.0).
* docs: replace the Lock the client app use case with a plain goals table
Goal, setting, and what users can still do, written for a junior admin.
disableProfiles row says plainly that signing out and into another
account still works (Windows lab W12).
* docs: OMA-URI payloads: <disabled/> pins an on/off setting off
The ADMX's on/off policies write enabledValue 1 and disabledValue 0, so
<enabled/> can only pin a setting on; document <disabled/> for off, the
String data type, and that un-pinning means Not configured (check the
device with reg query, since removing an OMA-URI may not clear it).
* docs: add What you can achieve tables to every MDM key section
Same goal / setting / what-to-know format as Lock the client app, for
server and startup, device exposure, encryption, support and monitoring,
and connection tuning; Lock's table now names values too. Every line
restates a claim already verified in the labs or source.
* docs: reorder the MDM page: goals first, key reference after
- What you can achieve (the six goal tables) comes first, then
Recommended policies, How the client applies a policy, and the Policy
keys reference; goal-table keys link down to their reference entries
- reference groups get noun names (Server and startup keys, ...) so no
two headings share an anchor
- the Acme running example is gone; its three keys become The laptop
baseline under Recommended policies, which the Windows, macOS and iOS
pages now link to as their example
- a one-line pin rule opens the goals, since the explanation now follows
* docs: laptop baseline goes to the user-devices group, not just laptops
* docs: rename the laptop baseline to the user device baseline
It applies to every user device (and the iOS page uses it), so the
Recommended policies column becomes User devices, the anchor becomes
#the-user-device-baseline, and the three platform pages follow.
---------
Co-authored-by: riccardom <riccardomanfrin@gmail.com>
Firefox/Gecko suffers severe scrolling jank on the documentation pages because of the large decorative SVG in the page header.
The SVG uses both:
- `mix-blend-mode: overlay`
- `transform: skewY(-18deg)`
Removing only the transform (`skew-y-[-18deg]`) for firefox-base browsers makes scrolling smooth immediately.
Reproduced in:
- Firefox on Windows
- Zen on Windows
- Zen on macOS
Chromium is unaffected.
* Add Sign-in Domains page
Documents how an email domain is matched to an account: adding a domain,
proving ownership with a DNS TXT record, and what changes for users once it is
verified.
Two points the page is careful about, because both are easy to assume wrongly:
- Verifying a domain decides where *new* users land. It does not move users who
already have an account of their own, so domains want adding before a team is
onboarded rather than after.
- A verified sign-in domain is not an SSO domain. Routing a domain to an
identity provider is a separate step on the integration, which is what lets
one domain sign in through SSO while another uses Google or a social login.
The four screenshots it references are not in this commit and need to be added
before merge:
public/docs-static/img/manage/team/sign-in-domains/
sign-in-domains-settings.png the Sign-in Domains tab in Settings
sign-in-domains-pending.png a newly added domain, Pending
sign-in-domains-dns-verification.png the TXT record dialog
sign-in-domains-login.png the login page
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Tighten the Sign-in Domains page
Switches the examples to company.com / company.net, drops the step-by-step
walkthrough of how matching works, and trims the instructions down to what a
reader actually needs to do. The prose and the callouts carry the page now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Trim the Sign-in Domains page further
Parallel section titles (Add / Verify / Remove Domain), drops the
"What Changes for Your Users" and "Things Worth Knowing" sections, and cuts
the availability note and the SSO note back to one line each.
The warning now says to add domains before onboarding a team from another
domain, which is the case it actually matters for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Move Sign-in Domains under Settings, and lead with the two domains
Sign-in Domains is a Settings tab in the dashboard, not part of Team, so the
page moves to /manage/settings/sign-in-domains and sits in the Settings nav
after Authentication, mirroring the dashboard's own tab order. Screenshots move
with it to img/manage/settings/sign-in-domains/.
The intro also led with jane@company.com, which would already have matched the
primary domain and so did not show the problem at all. It now establishes
company.com as the account's own domain and company.net as the second one, and
the colleague who needs it is jane@company.net.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Lead with what sign-in domains are for
Retitles the page "Allow Users from Other Domains to Join Your Account", which
is the job it does, and opens with the behaviour rather than with the account's
own domain: users on one business email domain are already joined into one
account, and most businesses have more than one domain -- another location, a
country domain, a second brand -- whose users are not.
Also documents the email route the verification dialog offers for anyone
without DNS access, and matches the dialog's own wording (Verify on the row,
then Start Verification).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Sharpen the intro and drop the primary-domain aside
- The colleague on another domain is not recognized unless invited by hand, so
the intro says so and links to the invite page.
- "With sign-in domains you prove ownership of those domains, and everyone
across your organization joins the same account."
- Drops the paragraph about company.com staying the primary domain. Remove
Domain named that term without defining it afterwards, so it now says "the
domain your account signed up with" instead.
- Drops the detail about the retry interval widening; that it keeps checking is
the part a reader needs.
- US spelling, matching the rest of the docs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Shorten the one-account-per-domain note
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Drop the SSO section, and nest the page under Authentication
The "Sign-in Domains and SSO" section read as confusing rather than
clarifying, so it goes along with its recap bullet. The constraint a reader
actually meets survives in Remove Domain: a domain an SSO integration uses
cannot be deleted until it is detached there.
The page also moves under the Authentication group in the sidebar, next to
Peer Session Expiration and Multi-Factor Authentication.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Follow the dashboard: Sign-in Domains lives under Authentication
The dashboard no longer gives sign-in domains a tab of their own, so the
instruction now sends the reader to Settings > Authentication and the section
within it. The screenshot is renamed to authentication-tab.png to match what
it has to show.
Also spells out that joining happens automatically without direct invites,
and drops the same point from the opening paragraph where it was now said
twice.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Move the page under Single Sign-On
/manage/team/single-sign-on/sign-in-domains, nested under Single Sign-On in
the Team section rather than sitting under Settings. Screenshots move with it
to img/manage/team/single-sign-on/sign-in-domains/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Put the page at manage/team/sign-in-domains
A sibling of Single Sign-On in the Team section, listed after it, rather than
nested inside it or under Settings. Screenshots follow to
img/manage/team/sign-in-domains/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Fix wording and a stale example domain
The DNS instruction still named www.company.net after the example moved to
company.co.uk, which is the one that actually misleads: that sentence is
telling people where to put the record.
Also a "usees" typo, a link with no object ("unless you invite manually"), a
missing comma after "By default", "as you" where the comparison is to your
domain, "E.g." opening a sentence, and "another one" where it means another
account.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Drop the authentication clause from the recap
It summarised the SSO section, which is gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Add the Sign-in Domains screenshots
- authentication-tab.png: the section under Authentication, with two domains
pending and two verified, which is what the page describes
- dns-verification.png: the Verify Domain Ownership dialog
- login.png: the login page
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Point domain verification help at NetBird Support
Replace the support@netbird.io mailto links with links to the support
page, and tell users with an account they were not aware of to reach out
so the team can verify their identity and point them to its admin.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs: add Reverse Proxy on OpenShift guide
Add a guide for running the NetBird reverse proxy on OpenShift with the
rootless UBI image under the restricted-v2 SCC. It covers the proxy
Deployment with self-managed ACME certificates on a PVC, exposure via a
TCP LoadBalancer or TLS-passthrough Routes, wiring a backend through a
routing peer, verification, and troubleshooting.
Adds the page to the Reverse Proxy sidebar and cross-links it from the
overview and Bring Your Own Proxy pages.
* docs: simplify OpenShift proxy guide
Drop the version availability note and the amd64 node restriction since
the rootless UBI proxy image is published for both AMD64 and ARM64, and
replace the interactive token prompt with plain export statements.
* docs: restructure OpenShift proxy guide and add http-01 variation
Make the guide easier to follow for reverse proxy operators:
- Put the LoadBalancer vs passthrough Route decision and the resource
footprint up front.
- Source the management address from the Secret and drop hardcoded
namespaces so the manifests apply without edits.
- Add checkpoints after each step and move alternatives (cert-manager,
replicas, upgrades, removal) into an "Operating the proxy" section.
- Document http-01 with the UBI image's :8081 challenge listener and why
it requires the LoadBalancer exposure.
Fixes from a test deployment on OpenShift 4.17 with the PR build of the
UBI proxy image:
- Add pkgs.netbird.io (geolocation database) to the egress requirements.
- Show how to switch a pending LoadBalancer Service back to ClusterIP.
- Describe the periodic PROTOCOL_ERROR reconnect symptom of a management
idle timeout separately from gRPC routing failures.
- Note that autocert handshake warnings during first issuance are expected.
* docs: add an external relays guide for commercial-license deployments
On NetBird Enterprise the relay's shared secret is also the traffic-flow
receiver's secret. The community guide tells readers to generate a new
secret, which on Enterprise leaves peers connected while traffic event
logging stops. Add a standalone Enterprise page that reuses the existing
secret, reads it from config.yaml, and ends with a check that the receiver
is still accepting events.
Correct the community guide:
- Relay hosts need 443/tcp, 443/udp and 3478/udp, not port 80: the relay
obtains its certificate with the TLS-ALPN-01 challenge on 443. Publish
443/udp in the compose file too, for QUIC.
- Apply a config.yaml change with `docker compose restart netbird-server`,
and a docker-compose.yml port change with `docker compose up -d`.
- Treat the config.yaml example as an addition to the server block, which
also holds auth, reverseProxy and store.
- Keep server.authSecret. Setting relays.addresses turns off the embedded
relay and STUN server, with no way to keep the embedded relay alongside.
- Relay choice is a latency race, a client can hold more than one relay
connection, and either transport can win.
- STUN status is not a failover signal, and a secret mismatch is best seen
in the relay host's log.
- Describe the startup log, the /relay response, and a certificate request
that hangs rather than errors.
- Make the proxy and supplied-certificate sections complete: the relay's
own configuration behind a proxy, what the proxy must do, what the
trusted-proxy headers affect, how to apply changes, and the pitfalls of
supplied certificates, including private CAs.
- chmod 600 relay.env, and apply later relay.env changes with
`docker compose up -d`.
List the new page under Commercial License as "External Relays (Licensed)"
and link it from the scaling guide.
* docs: clarify the receiver's log level, the firewall that restricts a published relay port, and the leftover Let's Encrypt sign
* docs: qualify the Step 1 traffic events check by the receiver's log level
* docs: cover migrated and no-traffic-flow deployments on the external relays page, and separate the two secret mismatches
* docs: name the QUIC form of the relay's secret-mismatch reason
* docs: read the active server configuration in Step 2, cover a stale receiver secret in Step 8, and separate what each receiver check proves
If you want a body line with it:
docs: add OpenShift client installation guide
Covers the certified rootless UBI image on restricted-v2, with both
ephemeral (no volume) and PVC-backed peer identity modes.
* docs: add Control Center Draft Mode guide
Add a how-to page for the new Draft Mode in Control Center: build a
change on a working copy of the canvas, review the exact API requests,
and deploy everything as one batch. A single running example (giving
DevOps HTTPS access to a not-yet-installed staging server) carries
through entering a draft, the canvas toolbar, node interactions,
placeholder-peer installs, and Review & Deploy.
Along the way:
- Nest Control Center in the sidebar (Overview + Draft Mode) and update
the overview page: Users view in the intro and quick start, an Edit
Nodes section covering live edits vs Draft Mode, permissions notes
including the Network Admin setup-key limitation, and a HashRedirect
for the renamed #editing-policies-from-the-graph anchor.
- Add a shared <Video> component for screen recordings: lazy playback
via IntersectionObserver, visible controls, preload="metadata", and
no autoplay under prefers-reduced-motion.
- Optimize media: re-encode recordings (H.264 CRF 26, 30 fps,
faststart, audio stripped) and losslessly recompress screenshots,
cutting the page's media payload from 6.3 MB to 1.2 MB.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix: image zoom overlay flickering on close
The closing fade-out ran without animation-fill-mode: forwards, so when
the 200ms animation finished the overlay snapped back to full opacity
until React's unmount timeout fired, flashing for a frame or two.
Holding the animation end state covers that gap.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: tighten Draft Mode intro
Give the running example its own paragraph and drop the header-chrome
description; the video right below it shows the same thing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: add Focus Mode section and group-from-selection video
Document Focus Mode on the Control Center overview (right-click a node
and choose Focus, or select it and press F) with two screenshots, and
move the F shortcut prose there from the Draft Mode page. Add a
recording of creating a group from a multi-peer selection to the
Draft Mode page. New media compressed like the rest.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: correct Focus Mode shortcut order
F is pressed first, then the node is selected.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: drop setup-key caveat from Draft Mode permissions note
The Network Admin limitation is already covered where it bites, in the
placeholder install section.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: drop Agent Network disambiguation from Add Nodes
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: reorder Assign Peers to Groups videos
Show the drag-to-group recording right after the text it illustrates,
then the group-from-selection flow.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: remove change-type badge list from review section
The review rows do not carry Add/Modify/Delete/Install badges.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: trim group-membership parenthetical from review example
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix: react to prefers-reduced-motion changes in Video
The reduced-motion check ran once on mount, so toggling the OS setting
while the page was open either kept videos auto-playing or left them
permanently inert. Listen for MediaQueryList changes: pause and drop
the observer when reduced motion turns on, re-observe when it turns
off.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Exit nodes previously lived only under Use Cases. Add them to the Routes
sidebar group and mention them on the Routes overview. Document that a
default route grants access to everything the routing peer can reach,
with Block LAN access and network isolation as mitigations, and link
How Routing Peers Work back to the exit nodes guide.
Add a decision-flow guide for "NetBird feels slow" that helps a reader
find whether the tunnel, their own connection, a routing peer, or the app
is the real cause, instead of assuming NetBird is at fault.
The page leads with the path traffic takes, a one-minute Quick test that
resolves the two most common causes (a relayed peer, or the local
network), then a Start here checklist that links down to detail sections:
checking the connection with netbird status -d, setting a baseline with
iperf3 in both directions, isolating the slow hop, ruling out packet size
and inspecting firewalls, and separating startup delays from throughput.
Add a reusable PathFlow component that draws the hop-by-hop path as a
labelled icon flow, used for the overview, the routing-peer example, and
the recap. Wire the page into the docs sidebar and the troubleshooting
hub.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: add clientless RDP for third parties use case guide
Covers publishing an internal RDP host as a TCP reverse proxy service
as an RDP gateway replacement for third parties that cannot install
the NetBird client: single-host resource, TCP service with auto-assigned
listen port, mandatory IP allowlist/CrowdSec restrictions, .rdp file
handover, and the L4 security boundaries (no SSO/PIN on TCP, port
re-rolls on service re-create, service publishing bypasses access
policies).
* docs: make CrowdSec conditional on broad allow rules, add UDP transport note
Review feedback: CrowdSec Enforce is redundant behind a strict single-IP
allowlist, so it is now recommended only when allow rules are broader.
Adds a note that RDP's optional UDP transport cannot be used through the
shared proxy cluster (independent auto-assigned listen ports) and that
clients fall back to TCP-only automatically.
* docs: update access control screenshot to match single-IP recommendation
* docs: scope the UDP transport limitation to the shared proxy cluster
Auto-assigned listen ports apply to the NetBird-hosted cluster only; a
BYOP cluster can bind a TCP and a UDP service to the same custom port.
* docs: UDP transport through a BYOP same-port service pair is verified working
Tested with mstsc against a BYOP cluster binding TCP and UDP services on
one custom port: the client negotiates the UDP transport through the
proxy, and removing the UDP service degrades cleanly to TCP-only. Also
notes the macOS client does not support the RDP UDP transport.
* docs: scope the macOS UDP claim to what was observed
* docs: macOS UDP claim holds with the app's UDP setting enabled
* docs: split into shared-proxy and BYOP use cases, drop client-specific UDP note
Adds a comparison of the two proxy deployments (auto-assigned port and
TCP-only vs custom ports and RDP UDP transport), a BYOP walkthrough with
the same-port TCP+UDP service pair, and keeps resource setup, access
restrictions, and verification shared between both paths.
* docs: clarify BYOP TLS requirement and service-domain resolution, grammar fixes
* docs: promote Agent Network in the sidebar and make sections collapsible
Rework the docs sidebar navigation:
- Render any nav group flagged `featured: true` as a highlighted card at the
top of the sidebar, with an optional `badge` label (currently Agent Network,
"New"). The flag is data-driven, so a future feature can take the spot by
moving two lines.
- Add a dropdown chevron to every collapsible menu, including the top-level
sections and the featured card, so it is obvious they expand.
- Collapse the top-level sections by default and expand the active one, so the
sidebar reads as a clean menu.
- Only render the active-page marker while its section is open, fixing the
orange highlight bar that lingered after collapsing an active section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: make sidebar section toggles keyboard-accessible
The collapse toggle was a click-only span, so after sections collapse by
default keyboard and screen-reader users could not expand a section or reach
its links. Make each toggle a semantic button with aria-expanded and an
aria-label, which restores keyboard operation and announces the open state.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: keep sidebar sections expanded by default, collapse only Agent Network
Restore the original behavior where top-level sections start expanded and only
the nested sub-groups start collapsed, instead of collapsing everything. The
featured Agent Network card keeps its own isOpen: false so it starts collapsed.
The dropdown chevrons, featured card, and keyboard-accessible toggles are
unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: move MDM deployment guides under Manage > Peers
The five fleet-deployment guides (GPO, macOS .pkg, Jamf Pro, Kandji,
Intune) lived under Integrations, but nothing in them integrates with
NetBird's platform — they are peer onboarding at scale, which lives
under Peers. The label also collided with Access Control's
'Integrate MDM & EDR', which uses MDM in the opposite sense.
- Move pages from /manage/integrations/mdm-deployment/ to
/manage/peers/mdm-deployment/ with a permanent wildcard redirect
- Re-point legacy /how-to redirects directly at the new paths
- Move the nav group under Peers as 'MDM Deployment'; remove the
now-empty Integrations group
- Update internal links
* docs: link full GPO deployment guide from MDM integration page
* docs: show setup-key secret wiring and replica naming for k8s routing peers
Fold the two verified-novel bits from the Access Infrastructure
autoscaling tutorial before purging it:
- Replace the 'use a secret' Note with the actual kubectl create
secret + secretKeyRef wiring (matches what the NetBird operator
injects for routing peers)
- In the HA section, note that removing the static NB_HOSTNAME lets
each replica register under its pod name (client falls back to
os.Hostname(), which is the pod name in Kubernetes)
* docs: purge redundant Access Infrastructure tutorials
The four pages under Manage > Peers > Access Infrastructure were
2024-era SEO tutorials that duplicated canonical feature docs and
carried outdated claims (pre-rewrite SSH model without the built-in
SSH server, a Docker section that never actually enrolls the
container with a setup key, CrowdStrike presented as the only EDR
integration, stale v0.29 output and vintage-UI screenshots).
Cross-checked each page against its canonical counterpart; nothing
novel remained (the two useful Kubernetes snippets were folded into
the routing-peers use case in the previous commit).
- Delete the four pages and their screenshot directory
- Remove the Access Infrastructure nav group
- Redirect each URL to its canonical replacement:
secure-remote-webserver-access -> /manage/peers/ssh
setup-keys-add-servers-to-network -> /manage/peers/register-machines-using-setup-keys
access-internal-resources-from-autoscaled-environments -> /use-cases/kubernetes
peer-approval-for-remote-worker-access -> /manage/peers/approve-peers
- Re-point the legacy /how-to redirects at the same targets to avoid
redirect chains
* docs: reorder Peers nav into enrollment, approval, day-2 flow
Group the five enrollment methods first (Add Peers, Setup Keys,
Bootstrap via Config File, MDM Deployment, Browser Client), then the
Approve Peers admission gate, then running-peer features (SSH, Lazy
Connections, Remote Jobs) and Auto Update last. Approve Peers
previously sat between two enrollment pages.
* docs: cross-link DNS aliases and internal DNS pages, fix tutorial inaccuracies
The two pages solve adjacent problems (NetBird-hosted records vs
forwarding to existing internal DNS) but never pointed at each other.
Add a which-page-do-I-need Note to each.
Also fix defects in the DNS Aliases tutorial found while cross-checking
it against the Custom Zones reference and dashboard source:
- 'Keep this enabled' implied search domain is on by default; it is
off by default (DNSZoneModal.tsx: enable_search_domain ?? false)
- Step 3 said 'wildcard resource' but the steps add exact-name domain
resources
- Wrong alt text ('Delete DNS Zone') on the zone-config screenshot
- Add missing meta description and a link to the Custom Zones
reference
* docs: align MSP portal page with 2026 partner program, rename For Partners nav
Cross-checked the MSP portal page against the 2026 MSP/MSSP Partner
Program document:
- Point the application link at netbird.io/use-cases/msp (the program's
canonical page) instead of a demo-form URL displayed as netbird.io/msp
- State tenant plan options (Team or Business) and the post-trial
minimum (Team plan with one user)
- Mention CSV/PDF usage export alongside the API
- Clarify the 3-day trial for existing accounts brought in as tenants:
it is a window to subscribe the tenant under the MSP account
- Add a subtle msp@netbird.io contact line at the bottom
Also rename the For Partners nav entries by deliverable instead of
audience (the section header already says who it's for): MSP Portal,
Distributor Portal, Deploy with Acronis.
* docs: update CLAUDE.md for agent-network, proxy.js, and tooling gaps
Audited every claim against the current repo. Stack, routing, security,
and convention claims all still hold; four gaps had accumulated:
- Add agent-network/ to the content structure list
- Document src/proxy.js in URL Routing: /api data requests must be
rewritten there because the config rewrite loses data-request context
on client-side navigation (Next.js #39669) and strips pageProps
- Add npm run lint:mdx; note npm run gen requires a Go toolchain
- Note fenced mermaid code blocks render as diagrams
* docs: address review findings on PR #906
- Move the MDM deployment screenshot directories to match the new page
paths; the URL rewrite had updated MDX image references without
moving the assets, breaking all Intune/Jamf/Kandji images
- Normalize pre-existing double slashes in Jamf and Kandji image URLs
- Align the routing-peers secret example with bootstrap-via-config-file
(same secret name, so both now use the NB_SETUP_KEY data key)
- DNS aliases: include the routing peer's group in the zone's
distribution groups. Verified in client source: the DNS route
interceptor (priority 100) outranks local zone records (priority 75)
and never falls through, so clients forward routed-domain queries to
the routing peer, which must receive the zone to answer
Turn "Commercial License" into a plain nav group and add an "Overview"
child pointing at /selfhosted/enterprise, above "Getting Started". This
matches the pattern already used by Networks, Cloud Marketplaces,
Observability, and Troubleshooting, where the section index page is
reachable as its own "Overview" link rather than only via the group
label.
* new: Windows GPO deployment guide under MDM for Deployment
* new: point GPO guide at the full policy key reference
* new: bold the example-posture disclaimer in GPO guide
* new: grammar and readability pass on GPO guide
* new: clarify AUTOSTART=0 vs Disable Autostart policy
* new: address review feedback on GPO guide install script and pinning
* docs: add Enterprise Commercial License overview page
Add a public, shareable overview of the NetBird Enterprise Commercial
License for teams evaluating self-hosted NetBird. Answers the questions
prospects ask most: in-place migration from the open source Community
Edition, zero-downtime control-plane upgrades via active-active HA,
control-plane behavior at scale, single-tenant boundaries and the
options for serving multiple customers, and how evaluation works.
Clarifies that the Cloud "Business plan" and the self-hosted commercial
license are different products, and lists what the license unlocks
(HA, SCIM, EDR/MDM integrations, traffic-flow logging, standard support).
Served at /selfhosted/enterprise and linked from the Self-Host sidebar.
* docs: qualify connection continuity by deployment topology
The single-server upgrade answer claimed all established connections
survive a restart. That holds only when Relay runs externally. In the
default combined deployment, netbird-server bundles Management, Signal,
and Relay, so recreating it restarts Relay and active relayed sessions
reconnect. Clarify that direct peer-to-peer connections continue either
way, while relayed-session continuity depends on whether Relay is
external or restarted with the combined server.
* docs: describe the commercial PoC as assisted, with 30-day default
"Managed proof of concept" overstated the offer. Per the EULA the
customer installs and runs the stack, with NetBird providing the license
and guidance, and a commercial PoC runs 30 days by default. Reword to
"assisted proof of concept" and state the default duration.
* Documentation for GRPC and JSON Sockets
* improve gRPC and HTTP/JSON socket documentation
* Update src/pages/client/grpc-socket.mdx
Co-authored-by: Nicolas Frati <nicofrati@gmail.com>
---------
Co-authored-by: Nicolas Frati <nicofrati@gmail.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>
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.
* 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>
* 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 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)
