How Does a PR Get Its Own URL?
The developer experience lives or dies on this question. If opening a PR automatically produces a clickable link to a live preview, the workflow is magical. If the developer has to manually look up an IP address, it is useless.
Three components must work together to produce a dynamic, HTTPS URL for every PR:
1. Wildcard DNS
In your DNS provider (Route 53, Cloudflare, etc.), you create a single wildcard A record mapping every subdomain of *.dev.mycompany.com to the load balancer's IP. This single record means that pr-101.dev.mycompany.com, pr-102.dev.mycompany.com, and any other subdomain all resolve to the same Kubernetes Ingress Controller. The Ingress Controller then routes traffic to the correct namespace based on the hostname in the HTTP request.
2. Dynamic Ingress Resource
Your Helm chart must generate an Ingress object with a hostname derived from the PR number. This is where Helm's templating engine does the work: the chart's Ingress template interpolates the PR number into both the TLS host list and the routing rule's host, pointing at the wildcard TLS secret and the PR's own Service.
When the CI pipeline runs helm upgrade --install with the PR number passed in as a value, Helm renders this template and creates an Ingress that routes pr-123.dev.mycompany.com to the correct Service in the correct namespace.
3. Wildcard TLS Certificate
You provision a single wildcard TLS certificate for *.dev.mycompany.com — either via cert-manager with Let's Encrypt DNS-01 challenge, or by uploading a purchased wildcard cert as a Kubernetes Secret. This certificate is valid for all subdomains, so pr-123.dev.mycompany.com and pr-456.dev.mycompany.com are both served over HTTPS without generating new certificates per PR.
The certificate is stored as a Kubernetes Secret (e.g., wildcard-tls-secret) in a shared namespace and referenced by each PR's Ingress resource.
Interviewers often ask: "How do you handle TLS for ephemeral environments without hitting Let's Encrypt rate limits?" The answer is a wildcard certificate using the DNS-01 ACME challenge (not HTTP-01). DNS-01 allows you to prove domain ownership via a DNS TXT record, which works for wildcard domains. HTTP-01 does not support wildcards. A single wildcard cert for *.dev.mycompany.com covers unlimited subdomains with no per-PR certificate issuance.
Key Point: The Ingress Controller is the traffic cop for the entire ephemeral environment system. It receives all traffic destined for *.dev.mycompany.com and uses the Host header in each HTTP request to route it to the correct backend Service. This means the Load Balancer IP never changes — only the Ingress rules inside the cluster change as PRs are opened and closed. This architecture scales to hundreds of concurrent environments with no DNS changes required.