DefinedNet · bgolat · Mar 4, 2026 · Mar 19, 2026 · Mar 19, 2026 · jasikpark
diff --git a/README.md b/README.md
@@ -2,7 +2,7 @@
 
 This is the documentation for the [nebula open source project](https://github.com/slackhq/nebula).
 
-## Commands Cheatsheet
+## Commands cheatsheet
 
 All commands are run from the root of the project, from a terminal:
 

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/lighthouse.mdx b/docs/config/lighthouse.mdx
@@ -56,15 +56,15 @@ name resolution by external DNS hosts. To enable listening on IPv6 in addition t
 `'[::]'`.
 
 The DNS listener can only respond to requests about hosts it's aware of. For this reason, it can only be enabled on
-Lighthouses.
+lighthouses.
 
 `A` records contain the Nebula IP for a host name and can be queried by any host that can reach the DNS listener,
 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/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.
 

diff --git a/docs/config/punchy.mdx b/docs/config/punchy.mdx
@@ -10,7 +10,7 @@ import { Pill } from '@components/Pill/Pill';
 `punchy` configures the sending of inbound/outbound packets at a regular interval to avoid expiration of firewall NAT
 mappings.
 
-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.
 
@@ -33,14 +33,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>
 
-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.
@@ -49,5 +49,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
@@ -49,7 +49,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/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/guides/debug-ssh-commands/index.mdx b/docs/guides/debug-ssh-commands/index.mdx
@@ -94,7 +94,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/quick-start/index.mdx b/docs/guides/quick-start/index.mdx
@@ -1,5 +1,5 @@
 ---
-title: Quick Start
+title: Quick start
 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
@@ -16,7 +16,7 @@ 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
 private key. A CA certificate is distributed to, and trusted by, every host on the network. The CA private key should
@@ -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,5 @@
 ---
-title: Rotating a Certificate Authority
+title: Rotating a certificate authority
 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
@@ -33,7 +33,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
@@ -78,7 +78,7 @@ passphrase. Keep it safe - you will be prompted for it each time you sign a host
 **Before proceeding,** we strongly recommend you set a reminder for yourself to rotate your CA again in the future.
 Consider setting a reminder in your team's shared calendar for 2-3 months prior to your new CA's expiration.
 
-### Step 2: Updating your existing host's trust bundle
+### Step 2: updating your existing host's trust bundle
 
 Before issuing new certificates for each host, it's important to update the trust bundle in all of your existing hosts'
 configs. This will ensure that as hosts are moved over to certificates signed by the new CA, these new certificates will
@@ -116,7 +116,7 @@ time="2022-07-27T11:32:04-04:00" level=info msg="Trusted CA certificates refresh
 
 For extra credit, you can verify that your newly minted CA's fingerprint appears in the log line shown above.
 
-### Step 3: Signing new host certificates
+### Step 3: signing new host certificates
 
 Now that all of your hosts have been updated to trust the new CA, it's time to issue new host certificates. You'll need
 to iterate all existing certificates and issue a new certificate using the same information as before:
@@ -157,7 +157,7 @@ Even though this host is using a different CA than the rest of your network you
 the rest of your hosts because its certificate is signed by a CA in their trust bundle. You can issue a `ping` to test
 this now. Don't forget that your [firewall](/docs/config/firewall/) must allow pings from this host.
 
-### Step 4: Removing the old CA from the trust bundle
+### Step 4: removing the old CA from the trust bundle
 
 You did it! All of your hosts have updated certificates and are communicating with each other. At this point, you can
 safely remove the original CA from the trust bundle so that only the new CA exists:

diff --git a/docs/guides/sign-certificates-with-public-keys/index.mdx b/docs/guides/sign-certificates-with-public-keys/index.mdx
@@ -1,5 +1,5 @@
 ---
-title: Signing a Certificate Without a Private Key
+title: Signing a certificate without a private key
 description: How to sign Nebula certificates without copying private keys across devices.
 summary:
   After reading this guide you will be able to create public/private keypairs on devices you wish to add to the Nebula

diff --git a/docs/guides/unsafe_routes/index.mdx b/docs/guides/unsafe_routes/index.mdx
@@ -64,7 +64,7 @@ nebula-cert print -json -path ca.crt | jq .details
 }
 ```
 
-## Example Network
+## Example network
 
 The following IP addresses, hostnames, and subnets are used throughout this guide to illustate a valid configuration for
 our use case.
@@ -93,7 +93,7 @@ This is the overlay network that will be used by hosts running Nebula.
 | `192.168.100.10` | `home-raspi`     | Linux host that will route traffic between LAN and overlay |
 | `192.168.100.11` | `laptop-mac`     | Mac that will access printer _via_ `home-raspi`            |
 
-## Configuration Steps
+## Configuration steps
 
 Using the example network and hosts referenced above, the following steps explain how to configure the macOS host
 (`laptop-mac`, `192.168.100.11`) to route traffic through the Linux host (`home-raspi`, `192.168.100.10`) in order to

diff --git a/docs/guides/upgrade-to-cert-v2-and-ipv6/index.mdx b/docs/guides/upgrade-to-cert-v2-and-ipv6/index.mdx
@@ -39,7 +39,7 @@ All hosts must be upgraded to v1.10+ before proceeding. Older versions cannot va
 
 :::
 
-## Create a v2 Certificate Authority
+## Create a v2 certificate authority
 
 Create a new v2 Certificate Authority that will coexist with your existing v1 CA during the migration. Creating a new CA
 with Nebula v1.10 will create a v2 CA by default.
@@ -298,7 +298,7 @@ You can also check the logs for the `certVersion` field in handshakes:
 time="2025-12-09T22:23:33Z" level=info msg="Handshake message received" certName=host-1 certVersion=2 fingerprint=1376f30ea6ec555bde413be57eb3a3fad58ff7f6e31a87890e24a4a65b22c688 from="192.168.65.1:16583" handshake="map[stage:1 style:ix_psk0]" initiatorIndex=2138029252 issuer=74303f85545a26409fc73a3da0969858fc6262111b1476705083f519779e4a0c remoteIndex=0 responderIndex=0 vpnAddrs="[192.168.1.1 fdc8:d0db:a315:cb00::1]"
 ```
 
