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.

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 now 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.
  • Use a hostname domain when one public FQDN should get its own Gateway managed HTTP-01 certificate.

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 and publish the Gateway service into your tailnet.

One important rule stays in place: hostname domains require a public Gateway API controller. Preview environments also remain wildcard-only.

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 for 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