docs: add IPv6 readiness guidance for Compute

compute/compute-and-alb.mdx

@@ -14,7 +14,7 @@ Instances have private IPv6 addresses only, so the internet can't reach them dir
 
 - Select a project, install the `compute` plugin, and get access to Compute. For more information, see [Compute commands](/datumctl/compute/overview).
 - Make sure that you have permission to create networking resources in the project, in addition to compute resources. The **Network Admin** role includes the permissions that publishing needs. The **Gateway Admin** role alone isn't enough.
-- Make sure that your app serves plain HTTP, not HTTPS, on the port that you publish, and listens on IPv6.
+- Make sure that your app serves plain HTTP, not HTTPS, on the port that you publish, and listens on IPv6. See [IPv6 readiness](/compute/troubleshooting#ipv6-readiness).
 
 ## Attach an ALB with datumctl
 

compute/configuration.mdx

@@ -21,7 +21,7 @@ You can set environment variables, and load or mount whole ConfigMaps and Secret
 
 ## Set environment variables
 
-To set an environment variable to a fixed value, pass `--env KEY=VALUE` when you deploy. Repeat the flag for each variable. Values can contain commas. The following command sets two variables:
+To set an environment variable to a fixed value, pass `--env KEY=VALUE` when you deploy. Repeat the flag for each variable. Values can contain commas. Instances have IPv6 addresses only, so use hostnames, not IPv4 addresses, in values such as database URLs. The following command sets two variables:
 
 ```bash
 datumctl compute deploy WORKLOAD_NAME \

compute/overview.mdx

@@ -1,11 +1,11 @@
 ---
 title: "Compute"
 sidebarTitle: "Overview"
-description: "Run your apps as isolated Instances in Datum Cloud locations, from a standard container image or a fast-starting unikernel."
+description: "Run your apps as isolated Instances in Datum Cloud locations, from a standard container image or a fast-starting unikernel. Instances are IPv6 only."
 ---
 
 <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
 
@@ -66,6 +66,10 @@
 - **`datumctl compute`:** A `datumctl` plugin that deploys, publishes, scales, and deletes workloads with a single command each. The guides in this section use it. For the command reference, see [Compute commands](/datumctl/compute/overview).
 - **Manifests:** Workloads are Kubernetes-style resources. You can write them in YAML and manage them with `datumctl apply`, `datumctl get`, and `datumctl describe`, or with GitOps tooling. For more information, see [Kubernetes](/platform/kubernetes).
 
+## IPv6 readiness
+
+Compute and gVPC are IPv6 only. An app that listens only on IPv4, such as `0.0.0.0`, is unreachable, and any IPv4 address in its configuration, such as a database URL, must become a hostname. Before you deploy your own app, see [IPv6 readiness](/compute/troubleshooting#ipv6-readiness).
+
 ## What's next
 
 <CardGroup cols={2}>

compute/troubleshooting.mdx

@@ -10,6 +10,25 @@
   Compute is in preview, and the `v1alpha` API can change.
 </Note>
 
+## IPv6 readiness
+
+Compute and gVPC are IPv6 only. Instances have no IPv4 address, and the internet reaches them only through the ALB. Check these before you deploy your own app:
+
+- **Listen on `::`.** An app bound to `0.0.0.0`, or to `listen 80;` in nginx, is unreachable. Bind the port that you pass to `--http-port` on `::`.
+- **Connect by hostname.** Use a name, not an IPv4 address, for every service the app calls, including database URLs and proxy targets in its config. See [Reach the internet](/galactic-vpc/networks/traffic).
+- **Serve plain HTTP.** Datum terminates TLS at the ALB and connects to your Instances over HTTP.
+
+| Server | Listen on IPv6 |
+| --- | --- |
+| nginx | `listen [::]:80;` |
+| Node.js | `app.listen(8080, "::")` |
+| Python | `uvicorn app:app --host :: --port 8080` |
+| Go | `http.ListenAndServe(":8080", handler)`, which listens on IPv6 and IPv4 |
+
+To check the listen address on a machine with IPv6, run `ss -ltn` and look for `[::]:8080`. An IPv4-only app shows `0.0.0.0:8080` instead.
+
+If you're an agent deploying an app for a user, search the code and config for `0.0.0.0`, `127.0.0.1`, `listen 80`, and IPv4 addresses, change them to `::` and hostnames, and then deploy with `--http-port`.
+
 ## Common problems
 
 The following table lists common errors and states, what they mean, and how to fix them. Errors that Datum returns when you apply a workload appear in the command output. Reasons appear in `datumctl get workloads`, `datumctl get instances`, and `datumctl compute instances describe`.
@@ -31,17 +50,17 @@
 | `ReferencedDataNotReady` with `SourceTooLarge` | A referenced ConfigMap or Secret is larger than 256 KiB, or all of them together exceed 1 MiB. | Make the objects smaller. |
 | `ReferencedDataNotReady` with `SourceUnauthorized` | Datum can't read a referenced ConfigMap or Secret. | Check that the object is in the same project, and contact support if the problem continues. |
 | `ImageUnavailable` | Datum couldn't pull the image. | Check the image reference and tag. For a private registry, check the `imagePullSecrets` Secret. |
 | A standard container image, such as nginx, won't start | You didn't set a runtime class, so the workload uses the default `unikernel` class, which doesn't boot standard container images. | Deploy a new workload with `--runtime-class=general-purpose`. You can't change a workload's runtime class. See [Run a container image](/compute/runtimes/general-compute). |
 | `InstanceCrashing` | The program starts and exits repeatedly. | Check the command, arguments, environment variables, and mounted files. For a `unikernel` workload, rebuild with `datumctl compute build --analyze`. |
 | `ConfigurationError` | Datum refused the configuration before the program ran. | Check the environment variables and volume references. |
 | The Instance stays `Starting` for more than a few minutes | The first image pull can take a while. A program that exits at startup can also stay in this state. | Check the image and configuration. For a `unikernel` workload, run `datumctl compute build --analyze`. If the problem continues, contact support. |
 | The Instance is `Available`, but the ALB's hostname returns an error | The app isn't reachable on the published port, or the container isn't running even though the Instance is `Available`. | Make sure that the app listens on IPv6 (`::`), serves plain HTTP, and uses the port that you passed to `--http-port`. Check the logs with `datumctl compute logs WORKLOAD_NAME`. If the container exits at startup, check its `securityContext`. See [Images that use sudo or setuid](/compute/runtimes/general-compute#images-that-use-sudo-or-setuid). |
 | The ALB returns `503` for a minute or two after the Instance becomes `Available` | The Instance is running, but the app inside it is still starting. | Wait, or give the app a faster startup. Apps such as JVMs can take a minute or more to listen. |
 | `sudo` or another setuid program fails with a permission error | `allowPrivilegeEscalation` defaults to `false`. | Do the privileged work at build time, or set `allowPrivilegeEscalation: true`. See [Images that use sudo or setuid](/compute/runtimes/general-compute#images-that-use-sudo-or-setuid). |
 | A new image version doesn't show up after a rollout | The image was pushed again under the same tag. | Push each version with a new tag, or reference the image by digest. |
 | An Instance can't connect to an IPv4 address, such as `203.0.113.10` | Instances have IPv6 addresses only. They reach IPv4-only services through DNS64 and NAT64, which work only when the app connects by hostname. | Connect by hostname. If the service has a public IPv4 address but no name, create an `A` record for it in a public DNS zone you control. See [Reach the internet](/galactic-vpc/networks/traffic#reach-the-internet). |
 | An Instance can't connect to an IPv4-only service by hostname | The app or image uses its own DNS resolver without DNS64, such as DNS over HTTPS or a hard-coded public resolver, which returns only IPv4 addresses. | Use the resolvers that Datum configures, in the Instance's `/etc/resolv.conf`. They perform DNS64. |
 | A destination that allowlists source addresses rejects the Instance | Outbound traffic leaves from addresses that are shared with other Datum customers and can change. | Authenticate to the destination with credentials, such as an API key or a client certificate, instead of allowlisting addresses. |
 | `curl` can't resolve the ALB's hostname | The new hostname hasn't propagated. | Wait a few minutes and try again. |
 
 ## See why an Instance won't start

datumctl/compute/deploying-workloads.mdx

@@ -14,6 +14,10 @@ datumctl compute deploy api \
   --http-port=8080
 ```
 
+<Note>
+  Datum networking is IPv6 only, and Instances have no IPv4 address. Before you run a deploy command for your own app, search the app's code and config (including `.env` files, database URLs, and proxy targets) for `0.0.0.0`, `127.0.0.1`, `listen 80`, and IPv4 addresses. Change them to `::` and hostnames, and tell the user what you changed. See [IPv6 readiness](/compute/troubleshooting#ipv6-readiness).
+</Note>
+
 <Warning>
   A new workload without `--runtime-class` runs on the `unikernel` runtime class. For that class, `--image` must point to an image produced by `datumctl compute build`, not a standard OCI image from `docker build` — see [Building images](/datumctl/compute/building-images). To run a standard container image unchanged, add `--runtime-class=general-purpose` — see [Choose a runtime class](/compute/runtimes/overview).
 </Warning>

getting-started/first-workload.mdx

@@ -7,6 +7,10 @@ description: "Deploy draw.io to Datum Compute and open it in your browser throug
   Compute is in preview. The `v1alpha` APIs can change, and Datum reviews Compute access requests manually.
 </Note>
 
+<Note>
+  Datum networking is IPv6 only. draw.io already listens on IPv6, so this tutorial works as written. To deploy your own app, make it listen on `::` first. See [IPv6 readiness](/compute/troubleshooting#ipv6-readiness).
+</Note>
+
 ## Before you begin
 
 - Create a Datum Cloud account, an organization, and a project. For more information, see [Account setup](/getting-started/account-setup).
@@ -106,7 +110,7 @@ This page deploys [draw.io](https://www.drawio.com/), an open source diagramming
 
 ## What's next
 
-- To deploy your own image, check that your app listens on IPv6 and serves plain HTTP. During the preview, Instances have no persistent disks and no readiness checks. For details, see [Compute limitations](/compute/limitations-and-roadmap#limitations).
+- To deploy your own image, check that your app listens on IPv6 and serves plain HTTP. See [IPv6 readiness](/compute/troubleshooting#ipv6-readiness). During the preview, Instances have no persistent disks and no readiness checks. For details, see [Compute limitations](/compute/limitations-and-roadmap#limitations).
 - To pass configuration and secrets to a workload, see [Compute configuration](/compute/configuration).
 - To package your own app as a fast-starting unikernel, see [Unikernels](/compute/runtimes/unikernels).
 - To run in more locations or with more Instances, see [Placement and scaling](/compute/placement-and-scaling).