docs: Compute Internet access + NAT + private dns fixes

compute/limitations-and-roadmap.mdx

@@ -17,9 +17,9 @@
 ### Runtime and sizing
 
 - One instance type is available, and you can't set CPU or memory for each container.
 - Persistent disks, raw devices, GPUs, and custom virtual machine images aren't available. Files written at runtime are lost when Datum replaces an Instance.
 - 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.
 
@@ -27,11 +27,13 @@
 
 - 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.

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,13 +20,13 @@
 
 - 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
 
 You create a *workload*. A workload holds a template for the Instances you want (image, command, environment variables, and ports) and one or more *placements* that say where to run them and how many to run in each location.
 
-For each location in a placement, Datum starts the requested number of Instances there. Every Instance attaches to a [network](/galactic-vpc/overview) in your project and receives a private IPv6 address. To reach a workload from the internet, attach Datum's [Application Load Balancer (ALB)](/alb/overview) to it.
+For each location in a placement, Datum starts the requested number of Instances there. Every Instance attaches to a [network](/galactic-vpc/overview) in your project and receives a private IPv6 address. Instances can connect out to the internet, including to IPv4-only services by hostname; see [Reach the internet](/galactic-vpc/networks/traffic#reach-the-internet). To reach a workload from the internet, attach Datum's [Application Load Balancer (ALB)](/alb/overview) to it.
 
 The following diagram shows a workload with one placement in two locations:
 

compute/private-dns.mdx

@@ -1,75 +1,68 @@
 ---
 title: "Private DNS for Compute"
 sidebarTitle: "Private DNS"
-description: "How Compute publishes stable private names for instances attached to a Datum VPC."
+description: "How Compute publishes stable private names for Instances on a gVPC network."
 ---
 
 Compute integrates with [Private DNS](/domain-dns/private-dns) to publish a
-predictable name for an instance in each VPC to which it is attached. The name
-resolves to the instance's programmed private IPv4 and IPv6 addresses and is
-visible only within the associated VPC's DNS context.
-
-<Note>
-  The Compute integration is under active development and is not yet a stable,
-  generally available interface.
-</Note>
+predictable name for each Instance on the [network](/galactic-vpc/overview)
+that it attaches to. The name resolves to the Instance's private addresses and
+resolves only from inside that network.
 
 ## Instance names
 
-Compute publishes instance identity names beneath the `instances` subtree of
-the VPC's managed namespace. A name has this general form:
+Compute publishes Instance names beneath the `instances` subtree of the
+network's managed DNS suffix. A name has this general form:
 
 ```text
-<instance-name>.instances.<vpc-managed-suffix>
+<instance-name>.instances.<network-managed-suffix>
 ```
 
-Compute normalizes the instance name into a valid DNS label when necessary. If
-two instance names normalize to the same DNS name, Private DNS keeps the first
-claim and reports a name conflict for the other instance.
+Compute normalizes the Instance name into a valid DNS label when necessary. If
+two Instance names normalize to the same DNS name, Private DNS keeps the first
+claim and reports a name conflict for the other Instance.
 
-Treat the complete name reported by the service as an output. The managed
-suffix is a platform allocation and should not be constructed or parsed by
-applications.
+Treat the complete name that Datum reports as an output. The managed suffix is
+a platform allocation, so don't build or parse it in your app.
 
-The allocated hostname and its publication state are reported for each network
-in `Instance.status.dns`.
+Datum reports the allocated hostname and its publication state in
+`Instance.status.dns`.
 
 ## Published addresses
 
 Compute publishes:
 
-- `A` records for private IPv4 addresses.
 - `AAAA` records for private IPv6 addresses.
+- `A` records for private IPv4 addresses. Instances have IPv6 addresses only
+  during the preview, so they have no `A` records.
 
-An address is eligible only while the instance is ready, its runtime is ready,
-and its network interface reports that the address is both allocated and
-programmed. Public addresses and delegated prefixes are not published as
-instance identity records.
+An address is published only while the Instance is ready, its runtime is
+ready, and its network interface reports that the address is both allocated
+and programmed. Public addresses and delegated prefixes aren't published as
+Instance records.
 
-Instance readiness covers the managed runtime and network attachment. Use the
-application's own health checks or a service-specific discovery mechanism when
-traffic should be sent only to healthy application endpoints.
+Instance readiness covers the runtime and the network attachment, not your
+app. To send traffic only to healthy app endpoints, use your app's own health
+checks or a [network service](/galactic-vpc/networks/network-services).
 
 ## Lifecycle behavior
 
-Compute continuously reconciles the DNS records from current instance and
-network state:
+Compute keeps the DNS records in step with the current Instance and network
+state:
 
-- Address changes update the records behind the stable identity name.
+- Address changes update the records behind the stable name.
 - An unavailable or deprogrammed interface withdraws its addresses.
-- Deleting the instance removes its published records.
-- Resource lifetime checks prevent an old instance from publishing addresses
-  after it has been replaced.
-- An instance attached to more than one VPC receives independently isolated
-  DNS state for each VPC.
-
-Publication is asynchronous. A running instance can become ready before its
-name is visible in every resolver, and clients can retain an older answer until
+- Deleting the Instance removes its records.
+- An old Instance can't publish addresses after it has been replaced.
+
+Publication is asynchronous. A running Instance can become ready before its
+name is visible in every resolver, and clients can keep an older answer until
 the DNS TTL expires.
 
 ## Network access
 
-Resolving an instance name does not grant access to the instance. The client
-must still have a valid route and be permitted by the applicable network
-policy. Clients outside the associated VPC context cannot resolve the private
-instance name through public DNS.
+Resolving an Instance name doesn't grant access to the Instance. The client
+must still be able to reach the Instance on the network. Firewall rules aren't
+available yet, so any Instance on the same network can connect to any port.
+See [Traffic and connecting](/galactic-vpc/networks/traffic). Clients outside
+the network can't resolve the name through public DNS.

compute/troubleshooting.mdx

@@ -31,14 +31,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

domain-dns/dns.mdx

@@ -10,7 +10,7 @@ sidebarTitle: "Authoritative DNS"
 
 To manage zones and records from the terminal with the `datumctl dns` plugin, see [Operations](/domain-dns/operations).
 
-Looking for names that resolve only inside a VPC? See [Private DNS](/domain-dns/private-dns).
+Looking for names that resolve only inside a gVPC network? See [Private DNS](/domain-dns/private-dns).
 
 ## Current features
 

domain-dns/overview.mdx

@@ -1,12 +1,12 @@
 ---
 title: "Domains and DNS"
 sidebarTitle: "Overview"
-description: "Track and verify domains, host authoritative DNS, and resolve private names inside Datum VPCs."
+description: "Track and verify domains, host authoritative DNS, and resolve private names inside gVPC networks."
 ---
 
 Datum treats domains and DNS zones as resources in your project. You can track
 and verify domains, host public zones on Datum's global anycast network, and use
-Private DNS to resolve resources inside your VPCs.
+Private DNS to resolve resources inside your gVPC networks.
 
 <CardGroup cols={2}>
   <Card title="Domains" icon="globe" href="/domain-dns/domains">
@@ -16,7 +16,7 @@ Private DNS to resolve resources inside your VPCs.
     Host authoritative DNS for your zones on Datum's global anycast network.
   </Card>
   <Card title="Private DNS" icon="shield-halved" href="/domain-dns/private-dns">
-    Resolve private resource and service names inside your VPCs.
+    Resolve private resource and service names inside your gVPC networks.
   </Card>
 </CardGroup>
 

domain-dns/private-dns.mdx

@@ -1,35 +1,30 @@
 ---
 title: "Private DNS"
-description: "Resolve private service and resource names within a Datum VPC."
+description: "Resolve private service and resource names within a gVPC network."
 ---
 
-Private DNS gives resources in a Datum VPC names that resolve only from that
-VPC. It provides a consistent discovery layer for private addresses without
-requiring every product or workload to run its own DNS server.
-
-<Note>
-  Private DNS is under active development. Availability and supported service
-  integrations may vary while the feature is in preview.
-</Note>
+Private DNS gives resources in a [gVPC](/galactic-vpc/overview) network names
+that resolve only from that network. It provides a consistent discovery layer
+for private addresses without requiring every product or workload to run its
+own DNS server.
 
 ## What you can do
 
 With Private DNS, you can:
 
 - **Reach resources by name:** Use DNS names instead of private IP addresses
-  that may change over a resource's lifetime.
+  that can change over a resource's lifetime.
 - **Use automatic service names:** Integrated Datum services publish names for
-  resources such as Compute instances.
-- **Create private namespaces:** Organize internal applications under private
-  zones that are available only to associated VPCs.
-- **Reuse internal names safely:** Different VPCs can use the same names and
-  overlapping private addresses without exposing answers to each other.
+  resources such as Compute Instances.
+- **Create private namespaces:** Organize internal apps under private zones
+  that only associated networks can resolve.
+- **Reuse internal names safely:** Different networks can use the same names
+  and overlapping private addresses without exposing answers to each other.
 - **Keep records aligned with resources:** Service-managed records update or
   disappear as their resources and addresses change.
 
-Applications use ordinary DNS lookups. When they run in an associated VPC,
-private names resolve alongside public names without application-specific
-resolver configuration.
+Apps use ordinary DNS lookups. On an associated network, private names
+resolve alongside public names with no resolver configuration in the app.
 
 ## Private and public DNS
 
@@ -38,46 +33,46 @@
 | Capability | Where names resolve | Typical use |
 | --- | --- | --- |
 | [Authoritative DNS](/domain-dns/dns) | The public internet | Websites, public APIs, email, and domain records |
-| Private DNS | Inside an associated VPC | Private instances, internal services, and service discovery |
+| Private DNS | Inside an associated network | Private Instances, internal services, and service discovery |
 
-Private DNS records are not published to the public DNS. Creating a private
-name does not make a resource reachable from the internet or grant network
-access to it.
+Private DNS records aren't published to public DNS. A private name doesn't
+make a resource reachable from the internet or grant network access to it.
 
 ## Names and zones
 
-Each VPC receives a managed DNS suffix for automatic service names. You can
-also associate private zones with a VPC for organization-specific names.
+Each network receives a managed DNS suffix for automatic service names. You can
+also associate private zones with a network for your own names.
 
-- **Managed names:** Datum services publish predictable names beneath the VPC's
-  managed suffix.
-- **Private zones:** Your internal names are visible only from the VPCs with
-  which the zone is associated.
+- **Managed names:** Datum services publish predictable names beneath the
+  network's managed suffix.
+- **Private zones:** Your internal names resolve only from the networks that
+  the zone is associated with.
 
-The complete service-managed name includes the VPC's allocated suffix. Use the
-name reported by the service instead of constructing it in application code.
+The complete service-managed name includes the network's allocated suffix. Use
+the name that the service reports instead of building it in your app.
 
 ## Service integrations
 
-The resource name, published record types, and eligibility rules are defined by
-the service that owns the resource.
+The service that owns a resource defines its name, its record types, and when
+it's published.
 
 <CardGroup cols={2}>
   <Card title="Compute" icon="microchip" href="/compute/private-dns">
-    Learn how Compute publishes stable private names for instance addresses.
+    Learn how Compute publishes stable private names for Instances.
   </Card>
 </CardGroup>
 
-Additional Datum services will be documented here as Private DNS integrations
+Datum will document more services here as their Private DNS integrations
 become available.
 
-## What Private DNS does not do
+## What Private DNS doesn't do
 
-- **Provide public discovery:** Private names are not available through public
+- **Provide public discovery:** Private names aren't available through public
   DNS.
-- **Grant network access:** Routing and access policy still determine whether a
-  client can reach the returned address.
-- **Replace application health checks:** A name can resolve while the
-  application itself is unavailable.
-- **Remove cached answers immediately:** Clients may retain an older answer
+- **Grant network access:** Whether a client can reach the returned address
+  depends on the network, not on DNS. See
+  [Traffic and connecting](/galactic-vpc/networks/traffic).
+- **Replace app health checks:** A name can resolve while the app itself is
+  unavailable.
+- **Remove cached answers immediately:** Clients can keep an older answer
   until its DNS TTL expires.

galactic-vpc/limitations-and-roadmap.mdx

@@ -15,17 +15,22 @@
 - 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.
 - 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
 
 Datum is working on the following networking capabilities:
 
 - **Firewall rules:** Security groups that control the traffic to and from your Instances.
 - **Private DNS:** Private DNS names, so Instances can find each other without IP addresses.
+- **Internet access setting:** A setting that turns internet access on or off for every Instance on a network.
+- **Datum DNS resolver:** A DNS resolver that Datum runs for Instances, which also performs DNS64.
 
-Outbound internet access, including IPv4 destinations, and viewing networks in the Datum Cloud portal are already available. For details, see [Traffic and connecting](/galactic-vpc/networks/traffic).
+Outbound internet access, including IPv4 destinations, and viewing networks in the Datum Cloud portal are already available. For details, see [Reach the internet](/galactic-vpc/networks/traffic#reach-the-internet).
 
 For what Datum is building next across the platform, see the [Platform roadmap](/platform/roadmap).