bgolat · Sep 10, 2026 · Sep 5, 2026 · Sep 8, 2026 · Sep 10, 2026 · Sep 10, 2026
diff --git a/docs/config/_category_.json b/docs/config/_category_.json
@@ -1,5 +1,5 @@
 {
-  "label": "Config Reference",
+  "label": "Config reference",
   "position": 4,
   "link": {
     "type": "generated-index",

diff --git a/docs/config/firewall.mdx b/docs/config/firewall.mdx
@@ -139,7 +139,7 @@ enabling the built-in Nebula SSH server, you may wish to grant access over the N
 
 ## firewall.default_local_cidr_any
 
-<Pill className="mb-24">Default: False</Pill> <Pill className="mb-24">Reloadable</Pill>
+<Pill className="mb-24">Default: false</Pill> <Pill className="mb-24">Reloadable</Pill>
 {/** children passed as prop to avoid MDX generating a paragraph inside Pill */}
 <Pill className="mb-24" variant="warning" children="Deprecated" />
 

diff --git a/docs/config/lighthouse.mdx b/docs/config/lighthouse.mdx
@@ -42,14 +42,14 @@ lighthouse:
 
 ## lighthouse.am_lighthouse
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 `am_lighthouse` is used to enable lighthouse functionality for a node. This should ONLY be `true` on nodes you have
 configured to be lighthouses in your network
 
 ## lighthouse.serve_dns
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 `serve_dns` optionally starts a DNS listener that responds to `A` and `TXT` queries and can even be delegated to for
 name resolution by external DNS hosts. To enable listening on IPv6 in addition to IPv4, set
@@ -64,7 +64,7 @@ regardless of whether it is communicating over the Nebula network.
 `TXT` records can only be queried over the Nebula network, and contain certificate information for the requested host IP
 address.
 
-For example, if `192.168.100.1` was your Lighthouse node running a DNS server and you wanted to find the Nebula IP
+For example, if `192.168.100.1` was your lighthouse node running a DNS server and you wanted to find the Nebula IP
 address of a host named `web01`:
 
 ```shell

diff --git a/docs/config/logging.mdx b/docs/config/logging.mdx
@@ -29,7 +29,7 @@ Controls the logging format. The options are `json` or `text`
 
 ## logging.disable_timestamp
 
-<Pill className="mb-24">Default: False</Pill> <Pill className="mb-24">Reloadable</Pill>
+<Pill className="mb-24">Default: false</Pill> <Pill className="mb-24">Reloadable</Pill>
 
 Disables timestamp logging. Useful when output is redirected to logging system that already adds timestamps.
 

diff --git a/docs/config/pki.mdx b/docs/config/pki.mdx
@@ -60,7 +60,7 @@ The `key` is a private key unique to every host on a Nebula network. It is used
 to prove a host’s identity to other members of the Nebula network. The private key should never be shared with other
 hosts.
 
-### PKCS11 Support
+### PKCS11 support
 
 <Pill>Added in v1.10</Pill>
 
@@ -100,7 +100,7 @@ support!
 
 :::note
 
-The blocklist is _not_ distributed via Lighthouses. To ensure access to your entire network is blocked you must
+The blocklist is _not_ distributed via lighthouses. To ensure access to your entire network is blocked you must
 distribute the full blocklist to every host in your network. This is typically done via tooling such as Ansible, Chef,
 or Puppet.
 
@@ -112,7 +112,7 @@ stolen or compromised.
 
 ## pki.disconnect_invalid
 
-<Pill className="mb-24">Default: False</Pill> <Pill className="mb-24">Reloadable</Pill>
+<Pill className="mb-24">Default: false</Pill> <Pill className="mb-24">Reloadable</Pill>
 
 `disconnect_invalid` is a toggle to force a client to be disconnected if the certificate is expired or invalid.
 

diff --git a/docs/config/preferred-ranges.mdx b/docs/config/preferred-ranges.mdx
@@ -17,7 +17,7 @@ ranges admitted as a set of preferred ranges of IP addresses.
 > An underlay network is the network that a nebula [overlay network](https://en.wikipedia.org/wiki/Overlay_network) maps
 > onto. It is the LAN network that a host is connected to in addition to the wider internet.
 
-## How nebula orders underlay IP addresses it learns about
+## How Nebula orders underlay IP addresses it learns about
 
 <figure>
 <figcaption>

diff --git a/docs/config/punchy.mdx b/docs/config/punchy.mdx
@@ -8,10 +8,10 @@ import { Pill } from '@components/Pill/Pill';
 # punchy
 
 `punchy` configures the sending of inbound/outbound packets at a regular interval to avoid expiration of firewall NAT
-mappings. See [NAT Traversal and Firewalls](/docs/guides/nat-traversal/) for when to reach for these settings and the
+mappings. See [NAT traversal and firewalls](/docs/guides/nat-traversal/) for when to reach for these settings and the
 NAT behaviors that make them necessary.
 
-Regardless of how `punchy` is configured, the Lighthouse will notify hosts when a peer is attempting to handshake with
+Regardless of how `punchy` is configured, the lighthouse will notify hosts when a peer is attempting to handshake with
 it and Nebula will issue an "empty" packet to the initiating peer's IP addresses in an attempt to punch a hole through
 its own NAT.
 
@@ -25,7 +25,7 @@ punchy:
 
 ## punchy.punch
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 When enabled, Nebula will periodically send "empty" packets to the underlay IP addresses of hosts it has established
 tunnels to in order to maintain the "hole" punched in the NAT's firewall.
@@ -34,14 +34,14 @@ tunnels to in order to maintain the "hole" punched in the NAT's firewall.
 
 <Pill className="mb-24">Default: 1s</Pill> <Pill className="mb-24">Reloadable</Pill>
 
-`delay` is the period of time Nebula waits between receiving a Lighthouse handshake notification and sending an empty
+`delay` is the period of time Nebula waits between receiving a lighthouse handshake notification and sending an empty
 packet in order to try to punch a hole in the NAT firewall. This is helpful in some NAT race condition situations.
 
 ## punchy.respond
 
-<Pill className="mb-24">Default: False</Pill> <Pill className="mb-24">Reloadable</Pill>
+<Pill className="mb-24">Default: false</Pill> <Pill className="mb-24">Reloadable</Pill>
 
-When enabled, the node will attempt a handshake to the initiating peer in response to the Lighthouse's notification of
+When enabled, the node will attempt a handshake to the initiating peer in response to the lighthouse's notification of
 the peer attempting to handshake with it. This can be useful when a node is behind a difficult NAT for which regular
 hole punching does not work. Some combinations of NAT still will not work and [relays](/docs/config/relay/) can be used
 for this scenario.
@@ -50,5 +50,5 @@ for this scenario.
 
 <Pill className="mb-24">Default: 5s</Pill> <Pill className="mb-24">Reloadable</Pill>
 
-`respond_delay` is the period of time Nebula waits between receiving a Lighthouse handshake notification and attempting
+`respond_delay` is the period of time Nebula waits between receiving a lighthouse handshake notification and attempting
 its own "reverse" handshake with the initiating peer.
diff --git a/docs/config/relay.mdx b/docs/config/relay.mdx
@@ -15,7 +15,7 @@ Relay support was introduced in Nebula v1.6.0.
 
 Relay hosts forward traffic between two peers. This can be useful if two nodes struggle to communicate directly with
 each other (e.g. some NATs can make it difficult to establish direct connections between two nodes.)
-[NAT Traversal and Firewalls](/docs/guides/nat-traversal/) explains which NAT behaviors cause this and when relays are
+[NAT traversal and firewalls](/docs/guides/nat-traversal/) explains which NAT behaviors cause this and when relays are
 the right fix.
 
 ```yml
@@ -51,7 +51,7 @@ relays:
   - <other Nebula VPN IPs of hosts used as relays to access me>
 ```
 
-This list of relays is reported to the Lighthouse. When other nodes attempt to handshake with this host, the Lighthouse
+This list of relays is reported to the lighthouse. When other nodes attempt to handshake with this host, the lighthouse
 will indicate its supported relays in addition to its known IP addresses.
 
 ## relay.am_relay

diff --git a/docs/config/sshd.mdx b/docs/config/sshd.mdx
@@ -30,7 +30,7 @@ See also the [Debugging with Nebula SSH commands](/docs/guides/debug-ssh-command
 
 ## sshd.enabled
 
-<Pill className="mb-24">Default: False</Pill> <Pill className="mb-24">Reloadable</Pill>
+<Pill className="mb-24">Default: false</Pill> <Pill className="mb-24">Reloadable</Pill>
 
 `enabled` toggles this feature globally.
 

diff --git a/docs/config/static-map.mdx b/docs/config/static-map.mdx
@@ -31,7 +31,7 @@ In general, this should be left as the default value `ip4` to avoid issues commu
 
 Lighthouses learn each node's IP addresses by looking at the source address of incoming packets as well as the
 self-reported addresses sent by the node. Because most devices are behind a NAT of some sort (e.g. a network router)
-they cannot self-report their public IPv4 address. By contacting the Lighthouse via its IPv4 address, the Lighthouse is
+they cannot self-report their public IPv4 address. By contacting the lighthouse via its IPv4 address, the lighthouse is
 able to learn the node's public IPv4 address.
 
 It is necessary to set this setting to `ip6` (or `ip`) for IPv6-only hosts.

diff --git a/docs/config/stats.mdx b/docs/config/stats.mdx
@@ -47,14 +47,14 @@ A golang [Duration](https://pkg.go.dev/time#ParseDuration). Recommended to be se
 
 ## stats.message_metrics
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 Enables counter metrics for meta packets, e.g.: `messages.tx.handshake`. NOTE: `message.{tx,rx}.recv_error` is always
 emitted.
 
 ## stats.lighthouse_metrics
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 Enables detailed counter metrics for lighthouse packets, e.g.: `lighthouse.rx.HostQuery`.
 
@@ -64,14 +64,14 @@ Config options if `stats.type` is chosen to be `graphite`
 
 ### stats.prefix
 
-<Pill className="mb-24 no-transform">DEFAULT: nebula</Pill>
+<Pill className="mb-24">Default: nebula</Pill>
 
 The prefix for Graphite metrics that nebula will prepend:
 https://graphite.readthedocs.io/en/latest/feeding-carbon.html#step-1-plan-a-naming-hierarchy
 
 ### stats.protocol
 
-<Pill className="mb-24 no-transform">DEFAULT: tcp</Pill>
+<Pill className="mb-24">Default: tcp</Pill>
 
 Choose which protocol is used for passing stats to Graphite. The options are `tcp` and `udp`.
 

diff --git a/docs/config/tun.mdx b/docs/config/tun.mdx
@@ -27,7 +27,7 @@ tun:
 
 ## tun.disabled
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 Allows the nebula interface (tun) to be disabled, which lets you run a lighthouse without a nebula interface (and
 therefore without root). You will not be able to communicate over IP with a nebula node that uses this setting.
@@ -39,13 +39,13 @@ required. If set, must be in the form `utun[0-9]+`. For FreeBSD: Required to be
 
 ## tun.drop_local_broadcast
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 Toggles forwarding of local broadcast packets, the address of which depends on the ip/mask encoded in pki.cert
 
 ## tun.drop_multicast
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 
 Toggles forwarding of multicast packets
 
@@ -135,7 +135,7 @@ remaining available gateways, though load balancing may become uneven until the
 
 ## tun.use_system_route_table
 
-<Pill className="mb-24">Default: False</Pill>
+<Pill className="mb-24">Default: false</Pill>
 <Pill className="mb-24">Added in v1.7.0</Pill>
 
 This option is only supported on Linux.

diff --git a/docs/guides/debug-ssh-commands/index.mdx b/docs/guides/debug-ssh-commands/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Debugging with Nebula SSH commands
+sidebar_label: SSH debug commands
 description:
   Learn how to use Nebula's built-in SSH server commands to debug network connectivity issues on overlay hosts.
 summary:
@@ -95,7 +96,7 @@ list-hostmap - List all known previously connected hosts
 ## Notes about some commands
 
 `query-lighthouse <some-ip>` will return an empty result set initially if the host is not connected, but it will trigger
-a background request to the Lighthouse. Meaning, you need to run it twice to actually get a result.
+a background request to the lighthouse. Meaning, you need to run it twice to actually get a result.
 
 `change-remote` has only a temporary effect: after a period of time, Nebula will "revert" to its
 [preferred remote](https://nebula.defined.net/docs/config/preferred-ranges/#how-nebula-orders-underlay-ip-addresses-it-learns-about)
diff --git a/docs/guides/host-discovery/index.mdx b/docs/guides/host-discovery/index.mdx
@@ -1,6 +1,6 @@
 ---
 sidebar_position: 2
-title: How Hosts Find Each Other
+title: How hosts find each other
 description:
   The two mechanisms Nebula hosts use to discover each other's routable addresses — the static host map and lighthouse
   discovery — and when to use each.
@@ -10,12 +10,12 @@ summary:
   to choose between them for each host in your network.
 ---
 
-# How Hosts Find Each Other
+# How hosts find each other
 
 Every host in your network has a Nebula IP, but that address only exists inside the overlay. To establish a tunnel with
 a peer, a host needs the peer's _underlay_ address — a routable IP and port like `203.0.113.42:4242` — to send packets
 to. Host discovery is how a host learns that address. Whether packets can actually get through the NATs and firewalls in
-between is covered in [NAT Traversal and Firewalls](/docs/guides/nat-traversal/).
+between is covered in [NAT traversal and firewalls](/docs/guides/nat-traversal/).
 
 There are two ways a host can learn where to reach a peer:
 
@@ -151,4 +151,4 @@ advanced config overrides.
 - [`static_map` reference](/docs/config/static-map/)
 - [`lighthouse` reference](/docs/config/lighthouse/)
 - [`listen` reference](/docs/config/listen/)
-- [NAT Traversal and Firewalls](/docs/guides/nat-traversal/)
+- [NAT traversal and firewalls](/docs/guides/nat-traversal/)
diff --git a/docs/guides/nat-traversal/index.mdx b/docs/guides/nat-traversal/index.mdx
@@ -1,6 +1,6 @@
 ---
 sidebar_position: 3
-title: NAT Traversal and Firewalls
+title: NAT traversal and firewalls
 description:
   What Nebula needs from the firewalls and NATs between hosts — how UDP hole punching works, which NAT behaviors break
   it, and the fallbacks available when a direct tunnel cannot be established.
@@ -10,7 +10,7 @@ summary:
   what to reach for when the network gets in the way.
 ---
 
-# NAT Traversal and Firewalls
+# NAT traversal and firewalls
 
 Nebula sends handshakes, tunneled traffic, and reports to [lighthouses](/docs/config/lighthouse/) over a single UDP
 socket, and connections always start from the inside out. That's why most hosts behind home routers and office firewalls
@@ -139,7 +139,7 @@ In rough order of preference:
 2. **Give the host a public address.** A port forward plus
    [`lighthouse.advertise_addrs`](/docs/config/lighthouse/#lighthouseadvertise_addrs) skips observation entirely. Peers
    dial a known-good address, so no punching is needed. Pin [`listen.port`](/docs/config/listen/) so the forward has a
-   stable target, and see [How Hosts Find Each Other](/docs/guides/host-discovery/) for how the advertised address
+   stable target, and see [How hosts find each other](/docs/guides/host-discovery/) for how the advertised address
    spreads.
 3. **Use relays.** [Relays](/docs/config/relay/) are the designed fallback when no direct path exists. A host that both
    peers can reach forwards traffic between them. The tunnel stays end-to-end encrypted; the relay can see routing
@@ -178,6 +178,6 @@ a relay from the admin panel. See [Using dedicated relays](https://docs.defined.
 - [`punchy` reference](/docs/config/punchy/)
 - [`relay` reference](/docs/config/relay/)
 - [`listen` reference](/docs/config/listen/)
-- [How Hosts Find Each Other](/docs/guides/host-discovery/)
+- [How hosts find each other](/docs/guides/host-discovery/)
 - [Connectivity and NAT traversal](https://docs.defined.net/architecture/#connectivity-and-nat-traversal) in the Managed
   Nebula architecture overview
diff --git a/docs/guides/quick-start/index.mdx b/docs/guides/quick-start/index.mdx
@@ -1,6 +1,6 @@
 ---
 title: Quick start
-description: How to create your first overlay network using a Certificate Authority, Lighthouse, and Hosts
+description: How to create your first overlay network using a certificate authority, lighthouse, and hosts
 summary:
   This section will walk you through setting up a simple nebula network for testing. The examples will need to be
   modified to suit your particular environment.
@@ -16,15 +16,15 @@ sidebar_position: 1
 In Nebula, a lighthouse is a Nebula host that is responsible for keeping track of all of the other Nebula hosts, and
 helping them find each other within a Nebula network.
 
-### Certificate Authority
+### Certificate authority
 
-In its simplest form, a Nebula Certificate Authority (CA) consists of two files, a CA certificate, and an associated
+In its simplest form, a Nebula certificate authority (CA) consists of two files, a CA certificate, and an associated
 private key. A CA certificate is distributed to, and trusted by, every host on the network. The CA private key should
 not be distributed, and can be kept offline when not being used to add hosts to a Nebula network.
 
 ### Hosts
 
-A Nebula host is simply any single node in the network, e.g. a server, laptop, phone, tablet. The Certificate Authority
+A Nebula host is simply any single node in the network, e.g. a server, laptop, phone, tablet. The certificate authority
 is used to sign keys for each host added to a Nebula network. A host certificate contains the name, IP address, group
 membership, and a number of other details about a host. Individual hosts cannot modify their own certificate, because
 doing so will invalidate it. This allows us to trust that a host cannot impersonate another host within a Nebula
@@ -41,7 +41,7 @@ to suit your particular environment.
 To start, you'll need to download Nebula for your specific platform(s). Specifically you'll need `nebula-cert` and the
 specific `nebula` binary for each platform you use.
 
-#### Desktop and Server
+#### Desktop and server
 
 Check the [releases](https://github.com/slackhq/nebula/releases/latest) page for downloads
 
@@ -117,7 +117,7 @@ would generate a CA valid for just under two years.
 
 ## Building a Nebula network
 
-### Establishing a Lighthouse
+### Establishing a lighthouse
 
 Nebula lighthouses allow hosts to find each other, anywhere in the world. Lighthouses are the only hosts in a Nebula
 network whose IP addresses should not change. Running a lighthouse requires very few compute resources, and you can
@@ -127,7 +127,7 @@ of us have used $5/mo [DigitalOcean](https://digitalocean.com) droplets as light
 Once you have launched an instance, ensure that Nebula UDP traffic (default port udp/4242) can reach it over the
 internet and is not blocked by any inbound firewall.
 
-### Creating Keys and Certificates
+### Creating keys and certificates
 
 This assumes you have three hosts, which we will name `lighthouse1`, `laptop`, and `server`. You can name the hosts any
 way you'd like, including FQDN. You'll also need to choose the Nebula IP address for each host when generating its

diff --git a/docs/guides/rotating-certificate-authority/index.mdx b/docs/guides/rotating-certificate-authority/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Rotating a certificate authority
+sidebar_label: Rotating a CA
 description: How to rotate an expiring Nebula certificate authority without downtime.
 summary:
   This guide will teach you how to migrate from an expiring certificate authority by creating a new certificate
@@ -34,7 +35,7 @@ bundle, giving you as much time as possible to rollback and fix any issues befor
 
 ## Let's get started!
 
-### Step 1: Generate a new Certificate Authority
+### Step 1: Generate a new certificate authority
 
 The first thing we need to do is create a new certificate authority with an expiration in the future. The new CA should
 use the exact same CIDR, group, and subnet restrictions as the original certificate. You can use `nebula-cert print` to

diff --git a/docs/guides/running-nebula-as-non-root/index.mdx b/docs/guides/running-nebula-as-non-root/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Running Nebula as a non-root user
+sidebar_label: Running as non-root
 description:
   How to run Nebula on Linux as an unprivileged user by granting the CAP_NET_ADMIN capability via systemd or setcap.
 summary: