Preview Environments per PR: The Setup That Pays Back Quickly

Preview environments make every PR demo-able and every reviewer effective. The setup is one-time; the dividend is every PR.

Why preview environments

Code review on a static diff misses behavior. Code review with a working preview catches regressions and UX issues at PR time, not after merge.

Speeds review; catches issues earlier; reduces back-and-forth.

Four implementation components

• 1. Per-PR namespace in Kubernetes.
• 2. Per-PR DNS via wildcard SSL.
• 3. Seeded test data per env.
• 4. Auto-teardown on PR close/merge.

Cost control

Use spot/preemptible nodes; share data layer (point at a shared dev DB).

At scale, manage with quotas: max N preview envs per team; oldest auto-evicted.

Lifecycle discipline

Auto-teardown is the discipline. Without it, envs pile up; cost explodes.

Idle >48h envs auto-pause; idle >7d auto-delete.

Antipatterns

• Per-PR full data clone. Cost explodes.
• No auto-teardown. 200 idle envs by quarter end.
• Production-equivalent for previews. Wasteful; previews are dev-tier.

What to do this week

Three moves. (1) Apply this to one pipeline first. (2) Measure deploy frequency / MTTR before/after. (3) Document the outcome so the next team starts from data.