-## Optional: Transition to IPv6-only
+## Optional: transition to IPv6-only
 
 Once all hosts are on v2 certificates and have IPv6 addresses, you can optionally transition to an IPv6-only network.
 

diff --git a/docs/guides/using-lighthouse-dns/index.mdx b/docs/guides/using-lighthouse-dns/index.mdx
@@ -1,10 +1,10 @@
 ---
-title: Using Lighthouse DNS with Nebula
+title: Using lighthouse DNS with Nebula
 description:
-  Configure Nebula's experimental built-in DNS server on Lighthouse hosts to resolve overlay network hostnames.
+  Configure Nebula's experimental built-in DNS server on lighthouse hosts to resolve overlay network hostnames.
 ---
 
-# Using Experimental Lighthouse DNS with Nebula
+# Using experimental lighthouse DNS with Nebula
 
 :::warning
 
@@ -13,7 +13,7 @@ Lighthouse DNS in nebula is experimental and should not be considered to be a ro
 
 :::
 
-Nebula comes with built-in DNS server support via Lighthouse hosts.
+Nebula comes with built-in DNS server support via lighthouse hosts.
 
 Lighthouse DNS can generate DNS records based on dynamic nebula hosts, useful if you are spinning up new nebula hosts on
 demand.
@@ -24,7 +24,7 @@ This guide assumes you already have a working Lighthouse and at least one other
 haven't setup a Nebula network yet, check out the [Quick Start guide](/docs/guides/quick-start/).
 
 You'll then want to set up the lighthouse as a DNS server for the other two hosts. This can be either the public static
-lighthouse IP or the private nebula IP depending on the Lighthouse's configuration.
+lighthouse IP or the private nebula IP depending on the lighthouse's configuration.
 
 ## Configuration
 
@@ -44,7 +44,7 @@ ensure the DNS is only accessible to hosts that are allowed to contact the light
 
 :::note
 
-Only Lighthouses should have `lighthouse.serve_dns` enabled, as DNS info is collected when hosts report to the
+Only lighthouses should have `lighthouse.serve_dns` enabled, as DNS info is collected when hosts report to the
 lighthouse. Nebula will not honor the option if enabled on a non-lighthouse host.
 
 :::
@@ -103,7 +103,7 @@ curl --dns-servers "100.100.0.1" http://alice-laptop:3000
 - If the name in the Nebula certificate is not a [valid hostname](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.1),
   Lighthouse DNS will return an empty result.
 
-## Hostname Validity
+## Hostname validity
 
 import { ValidateHostnameInput } from './ValidateHostnameInput';
 
@@ -119,16 +119,16 @@ address visible to the internet, only users on your nebula network will be able
 
 - How do hostnames turn into DNS host names?
   - If the hostname is a [valid DNS name](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.1), it will be resolved by
