Skip to main content
With direct IP routing, traffic reaches your applications through your worker nodes’ public IP addresses. You point your domains at your workers via DNS, and a controller on the cluster routes requests to the correct application based on the hostname. This approach is ideal for self-hosted clusters where you manage the nodes and have direct access to their public IPs.

​
How it works with CNAP-managed clusters

Clusters created through CNAP use as the , which includes a built-in Gateway API controller. Cilium’s envoy proxy runs on every worker via host network mode, listening on ports 80 and 443: 
Client → worker-node-ip:80 → Cilium envoy (host network) → HTTPRoute match → Service → Pod
The envoy proxy checks the Host header against all configured and forwards matching traffic to the correct application, regardless of which node the app’s pod runs on.

​
Imported and cloud-hosted clusters

If you import an existing cluster into CNAP, the Gateway API controller depends on your Kubernetes setup:
  • Cloud providers (GKE, EKS, AKS) — typically include their own Gateway API controller backed by cloud load balancers. Traffic goes through the cloud’s load balancer rather than directly to worker node IPs, so you don’t need to manage A records yourself.
  • Self-hosted with Cilium — works the same as CNAP-managed clusters. Deploy a Cilium Gateway from your cluster’s detail page.
  • Other CNIs — consult the documentation for your CNI or Kubernetes distribution to set up a Gateway API controller. The HTTPRoute workflow stays the same, only the underlying controller and how traffic enters the cluster differs.

​
Prerequisites

  • A cluster with a Gateway API controller (Cilium Gateway for CNAP-managed and self-hosted clusters, or a cloud-provided controller)
  • One or more worker nodes with public IP addresses (for direct IP setups)
  • A domain you control with access to its DNS settings

​
Set up a custom domain

1

Expose a port

For Docker and GitHub apps, go to Settings > Ports or the app creation flow and toggle Expose externally on the port you want to make public. Enter your domain (for example, app.yourdomain.com) as the hostname.For custom Helm charts, configure the HTTPRoute hostname through the chart’s own values (the field name varies by chart).
2

Set up DNS

The gateway runs on every worker node, so any worker with a public IP can receive traffic. Choose a DNS strategy based on your setup:
Create one A record pointing your domain at the worker’s public IP:
Record typeNameValue
Aapp.yourdomain.comWorker’s public IP
DNS propagation can take a few minutes to a few hours depending on your provider and TTL settings.
3

Verify

Once DNS has propagated, open http://app.yourdomain.com in your browser. The gateway routes the request to your application based on the hostname.

​
Test before DNS propagation

You can verify that the gateway routing works correctly before creating DNS records. Use curl with an explicit Host header to simulate what a browser does after DNS resolves: 
curl -H 'Host: app.yourdomain.com' http://<server-ip>/
Replace <server-ip> with your worker node’s public IP and app.yourdomain.com with the hostname you configured.
  • If you see your app’s response — the routing is correct. Create the DNS record and you’re done.
  • If you get a 404 from envoy — the hostname doesn’t match any HTTPRoute. Double-check the hostname in your app’s port configuration matches exactly what you’re passing in the Host header.
This works because HTTP routing is based entirely on the Host header. The curl command sends the same header a browser would send after resolving your domain through DNS — the only difference is you’re connecting directly to the server IP instead of going through DNS.

​
Troubleshooting

The gateway is running but no HTTPRoute matches the request’s Host header. Check that:
  • The hostname in your app’s port configuration matches your domain exactly
  • The port has Expose externally toggled on
  • The HTTPRoute was created (check the app’s status)
The gateway’s envoy proxy isn’t running on the worker node. Verify that:
  • A Cilium Gateway is deployed to the cluster
  • The gateway pod is running and healthy
  • Host network mode is enabled in the Cilium configuration
This is normal with Cilium’s host network mode. The gateway creates a ClusterIP service (not a LoadBalancer), so the status never reports an external IP. Traffic still flows correctly through the host network envoy proxy.
DNS propagation can take time. While waiting, use the curl test above to confirm routing works. If curl returns your app, the issue is DNS propagation — not routing.