Back to Blog

ARTICLE // INSIGHTS

Gateway, Domains, and Tailscale in One Traffic Flow

Camil Blanaru / 21 Mar, 2026
Gateway, Domains, and Tailscale in One Traffic Flow

Edka’s traffic model is now much clearer: Gateway manages entry points, Domains manages DNS and TLS, and Tailscale covers private tailnet exposure.

This matters because clusters now support more than one path for HTTP traffic, without forcing everything into the same domain or certificate flow.

Update — July 22, 2026: Exact hostname domains can now use DNS-01 on public or private Gateway classes. Wildcard domains can also route their base hostname with the same DNS validation and certificate. The sections below describe the current behavior; preview environments remain wildcard-only.

What changed

  • Gateway API is the primary traffic path for new internet-facing workloads. You can create public, private, or tailnet-published Gateway classes from the cluster Gateway tab.
  • Domains now supports both wildcard and hostname domains. Wildcards such as *.example.com are still the right choice for shared deployment hostnames and preview environments. Hostname domains such as app.example.com get their own HTTP-01 certificate on a public Gateway.
  • Tailscale is integrated into the same model. You can either use direct tailscale ingress for hostnames like grafana.<tailnet>.ts.net, or publish an Envoy Gateway class into your tailnet with Tailscale tailnet (BYOD).

How the pieces fit together

For public traffic, use a Gateway API traffic class and manage the DNS records from the Domains view:

  • Use a wildcard domain when multiple workloads should share one domain and TLS should be issued with DNS-01. Include the base hostname when example.com should route through the same certificate as *.example.com.
  • Use a hostname domain when one FQDN should get its own Gateway-managed certificate. Choose HTTP-01 for a public Gateway or DNS-01 for a public or private Gateway.

For private traffic, install the Tailscale operator and choose one of two paths:

  • Use direct tailscale ingress when you want Tailscale to generate the final hostname and certificate.
  • Use Tailscale tailnet (BYOD) Gateway classes when you want to keep Gateway API routing, publish the Gateway service into your tailnet, and use DNS-01 with a wildcard or exact hostname you own.

One important rule stays in place: preview environments remain wildcard-only. Exact hostname domains require a managed Gateway API class; only HTTP-01 specifically requires that class to be public.

Why this is useful

This split lets you choose the right exposure model per workload:

  • public Gateway with wildcard TLS for shared app domains
  • public Gateway with HTTP-01 or DNS-01 for single hostnames
  • private Gateway with DNS-01 for wildcard or single hostnames
  • direct Tailscale exposure for private service endpoints
  • tailnet-published Gateway classes for private Gateway API traffic

That makes the platform easier to reason about and avoids mixing public DNS, wildcard delegation, and tailnet-only traffic in one setup.

Read the docs

Back to All Posts