A preview environment should hold only synthetic data built by a seed script, run with scoped sandbox credentials, sit behind sign in, and be destroyed when the pull request closes or after a short time limit. Never clone production into it, because previews multiply, and each copy is a new exposure.
Why previews need rules
A preview environment is a temporary copy of your application created for one change, so reviewers can click through it. Teams may spin up dozens a week. Each one has a URL, a database and secrets. If previews start from a production copy, you create dozens of short lived copies of real data, many of them on infrastructure that nobody monitors.
The related post on ephemeral environments and security testing covers the testing angle. This one is about data and teardown.
Design rules
| Rule | Reason |
|---|---|
| Seed from code | Same fake data every time, nothing real |
| One database per preview | No shared state, no cross contamination |
| Sandbox keys only | A leaked preview key opens nothing real |
| Authentication in front | Preview URLs get shared in chat and tickets |
| Time to live | Abandoned previews do not run for months |
| Destroy on close | Data lifetime equals review lifetime |
Steps to set up
- Create a preview seed. Reuse the staging seed script with a small profile, so startup is fast. Fixed seeds make reviews comparable.
- Provision a fresh database per preview. A container or a small managed instance, named with the pull request number.
- Inject only preview secrets. Use a separate secret scope for previews with sandbox keys and a mail catcher. Avoid inheriting the staging scope wholesale.
- Protect the URL. Put previews behind your single sign on or a short lived token. Search engines and chat link unfurlers should not reach them.
- Tear down on close. Trigger destruction from the pull request closed event, and add a scheduled sweep that deletes any preview older than a set number of days.
- Include storage and DNS. Teardown must also remove buckets, queues, DNS records and any cached copies, not just the application containers.
- Report leftovers. Run a daily job that lists resources tagged as previews and posts any that outlived their pull request.
Handling forks and external contributors
Be careful when a pull request comes from a fork. Building a preview from untrusted code with access to secrets is a classic way to leak them. Use read only tokens and no secrets for fork builds, or require a maintainer to approve the preview.
Data kept after teardown
Think about logs and monitoring. Preview logs often flow to a shared logging system. Keep preview logs in their own index with short retention, and avoid logging request bodies.
Mistakes to avoid
- Cloning staging "because it is closer to production". Staging should not hold real data either.
- Sharing one preview database among several pull requests to save time.
- Leaving previews open to the internet with a guessable URL.
- Keeping the container image with baked in data after the preview is gone.
Where Safeguard fits
Safeguard can run dependency scanning and policy gates on a pull request, so a preview does not deploy a build that fails your rules. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Click through the pull request gate and watch what blocks a merge, then picture the same rule applied to a preview deploy.
Quick check
How long should a preview live?
Until the pull request closes, with a hard cap such as a few days. Make the cap explicit and automated.
Can QA use previews for realistic scenarios?
Yes, with richer synthetic profiles built for those scenarios. Real customer cases should not be copied in.
Sources
Last reviewed: 19 October 2026.
