One PR can map to one namespace, one image tag, and one preview URL using GitHub Actions, Helm, and Kubernetes in your repo. Full breakdown.
One PR, one environment
Ephemeral preview deploys turn each pull request into a short-lived environment that lives only while the PR is open. The practical mapping is simple: one PR maps to one Kubernetes namespace, one image tag, and one preview URL. Reviewers stop arguing from screenshots or “works on my machine” and instead open a real stack—same manifests, same chart values, same ingress pattern as production, just scoped to that change.
That isolation is the point. Shared staging queues force PRs to wait, collide, or overwrite each other. Per-PR namespaces keep secrets, config, and traffic separate. When the PR merges or closes, the namespace and its resources go away, so you do not accumulate orphaned services and disks from half-finished experiments.
Wiring GitHub Actions to the cluster
A typical flow starts when a PR is opened or updated. The workflow builds a container image, tags it with something unique to that PR (for example the PR number or commit SHA), and pushes it to your registry. A later job authenticates to the cluster, ensures a namespace exists for that PR, and runs a Helm install or upgrade against that namespace using the new image tag and a small set of preview-specific values.
Keep the pipeline idempotent. Re-running the same workflow on a new commit should upgrade the existing release, not invent a second namespace. Use stable names derived from the PR number for the namespace, Helm release, and ingress host so cleanup and status checks stay predictable. Fail the job if the deploy cannot become ready within a reasonable window; a green check that points at a crash-looping pod is worse than a red one.
Helm values and the preview URL
Helm is the contract between CI and the cluster. Base values match what you ship; an overlay or values file for previews sets the image tag, scales replicas down if you want cheaper previews, and configures ingress. The preview URL usually follows a pattern such as a subdomain per PR on a shared base domain. That host should be computed in the workflow and written back to the PR as a comment or deployment status so reviewers never hunt through CI logs.
- Namespace and release names keyed to the PR number
- Image tag unique per build (PR number, SHA, or both)
- Ingress host and TLS consistent with your cluster’s DNS setup
- Resource limits sized for review traffic, not full production load
Avoid stuffing production secrets into every preview unless the app truly needs them. Prefer dedicated preview credentials, mock external services, or feature flags that disable expensive side effects. The environment should be realistic enough to catch integration bugs, not a copy of production with write access to live systems.
Lifecycle, cost, and review hygiene
Create on open, update on push, destroy on close or merge. The destroy step is non-negotiable: delete the Helm release, then the namespace, and confirm the image tag policy so old preview images do not pile up forever. If a PR sits idle, a scheduled job that tears down namespaces older than a threshold keeps the cluster from filling with abandoned previews.
Treat the preview as part of the review checklist. Smoke-test the URL after deploy, link it in the PR, and require that the environment stays healthy while review is open. With GitHub Actions building and tagging, Helm applying a consistent chart, and Kubernetes isolating each PR in its own namespace, you get a repeatable path from branch to URL—and a clean teardown when the work is done.