Skip to main content
CNAP provides multiple ways to make your applications accessible from outside the cluster. All options use on the cluster to define routing rules — the difference is how traffic reaches your workers and who manages DNS. Choose the approach that fits your setup:

Preview Domains

Instant *.cnap.app URL for every deployment — no DNS, no certificates, no configuration.

Direct IP

Point your domain’s DNS at your worker nodes. Full control over routing and TLS.

Cloudflare Tunnel

Route through Cloudflare’s network. No public IPs or firewall rules needed.

​
Comparison

Direct IPCloudflare TunnelPreview Domains
Public IP requiredYesNoNo
DNS setupYou manage A recordsYou set a CNAMEAutomatic
TLSBring your ownCloudflare EdgeAutomatic
Best forFull control, existing infrastructureProduction custom domains without public IPsDevelopment, demos, quick sharing
Traffic pathDNS → Worker node → AppDNS → Cloudflare Edge → Tunnel → AppDNS → Cloudflare Edge → Tunnel → App

​
How routing works

All three options use resources on the cluster. When you expose a hostname, an HTTPRoute is created that defines the routing rule. A controller on the cluster detects the route and configures the appropriate gateway — whether that’s a Cloudflare Tunnel or a direct IP gateway like Cilium. Because routing is defined through standard Kubernetes resources, it works with GitOps tools like Flux and ArgoCD, custom Helm charts, and kubectl apply. For apps deployed from Docker images or GitHub repositories, CNAP automates the routing setup — toggle Expose externally on a port, enter a hostname, and the generic application chart creates the HTTPRoute for you. Apps deployed from custom Helm charts can create HTTPRoutes through the chart’s own values.