For AI agents: The documentation index is at https://docs.digitalocean.com/llms.txt. Markdown versions of pages use the same URL with index.html.md in place of the HTML page (for example, append index.html.md to the directory path instead of opening the HTML document).

Isolated Worker Nodes is a DigitalOcean Kubernetes (DOKS) feature that runs every worker node in a cluster without a public IPv4 address. The nodes are isolated from the public internet at the network level rather than only protected by a firewall. Other DigitalOcean resources in the same VPC network can still reach the nodes over private addresses, and outbound internet access for provisioning, control plane registration, and image pulls goes through a VPC NAT Gateway.

Isolation applies to worker nodes only. It does not make the Kubernetes API server private: the control plane endpoint stays publicly reachable so you can manage the cluster. To restrict which public IP addresses can reach the API server, add a control plane firewall.

How Isolated Worker Nodes Work

When you create a cluster with Isolated Worker Nodes enabled:

• Every worker node receives a private IPv4 address only. Nodes are not assigned a public IPv4 address.
• Nodes communicate with the control plane over its internal endpoint. Initial node provisioning and registration require VPC NAT Gateway egress before that internal path is established.
• Outbound internet traffic, including node provisioning and container image pulls for both DOKS-managed components and your workloads, routes through the VPC’s default NAT Gateway.
• Other resources in the same VPC can communicate with the nodes over private addresses.

This differs from a cloud firewall, which can block unwanted traffic but leaves a public IPv4 address assigned, so the node stays internet-addressable. Isolated Worker Nodes remove the public IPv4 address entirely.

Prerequisites

Before you create a cluster with Isolated Worker Nodes, you need the following:

• A personal access token with permission to create Kubernetes clusters. Store the token in an environment variable named DIGITALOCEAN_TOKEN.
• A VPC network in the region where you plan to create the cluster.
• A VPC NAT Gateway in that VPC, set as the default gateway for the VPC. The NAT Gateway lets nodes provision, register with the control plane, and pull container images. Self-managed NAT on Droplets and other custom NAT setups are not supported.
• A cluster running Kubernetes 1.36 or later.

If the VPC has multiple NAT Gateways, use the routing agent after the nodes join the cluster to send traffic for specific destinations through different gateways. For more detail on pairing DOKS with a NAT Gateway, see How to Configure DOKS for NAT Gateway.

Worker node pricing is the same as for standard DOKS clusters. See Kubernetes pricing. Because the feature requires a VPC NAT Gateway, the gateway is billed separately. See VPC NAT Gateway pricing.

Size the NAT Gateway

Size the NAT Gateway for peak egress bandwidth and concurrent connection volume, not average load. Sizing the gateway too small can cause SNAT port exhaustion, where outbound connections fail or hang, and bandwidth throttling when traffic exceeds capacity. Autoscaling events can intensify both issues when many nodes provision and pull images through the same gateway IP address at once. For large or high-throughput clusters, increase the size increment or split egress across multiple NAT Gateways.

Create a Cluster with Isolated Worker Nodes

You enable Isolated Worker Nodes only when you create the cluster. If you do not enable it, the cluster defaults to worker nodes with public IPv4 addresses. You can enable it using doctl, the DigitalOcean API, or Terraform. The cluster’s VPC must already have a NAT Gateway set as its default gateway.

The following examples create a cluster in the NYC1 region with Isolated Worker Nodes enabled. Replace <vpc-uuid> with the ID of your VPC, and set the node pool size and count for your workload. Use a Kubernetes version of 1.36 or later, which you can retrieve from the list Kubernetes options endpoint.

doctl kubernetes cluster create example-cluster \
  --region nyc1 \
  --version 1.36 \
  --vpc-uuid <vpc-uuid> \
  --isolated-workers=true \
  --node-pool "name=worker-pool;size=s-2vcpu-4gb;count=3"

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  -d '{
    "name": "example-cluster",
    "region": "nyc1",
    "version": "1.36.1-do.0",
    "vpc_uuid": "<vpc-uuid>",
    "isolated_workers": true,
    "node_pools": [
      {
        "name": "worker-pool",
        "size": "s-2vcpu-4gb",
        "count": 3
      }
    ]
  }' \
  "https://api.digitalocean.com/v2/kubernetes/clusters"

resource "digitalocean_kubernetes_cluster" "example" {
  name             = "example-cluster"
  region           = "nyc1"
  version          = "1.36.1-do.0"
  vpc_uuid         = "<vpc-uuid>"
  isolated_workers = true

  node_pool {
    name       = "worker-pool"
    size       = "s-2vcpu-4gb"
    node_count = 3
  }
}

To also restrict which public IP addresses can reach the API server, add a control plane firewall in the same create request.

Verify Isolated Worker Nodes

After the cluster finishes provisioning, confirm that isolation is enabled, that the nodes have no public IPv4 address, and that outbound traffic uses the NAT Gateway.

Confirm Isolation Is Enabled

Retrieve the cluster with doctl and check the isolated_workers field:

doctl kubernetes cluster get example-cluster

You can also retrieve the cluster through the API. Replace <cluster-id> with the ID of your cluster:

curl -X GET \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  "https://api.digitalocean.com/v2/kubernetes/clusters/<cluster-id>"

The cluster object shows isolated_workers set to true.

Confirm Nodes Have No Public IPv4 Address

Save the cluster’s kubeconfig, then list the nodes with wide output:

doctl kubernetes cluster kubeconfig save example-cluster
kubectl get nodes -o wide

The EXTERNAL-IP column is <none> for each node, and each node has a private INTERNAL-IP.

You can also check each node’s Droplet directly. Get the droplet_id from the node pool, then retrieve the Droplet’s addresses. Replace <droplet-id> with the ID of a node’s Droplet:

doctl compute droplet get <droplet-id> --format PublicIPv4,PrivateIPv4

The public IPv4 address is empty and a private IPv4 address is present.

Confirm Outbound Traffic Uses the NAT Gateway

To confirm that image pulls succeed through the NAT path, deploy a workload that pulls a public image:

kubectl run verify-pull --image=nginx:latest --restart=Never
kubectl wait --for=condition=Ready pod/verify-pull --timeout=120s
kubectl get pod verify-pull

The pod reaches the Running state, which means the image pull succeeded.

To confirm outbound egress, run a test pod that makes an HTTP request:

kubectl run verify-egress -it --rm --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w "%{http_code}\n" https://example.com

The request returns a successful HTTP response, such as 200. Traffic egresses through the VPC’s default NAT Gateway, so the source public IP address is the gateway’s, not a node’s. On the NAT Gateway details page, you can confirm recent outbound traffic while the test runs.

Limitations

• You can enable node isolation only when you create the cluster. You cannot convert an existing cluster or add public IPv4 addresses to worker nodes later.
• Isolation is a cluster-wide setting on the cluster object (isolated_workers), not a per-node-pool option. A cluster cannot contain both public and isolated worker nodes.
• Public Network Load Balancers are not supported, because they preserve the client IP to the node and require a direct public path that Isolated Worker Nodes remove. Use HTTP load balancers (public or private), internal load balancers, or private Network Load Balancers. See How to Add Load Balancers to Kubernetes Clusters.
• Isolated Worker Nodes require a DigitalOcean VPC NAT Gateway set as the default gateway for the cluster’s VPC. Cluster creation validates that a default VPC NAT Gateway exists, and only a managed VPC NAT Gateway can be designated as the VPC’s default gateway.