Skip to main content
Preview domains are coming soon. This page will be updated when the feature is available.
Every deployment gets a public HTTPS URL on *.cnap.app — no DNS records, no certificates, no configuration. Toggle Expose externally on a port and you have a working URL in seconds. For custom domains or more control over routing, CNAP also supports bringing your own Cloudflare Tunnel or routing directly to your nodes. Other platforms offer preview URLs too (Vercel, Cloudflare Workers, Fly.io), but they run your app on shared infrastructure. CNAP preview domains are different: your app stays on your clusters, on your servers. Cloudflare only handles the edge routing — traffic flows through a tunnel directly to the workload running on your infrastructure.

​
How it works

  1. You expose a port on your app and choose a subdomain (for example, myapp.cnap.app)
  2. An is created on your cluster — a Gateway API controller detects it and configures the routing automatically
  3. Cloudflare handles TLS and routes requests through the tunnel to your app
Browser → Cloudflare Edge (TLS) → Tunnel → Your Cluster → App

​
Why use preview domains

  • Zero setup — No DNS provider, no certificate authority, no gateway configuration
  • Instant sharing — Send a link to a teammate or client the moment you deploy
  • Your infrastructure — Traffic routes to your own cluster, not a shared platform. You keep full control over where your workload runs
  • Automatic HTTPS — TLS is terminated at Cloudflare’s edge, every URL is secure by default

​
Limitations

Preview domains are fully managed by CNAP — the tunnel, the subdomain, and the DNS. That makes them effortless, but it also means you don’t control the Cloudflare configuration. There are no options for access policies, custom headers, or tunnel-level settings. For production workloads that need custom domains or fine-grained tunnel configuration, CNAP supports bringing your own Cloudflare Tunnel — you connect your own Cloudflare account and manage the tunnel settings yourself. You can also point your DNS directly at your worker nodes for full control over the routing stack.

​
Under the hood

Preview domains use the same Cloudflare Tunnel infrastructure as custom domain tunnels, but CNAP manages the Cloudflare account and credentials on your behalf. One tunnel per cluster. The first time you expose a port with a preview domain, CNAP provisions a Cloudflare Tunnel for your cluster and deploys a cloudflared agent as a Kubernetes Deployment. Subsequent preview domains on the same cluster reuse the same tunnel — no additional infrastructure is created. You choose your subdomain. When you expose a port, you pick the subdomain — myapp.cnap.app, api-staging.cnap.app, whatever fits. Subdomains are unique across all CNAP users (first come, first served). If you don’t provide one, CNAP suggests a name based on your app. When a subdomain is released, CNAP reserves it for a grace period before making it available again, preventing accidental takeover during reconfigurations. Routing is Kubernetes-native. Under the hood, exposing a port creates a standard Gateway API HTTPRoute on your cluster. A controller watches for these routes and pushes the corresponding hostname configuration to Cloudflare’s tunnel. Because routing is defined through standard Kubernetes resources, it works with GitOps workflows, custom Helm charts, and kubectl apply — CNAP’s UI is one way to create routes, not the only way. DNS is a CNAME. Each preview subdomain is a proxied CNAME record pointing to {tunnel-id}.cfargotunnel.com. Cloudflare resolves this to their nearest edge node, terminates TLS, and forwards the request through the tunnel. The cloudflared agent on your cluster receives the request and routes it to the correct Kubernetes Service based on the hostname. Local tunnel config. Unlike custom domain tunnels where ingress rules are pushed to Cloudflare’s API (so they appear in your CF dashboard), preview domain ingress rules are configured locally on the cluster. The controller writes the routing rules to a config file and cloudflared reads them directly — no polling delay. DNS CNAME records are still created per hostname via CNAP’s API, but the routing logic itself stays on the cluster for faster updates. Credentials never touch your cluster. CNAP’s Cloudflare credentials are managed centrally. The controller on your cluster authenticates with CNAP’s API using a scoped service account token — it never holds Cloudflare API keys directly.