dlotterman · Nov 11, 2026
diff --git a/alb/limitations-and-roadmap.mdx b/alb/limitations-and-roadmap.mdx
@@ -9,7 +9,7 @@ The Application Load Balancer is still being built. This page lists known limita
 ## Limitations
 
 - There is no single composite ALB API yet. An ALB is an `HTTPProxy`, a `TrafficProtectionPolicy`, and optional authentication resources. See [What an ALB is made of](/alb/overview#what-an-alb-is-made-of).
-- Public traffic is HTTP and HTTPS only. Raw TCP and UDP exposure isn't available.
+- An ALB serves HTTP and HTTPS only. To publish raw TCP or UDP traffic, such as a database or a game server, use a [Network Load Balancer](/nlb/overview).
 - Rule exclusions, score thresholds, rate limiting, and circuit breaking aren't available through `datumctl alb`. Use manifests. See [Web application firewall](/alb/configuration/waf).
 - A `connector` backend must be the only backend in its rule.
 - You can't choose which Datum locations serve a load balancer or set its capacity. [Envoy](/platform/envoy) in every location serves every load balancer, and Datum scales the fleet.

diff --git a/alb/overview.mdx b/alb/overview.mdx
@@ -10,14 +10,14 @@
 
 Datum's Application Load Balancer (ALB) is an edge proxy built on [Envoy](/platform/envoy), with a [Coraza](https://www.coraza.io/)-based [web application firewall](/alb/configuration/waf) (WAF). It started life as Datum's "AI Gateway", and it's built for AI and agent traffic as much as for websites and APIs.
 
-Application Load Balancers help you protect and route internet traffic to your backend services. We support HTTP(S) 1.1, HTTP/2, HTTP/3, gRPC, and WebSockets. See [How the load balancer handles requests](/alb/request-handling).
+Application Load Balancers help you protect and route internet traffic to your backend services. We support HTTP(S) 1.1, HTTP/2, HTTP/3, gRPC, and WebSockets. See [How the load balancer handles requests](/alb/request-handling). For raw TCP or UDP traffic, such as a database or a game server, use a [Network Load Balancer](/nlb/overview) instead.
 
 <Tip>
   Running NGINX, Apache, Caddy, or Traefik in front of your app? To replace that container with an ALB, see [Use ALB as your HTTP proxy](/guides/alb-as-httpd).
 </Tip>

 <Frame caption="The overview for a load balancer: whether it is serving, live request rate, error rate, latency and blocked requests, and the hostnames it answers on">
  ![The Datum Cloud console showing an Application Load Balancer's overview, with live request rate, error rate, p95 latency, requests blocked by the firewall, and a panel for attaching custom hostnames](/images/alb-overview.png)
 </Frame>

 ## How it works
@@ -82,7 +82,7 @@

 Each Application Load Balancer deploys with a default hostname and enforces HTTPS (you can disable this).

 - **Protection** - The [**OWASP Coraza Web Application Firewall (WAF)**](https://www.coraza.io/) provides built-in protection with the [OWASP Core Rule Set](https://coreruleset.org/), running inside Envoy before requests reach your origin. A load balancer created with `datumctl alb create` starts in `Enforce` mode at sensitivity 1. A `TrafficProtectionPolicy` that doesn't set a mode runs in `Observe` mode. See [Roll out traffic protection safely](/alb/operations/traffic-protection).
 - **Custom Hostnames** – Verify domains (or use already verified domain resources) to use custom hostnames with an Application Load Balancer.
 - **Basic Authentication** - Add a username and password to restrict access to an Application Load Balancer.
 - **Load Balancing** - Split traffic across several origins by weight, choose the load balancing algorithm, and turn on passive health checks. See [Load balancing and health checks](/alb/configuration/load-balancing).

diff --git a/changelog.mdx b/changelog.mdx
@@ -9,7 +9,7 @@
 <Update label="November 10, 2026" description="Application Load Balancer" tags={["Fix"]}>
  ## New load balancers serve traffic sooner

  - **Fixed:** a new ALB no longer returns `503` for several minutes when its compute workload runs in a different location than the edge serving the request. Datum now rebuilds the load balancer's routing as soon as it learns which network the workload is on.

  See [ALB troubleshooting](/alb/troubleshooting).
 </Update>
@@ -37,7 +37,7 @@
   - **Fixed:** deleting a listener works on the first try.
   - **Fixed:** the **Add listener** dialog no longer flashes a warning as it closes.
 
-  NLBs are early access. See [Network services](/galactic-vpc/networks/network-services).
+  NLBs are early access. See [NLB operations](/nlb/operations).
 </Update>
 
 <Update label="November 6, 2026" description="datumctl" tags={["AX/DX/UX"]}>
@@ -150,7 +150,7 @@
  - **Managed zone:** every network gets its own `datum.internal` zone. Compute publishes each Instance at `<instance-name>.instances.datum.internal`. See [Private DNS for Compute](/compute/private-dns).
  - **Your own private zones:** associate private zones with a network for internal names. The zone class is now optional for private zones.
  - **Network isolation:** a network can't be pointed at another network's private DNS, and the same names can be reused across networks without leaking answers.
  - **Availability:** lookups go only to healthy DNS servers, so server updates no longer stall lookups until they time out.
  - **Regions:** a private zone is served only in the regions its networks use, and is withdrawn from regions it leaves.
  - **Fixed:** a CNAME that points into another private zone now returns the target's answer over UDP, not just the CNAME.
  - **Fixed:** the managed `datum.internal` zone can't be deleted while its network uses it. Deleting a project still removes it.
@@ -164,14 +164,14 @@
 
   Publish a network service on a public TCP or UDP port with a network load balancer (NLB).
 
-  - **Addresses and hostnames:** each location gets a public IPv6 address and a generated hostname you can point a CNAME at. IPv4 is available for single-port listeners where Datum has enabled it.
+  - **Addresses and hostnames:** each location gets a public IPv6 address and a generated hostname you can point a CNAME at. IPv4 isn't available yet.
   - **Health checks:** NLBs actively check backends and send new connections only to healthy ones.
   - **UDP ports:** network services now accept UDP ports, and the create-service dialog has a TCP/UDP selector per port. A UDP listener also needs a TCP port on the backend for its health check.
   - **Portal:** create an NLB, copy its hostname and address, and add, edit, or delete listeners in the [Cloud Portal](https://cloud.datum.net).
 
   NLBs are early access. TLS listeners aren't supported yet, but a TCP listener forwards TLS traffic unchanged to your backend. Each route serves one backend. An ALB that points at a UDP port now reports a clear unsupported-protocol error.
 
-  See [Network services](/galactic-vpc/networks/network-services).
+  See [NLB](/nlb/overview).
 </Update>
 
 <Update label="October 29, 2026" description="datumctl" tags={["Fix"]}>
@@ -191,7 +191,7 @@
  When a custom hostname's DNS is hosted outside Datum, the [Cloud Portal](https://cloud.datum.net) now shows whether it points at your ALB.

  - **DNS Ready** appears once Datum sees the CNAME or matching IPs pointing at the ALB.
  - **Awaiting DNS** appears until then, with a tooltip that names the record to add. The chip no longer spins indefinitely.
  - **Fixed:** an ALB whose single backend carries the Host override can now be edited in the portal instead of showing **Managed with datumctl**.

  See [Custom domains](/alb/operations/custom-domains).

diff --git a/compute/compute-and-alb.mdx b/compute/compute-and-alb.mdx
@@ -150,3 +150,4 @@ In addition to the [limitations that apply to all of Compute](/compute/limitatio
 - To run in more locations so that more users reach a nearby Instance, see [Placement and scaling](/compute/placement-and-scaling).
 - To learn more about `HTTPProxy` routing and options, see [Application Load Balancer](/alb/overview).
 - To learn how Instances connect privately, see [Traffic and connecting](/galactic-vpc/networks/traffic).
+- To publish a TCP or UDP port that isn't HTTP, such as a database or a game server, see [NLB operations](/nlb/operations).
diff --git a/compute/limitations-and-roadmap.mdx b/compute/limitations-and-roadmap.mdx
@@ -18,9 +18,9 @@

 - One instance type is available, and you can't set CPU or memory for each container.
 - Persistent disks aren't available. The workload API includes a `disk` volume type, but no runtime class serves it, so Datum rejects a workload that declares one. Files written at runtime are lost when Datum replaces an Instance. For details, see [Disk volumes](/compute/configuration#disk-volumes).
 - Raw devices, GPUs, and custom virtual machine images aren't available.
 - Instances with more than one container aren't supported. Run one container per workload.
 - Health probes, such as readiness and liveness checks, aren't available. An Instance is ready when its containers are running.
 - You can't suspend, resume, or snapshot Instances. You can open a shell or run a command in a running `general-purpose` Instance; see [Instance shell sessions](/compute/instance-shell).
 - A workload's runtime class and network can't change after you create it.

@@ -28,16 +28,16 @@

 - Compute runs in `us-central-1` (Dallas), `us-east-1` (Ashburn), and `us-west-1` (San Jose).
 - Workloads don't scale automatically, and they can't scale to zero. Don't set `scaleSettings.maxReplicas` or `scaleSettings.metrics`.
 - Rollouts replace Instances one at a time in each location, with no option to add extra Instances during the rollout.

 ### Networking

 - During the preview, Instances have private IPv6 addresses only. Private IPv4 addresses and public IP addresses are a preview limitation.
 - Instances reach IPv4-only internet services by hostname only, through DNS64 and NAT64. A connection to an IPv4 address fails. See [Reach the internet](/galactic-vpc/networks/traffic#reach-the-internet).
 - Every Instance can reach the internet, and you can't turn that off. Outbound traffic leaves from shared addresses that Datum doesn't publish, so you can't allowlist your Instances at a destination.
 - Private DNS names for Instances are on the [roadmap](/galactic-vpc/limitations-and-roadmap#planned-capabilities).
 - Firewall rules to filter traffic between Instances on a network are on the [roadmap](/galactic-vpc/limitations-and-roadmap#planned-capabilities).
-- Public access is HTTP and HTTPS only, served through Datum's [ALB](/alb/overview). Raw TCP and UDP exposure is a preview limitation.
+- Public HTTP and HTTPS traffic reaches Instances through Datum's [ALB](/alb/overview). Public TCP and UDP traffic reaches them through a [Network Load Balancer](/nlb/overview), which is in early access, serves IPv6 only, and is available only in `us-central-1`, `us-east-1`, and `us-west-1`.
 
 For more information about networking, see [gVPC limitations and roadmap](/galactic-vpc/limitations-and-roadmap). To learn which networking capabilities Datum is working on, see [Planned capabilities](/galactic-vpc/limitations-and-roadmap#planned-capabilities).
 

diff --git a/compute/overview.mdx b/compute/overview.mdx
@@ -5,7 +5,7 @@
 ---

 <Note>
 **Working with this product via an AI agent?** [Datum MCP](/agents/datum-mcp) gives agents live access to workloads and Instances through its `compute` toolset, including Compute's own diagnostic tools. For an open-ended question such as "why isn't my workload available?", agents can ask [Patch](/datumctl/ai/assistant) with `datumctl assistant chat`.
 </Note>

 Datum Cloud Compute runs your app close to your users. You describe what to run and where, and Datum starts isolated Instances in the locations you choose, connects them to a private network, and can serve them publicly through Datum's Application Load Balancer (ALB).
@@ -20,7 +20,7 @@

 - Run an HTTP service or API in more than one location without operating servers.
 - Deploy a container image you already build, with virtual machine isolation.
 - Start small, purpose-built services in a fraction of a second as unikernels.

 ## How it works

@@ -51,6 +51,7 @@
 | Runtime class | The execution tier for a workload's Instances: `general-purpose` or `unikernel`. You choose it when you create the workload. |
 | Network | The private network your Instances attach to. `datumctl compute deploy` uses a network named `default`. |
 | ALB | Datum's [Application Load Balancer](/alb/overview), which serves public HTTP and HTTPS traffic to your workload's Instances. |
+| NLB | Datum's [Network Load Balancer](/nlb/overview), which forwards public TCP and UDP traffic to your workload's Instances. |
 
 ## Runtime classes
 

diff --git a/docs.json b/docs.json
@@ -195,6 +195,27 @@
                 ],
                 "expanded": false
               },
+              {
+                "group": "NLB",
+                "pages": [
+                  "nlb/overview",
+                  {
+                    "group": "Concepts",
+                    "root": "nlb/listeners-and-routes",
+                    "pages": [
+                      "nlb/addresses-and-hostnames",
+                      "nlb/health-checks",
+                      "nlb/traffic-handling"
+                    ]
+                  },
+                  "nlb/operations",
+                  "nlb/observability",
+                  "nlb/troubleshooting",
+                  "nlb/limits-and-quotas",
+                  "nlb/limitations-and-roadmap"
+                ],
+                "expanded": false
+              },
               {
                 "group": "Connectors",
                 "pages": [
@@ -217,6 +238,7 @@
                   "domain-dns/private-dns",
                   "domain-dns/operations",
                   "domain-dns/point-to-alb",
+                  "domain-dns/point-to-nlb",
                   "domain-dns/observability",
                   "domain-dns/troubleshooting",
                   "domain-dns/limits-and-quotas",

diff --git a/domain-dns/point-to-nlb.mdx b/domain-dns/point-to-nlb.mdx
@@ -0,0 +1,65 @@
+---
+title: "Point a domain at an NLB"
+description: "Use Datum DNS to give a Network Load Balancer a name on your own domain, with a CNAME to the generated hostname of one of its locations."
+sidebarTitle: "Point to an NLB"
+---
+
+When Datum hosts your domain's DNS, you can give a [Network Load Balancer](/nlb/overview) (NLB) a name on your domain, such as `db.example.com`, with a `CNAME` record. Clients then connect to `db.example.com` on the listener's port.
+
+An NLB has a generated hostname for each location and each listener, such as `us-central-1.lively-otter-x7k2p.datumproxy.net`. A record on your domain points at one of them, so it sends clients to one location. See [Addresses and hostnames](/nlb/addresses-and-hostnames).
+
+<Note>
+  If your DNS is hosted somewhere else, you don't need anything on this page. Create a `CNAME` to the NLB's generated hostname at your own DNS provider.
+</Note>
+
+Unlike an [Application Load Balancer](/alb/overview), an NLB doesn't need your domain added to it, and it doesn't issue a certificate for it. If clients use TLS, your workload must present a certificate for your domain.
+
+## Point a domain with datumctl dns
+
+To install the `dns` plugin, run `datumctl plugin install dns`.
+
+<Steps>
+  <Step title="Find the NLB's hostname">
+    ```bash
+    datumctl get networkloadbalancer NLB_NAME \
+      -o jsonpath='{range .status.endpoints[*]}{.location}{"\t"}{.requestName}{"\t"}{.canonicalHostname}{"\n"}{end}'
+    ```
+
+    Each line shows a location, an address request, and its hostname. Pick the hostname for the location and listener that you want.
+  </Step>
+  <Step title="Create the zone, if you haven't already">
+    ```bash
+    datumctl dns zone create example.com
+    ```
+
+    Then point your domain at Datum's nameservers. See [Point your domain at Datum](/domain-dns/operations#point-your-domain-at-datum).
+  </Step>
+  <Step title="Add the record">
+    ```bash
+    datumctl dns record set example.com db CNAME GENERATED_HOSTNAME.
+    ```
+
+    Replace `GENERATED_HOSTNAME` with the NLB's hostname, and keep the trailing dot.
+
+    To use the apex, `example.com`, create an `ALIAS` record instead, because a `CNAME` isn't allowed at the apex. See [ALIAS](/domain-dns/dns#alias-/-cname-flattening).
+
+    ```bash
+    datumctl dns record set example.com @ ALIAS GENERATED_HOSTNAME.
+    ```
+  </Step>
+  <Step title="Check that it works">
+    ```bash
+    datumctl dns record list example.com --type CNAME,ALIAS
+    dig +short AAAA db.example.com
+    ```
+
+    The record is live when its status is `Programmed`. `dig` returns the NLB's IPv6 address for that location.
+  </Step>
+</Steps>
+
+To create the same records with `DNSZone` and `DNSRecordSet` manifests, follow [Point a domain with manifests](/domain-dns/point-to-alb#point-a-domain-with-manifests), and use the NLB's hostname as `TARGET`.
+
+## What's next
+
+- To learn when a hostname starts serving, see [Generated hostnames](/nlb/addresses-and-hostnames#generated-hostnames).
+- To check that the NLB is serving, see [Check that an NLB is serving](/nlb/operations#check-that-an-nlb-is-serving).
diff --git a/galactic-vpc/limitations-and-roadmap.mdx b/galactic-vpc/limitations-and-roadmap.mdx
@@ -13,12 +13,12 @@
 In addition to the [networking limitations that apply to all of Compute](/compute/limitations-and-roadmap#networking), networks have the following limitations:
 
 - Each workload attaches to exactly one network through one network interface, and it can't move to another network.
-- Instance addresses aren't reachable from the internet. To serve traffic publicly, attach an [ALB](/alb/overview) to the workload.
+- Instance addresses aren't reachable from the internet. To serve traffic publicly, attach an [ALB](/alb/overview) to the workload for HTTP and HTTPS, or an [NLB](/nlb/overview) for TCP and UDP.
 - The `networkPolicy` field of a network interface has no effect. Don't rely on it to restrict traffic. Firewall rules are a planned capability.
 - You can't choose a network's address ranges or create your own subnets.
 - Networks carry Compute traffic only in the locations where Compute runs: `us-central-1`, `us-east-1`, and `us-west-1`.
 - Every network can reach the internet, and you can't turn that off.
 - Outbound internet traffic leaves from addresses that are shared with other Datum customers. Datum doesn't publish them, so a destination can't allowlist your Instances by address.
 - Instances reach IPv4-only internet services by hostname only. A connection to an IPv4 address fails. See [Reach the internet](/galactic-vpc/networks/traffic#reach-the-internet).

 ## Planned capabilities
@@ -42,4 +42,5 @@
 
 - To learn which traffic a network carries, see [Traffic and connecting](/galactic-vpc/networks/traffic).
 - To serve a workload publicly through Datum's ALB, see [Publish a workload](/compute/compute-and-alb).
+- To publish a TCP or UDP port, see [NLB operations](/nlb/operations).
 - To run Instances in more locations, see [Placement and scaling](/compute/placement-and-scaling).
diff --git a/galactic-vpc/networks/network-services.mdx b/galactic-vpc/networks/network-services.mdx
@@ -4,7 +4,7 @@
 description: "Give a workload's Instances a stable name and named ports on a gVPC network, and send load balancer traffic to them."
 ---
 
-A network service gives a workload's Instances on one network a stable name and named ports. Datum keeps the service's membership current as Instances start, stop, and move between locations, and sends each request to the nearest location that has a ready Instance. Datum's [Application Load Balancer](/alb/overview) reaches a workload through a network service.
+A network service gives a workload's Instances on one network a stable name and named ports. Datum keeps the service's membership current as Instances start, stop, and move between locations, and sends each request to the nearest location that has a ready Instance. Datum's [Application Load Balancer](/alb/overview) and [Network Load Balancer](/nlb/overview) reach a workload through a network service.
 
 <Note>
   gVPC is in preview, and the `networking.datumapis.com/v1alpha` API can change.
@@ -15,7 +15,7 @@
 A network service is a `NetworkService` resource with two parts:
 
 - **A selector:** labels that an Instance's network interface must carry to belong to the service. Every Instance of a workload carries the workload's name as a label, so a service usually selects one workload.
-- **Ports:** the ports the Instances listen on, each with a name, such as `http` on port `8080`. A load balancer refers to a port by its name, not its number.
+- **Ports:** the ports the Instances listen on, each with a name, a number, and a protocol, `TCP` or `UDP`, such as `http` on TCP port `8080`. A load balancer refers to a port by its name, not its number.
 
 Keep the following points in mind:
 
@@ -51,13 +51,15 @@
 
 To add more ports, repeat `--port`. A service takes up to 16 ports, and each name and number must be unique.
 
+`datumctl network service create` creates TCP ports only. To add a UDP port, use the Cloud Portal or a manifest. See [Add UDP ports](#add-udp-ports).
+
 By default, a load balancer connects to a port over HTTP/1.1. For a port that serves gRPC or another HTTP/2 app without TLS (h2c), use the long form of `--port` with `app-protocol=h2c`, such as `--port=name=grpc,port=9090,app-protocol=h2c`. The load balancer then sends every request on that port as HTTP/2. Most servers accept WebSockets only over HTTP/1.1, so serve WebSockets on a different port.
 
 To select Instances by label instead of by workload, use `--selector`, such as `--selector app=web`. The labels must be on the Instances' network interfaces, not only on the workload.

 ## Send load balancer traffic to a network service

 To send a load balancer's traffic to a network service, name the service and one of its port names:

 ```bash
 datumctl alb create LOAD_BALANCER_NAME \
@@ -67,6 +69,37 @@
 
 For more information, see [Create a load balancer](/alb/operations/overview#create-a-load-balancer).
 
+To publish a port on a public TCP or UDP port, send a [Network Load Balancer](/nlb/overview)'s traffic to it with a route instead. A route names the service and one of its port names, and the port's protocol must match the NLB listener's. See [Listeners and routes](/nlb/listeners-and-routes).
+
+## Add UDP ports
+
+To give a service a UDP port, such as for an NLB, describe the service in a manifest and set `protocol` on each port. The following service has a UDP port for a game server, and a TCP port for the NLB's health check:
+
+```yaml game-service.yaml
+apiVersion: networking.datumapis.com/v1alpha
+kind: NetworkService
+metadata:
+  name: game
+spec:
+  networkInterfaces:
+    selector:
+      matchLabels:
+        compute.datumapis.com/workload-name: game
+  ports:
+    - name: game
+      port: 7777
+      protocol: UDP
+    - name: health
+      port: 8080
+      protocol: TCP
+```
+
+The `compute.datumapis.com/workload-name` label selects every Instance of the named workload. To create the service, run `datumctl apply -f game-service.yaml`.
+
+In the [Cloud Portal](https://cloud.datum.net), the create-service dialog has a **TCP** or **UDP** choice for each port.
+
+An ALB can't send traffic to a UDP port.
+
 ## Check a network service
 
 To see what a service selects, its ports, and where it's serving, run the following command:
@@ -109,8 +142,11 @@
 
 Before it asks you to confirm, the command lists the load balancers that send traffic to the service. Those load balancers stop reaching anything on that route.
 
+Deleting a network service with `datumctl delete networkservice` doesn't check for NLB routes. An NLB whose route uses the service stops serving, and the route reports `BackendNotFound`. See [Delete an NLB](/nlb/operations#delete-an-nlb).
+
 ## What's next
 
 - To manage networks and Instances' network interfaces from the command line, see [Operations](/galactic-vpc/operations).
 - To publish a workload with a load balancer in one step, see [Compute and ALB](/compute/compute-and-alb).
+- To publish a TCP or UDP port, see [NLB operations](/nlb/operations).
 - To learn how Instances connect privately, see [Traffic and connecting](/galactic-vpc/networks/traffic).
diff --git a/galactic-vpc/networks/overview.mdx b/galactic-vpc/networks/overview.mdx
@@ -19,7 +19,7 @@ A network belongs to a project, not to a location. The following list describes
 - **Many workloads on one network:** Several workloads can name the same network. For example, a frontend workload and a backend workload can share a network.
 - **Addresses are private IPv6:** Each network gets its own private IPv6 prefix from the unique local address range. Each Instance gets an address from that prefix. The addresses aren't reachable from the internet. For more information, see [Addressing](/galactic-vpc/networks/addressing).
 - **Networks are isolated:** Each network is separate from every other network, including other networks in the same project and other customers' networks.
-- **Public traffic arrives through Datum's ALB:** To serve a workload on the internet, attach Datum's [Application Load Balancer](/alb/overview) to it. The ALB reaches a workload through a [network service](/galactic-vpc/networks/network-services), which gives the workload's Instances a stable name and named ports, and forwards each request to an Instance over the private network. For more information, see [Compute and ALB](/compute/compute-and-alb).
+- **Public traffic arrives through a load balancer:** To serve a workload on the internet, attach Datum's [Application Load Balancer](/alb/overview) to it for HTTP and HTTPS, or a [Network Load Balancer](/nlb/overview) for raw TCP and UDP. The ALB reaches a workload through a [network service](/galactic-vpc/networks/network-services), which gives the workload's Instances a stable name and named ports, and forwards each request to an Instance over the private network. For more information, see [Compute and ALB](/compute/compute-and-alb).
 
 ## The default network