-    the Lighthouse DNS resolver.
-- Do Lighthouse DNS queries support Unicode?
+    the lighthouse DNS resolver.
+- Do lighthouse DNS queries support Unicode?
   - DNS only supports ASCII, but has [support for Unicode via punycode](https://www.rfc-editor.org/rfc/rfc3492), for
     example:
     ```bash
     # `alice-xn--3s8h` = `alice-💻` in punycode.
     dig @100.100.0.1 +short alice-xn--3s8h A
     100.100.0.2
     ```
-    Nebula supports full unicode strings in the host name, but for hosts to be discovered via Lighthouse DNS, they must
+    Nebula supports full unicode strings in the host name, but for hosts to be discovered via lighthouse DNS, they must
     conform to the DNS spec. https://www.punycoder.com/ is a useful tool for conversion.
 - Are the domain names resolved with case sensitivity?
   - No, Nebula is compliant with [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.3) since version 1.7.0.

diff --git a/docs/guides/viewing-nebula-logs/index.mdx b/docs/guides/viewing-nebula-logs/index.mdx
@@ -1,11 +1,11 @@
 ---
-title: Viewing Nebula Logs
+title: Viewing Nebula logs
 description: How to view Nebula logs on Linux, macOS, Windows, iOS, and Android for troubleshooting and monitoring.
 ---
 
 import ThemedImage from '@theme/ThemedImage';
 
-# Viewing Nebula Logs
+# Viewing Nebula logs
 
 This guide explains how to view logs for Nebula in each of the supported platforms. Please note that these instructions
 are approximations as there are many ways that Nebula can be installed.

diff --git a/docs/intro.md b/docs/intro.md
@@ -7,7 +7,7 @@ slug: /
 sidebar_position: 1
 ---
 
-# Nebula: Open source overlay networking
+# Nebula: open source overlay networking
 
 Nebula is a self-hosted overlay networking tool designed to be fast, secure, and scalable. Connect any number of hosts
 with on-demand, encrypted tunnels that work across any IP networks and without opening firewall ports.
@@ -48,7 +48,7 @@ Nebula is written in Go and is designed for portability.
 - Efficiently runs on x86, ARM, MIPS, PPC, and RISC hardware (32 & 64-bit)
 - A single `nebula` executable runs host firewall and service
 - Host config file defines CA trust, host cert & key, and firewall rules
-- At least one host in overlay network should be a _Lighthouse_, which helps hosts discover routes to one another and
+- At least one host in overlay network should be a _lighthouse_, which helps hosts discover routes to one another and
   assists in NAT traversal.
 
 ## Getting started

diff --git a/docs/security/2025-10-07-source-ip-spoofing-defect.mdx b/docs/security/2025-10-07-source-ip-spoofing-defect.mdx
@@ -5,13 +5,13 @@ description:
   source IP when the sender's certificate is configured with unsafe_routes.
 ---
 
-# 2025-10-07 - Source IP Spoofing Defect
+# 2025-10-07 - Source IP spoofing defect
 
 Due to a bug in Nebula’s packet validation logic, hosts configured with a certificate that includes unsafe_routes (cert
 v1 / cert v2) or multiple IP addresses can spoof the source IP of packets sent to other hosts running an affected
 version of Nebula. We do not believe that it is possible to receive return traffic for the spoofed packets.
 
-## Affected Versions
+## Affected versions
 
 - v1.9.4 &ndash; v1.9.6 (stable)
 - v1.9.4-nightly20240801 &ndash; v1.10.0-nightly20240730 (nightly)

diff --git a/docs/security/_category_.json b/docs/security/_category_.json
@@ -1,5 +1,5 @@
 {
-  "label": "Security Bulletins",
+  "label": "Security bulletins",
   "position": 3,
   "link": {
     "type": "generated-index",

diff --git a/docusaurus.config.ts b/docusaurus.config.ts
@@ -81,7 +81,7 @@ const config: Config = {
     image: 'img/nebula-docs-og.png',
     metadata: [{ name: 'keywords', content: 'nebula, overlay network, VPN, mesh networking, defined networking' }],
     navbar: {
-      title: 'Nebula Documentation',
+      title: 'Nebula documentation',
       logo: {
         alt: 'Nebula logo',
         href: '/docs/',
@@ -107,11 +107,11 @@ const config: Config = {
               to: '/docs/guides/',
             },
             {
-              label: 'Config Reference',
+              label: 'Config reference',
               to: '/docs/config/',
             },
             {
-              label: 'Docs Github',
+              label: 'Docs GitHub',
               href: 'https://github.com/DefinedNet/nebula-docs',
             },
           ],