IaC Ephemeral Preview Environments Prompt
Design per-pull-request ephemeral infrastructure environments that spin up on open, expose a preview, and tear down automatically so they never leak cost or orphaned resources.
- Target user
- Platform engineers building PR-based preview environments on cloud IaC
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who builds per-PR ephemeral environments and has cleaned up enough orphaned cloud resources to design teardown as a first-class concern, not an afterthought. I will provide: - The IaC tool and backend ([Pulumi / OpenTofu / CDK / Crossplane] + state/stack backend). - The stack a PR environment needs (e.g. [a service + db + queue], or a namespace on a shared cluster). - Our CI system and cost constraints. Your job: 1. **Namespace per PR** — design a deterministic, collision-free naming/stack scheme keyed to the PR number so two PRs never clash and resources are easy to identify and find later. 2. **Spin-up flow** — define the CI job that provisions on PR open/update: plan/preview first, apply, then post the preview URL and a teardown reminder back to the PR. 3. **Guaranteed teardown** — design teardown on PR close/merge AND a scheduled reaper that destroys any environment older than [TTL] regardless of PR state, so a failed close-hook never leaks resources. 4. **Cost guardrails** — pick the smallest viable resource sizes, set hard limits, and tag every resource with pr-number/ttl/owner so a cost report and the reaper can find strays. 5. **Isolate blast radius** — ensure a PR env can never touch shared/prod state, secrets, or data; use a separate account/project/namespace and scoped credentials. 6. **Handle partial failures** — make spin-up and teardown idempotent so a re-run cleans up a half-created environment instead of compounding the mess. Output as: (a) the naming/stack scheme, (b) the spin-up CI job, (c) the teardown job + reaper, (d) the tagging and cost-guard policy, (e) the isolation model. Always plan/preview before apply in the spin-up job, and make the reaper the safety net that runs even when the normal teardown path fails. Never let a PR environment share credentials with production.
Why this prompt works
Ephemeral preview environments are the feature everyone wants and almost everyone implements with a fatal gap: teardown that depends on a PR-close webhook firing successfully. Webhooks fail, jobs time out, force-pushes confuse the state, and three months later you discover forty orphaned databases quietly billing. This prompt makes guaranteed teardown a first-class deliverable by demanding two destruction paths — the normal close/merge hook and an independent time-based reaper that destroys anything older than a TTL regardless of PR state. That redundancy is the single most important design decision in the whole system, which is why the prompt and its safety notes both hammer it.
The isolation requirement addresses the security reality that preview environments run code from branches that haven’t necessarily passed full review. A PR environment that shares credentials or state with production is a privilege-escalation path: open a PR, modify the IaC, and the spin-up job applies it with prod access. By forcing a separate account/project/namespace and scoped credentials, the prompt keeps an attacker (or an honest mistake) contained to a throwaway environment. The deterministic per-PR naming scheme is the unglamorous enabler — without it, two concurrent PRs collide, and the reaper can’t reliably identify what to destroy.
The cost guardrails and tagging tie the system together operationally. Tagging every resource with pr-number, ttl, and owner means the reaper has something to query and your finance team has something to attribute, turning “where is this spend coming from” from an investigation into a filter. Idempotent spin-up and teardown handle the partial-failure case that always happens at scale, where a half-created environment must be cleanable by a re-run rather than requiring manual surgery. Pair this with the multi-environment promotion prompt and the cost estimation CI gate prompt, and browse the IaC category for more pipeline tooling.
Related prompts
-
IaC Cost Estimation CI Gate Prompt
Wire Infracost (or equivalent) into pull-request CI so infrastructure changes show a cost diff and breach a budget gate before merge — turning cloud spend into a reviewable, policy-enforced number.
-
Multi-Environment IaC Promotion Pipeline Prompt
Design a dev → stage → prod promotion pipeline for infrastructure where the same code ships to every environment, differences live in config, and prod changes are reviewed, gated, and reversible.