How we use a preview environment simulator to map the PR to teardown flow

Setting up preview environments is a straightforward concept—label a PR, trigger a build, spin up a namespace, and kill it all when the PR closes—but the actual plumbing is complex. To get my team on the same page, I've been using the Preview Environment Simulator. It breaks the entire sequence into five scenes, and if you toggle "Practice a failure," it actually forces you to debug a realistic block with three repair options, only one of which actually works.

Breaking down the five-scene sequence

The simulator uses a progress strip at the top so you can see exactly where the process stands. While you make the calls in the first and last steps, the automation in the middle pauses so you can actually see what's happening behind the scenes.

1. Developer intent: You start with a GitHub-style PR list. Adding the preview label is the specific trigger that kicks everything off.
2. Webhook event: GitHub sends the pull_request labeled event. The receiver validates the signature, confirms the label=preview on acme/store, and forces an Argo CD ApplicationSet refresh so the pull-request generator picks it up immediately instead of waiting for the next poll.
3. GitHub Actions: The runner builds an image tagged with that specific commit and pushes it to the registry. This tag is critical because it's how the review page identifies the exact revision currently running.
4. Argo CD console: You watch the resource tree populate automatically. This includes the Argo CD application, namespace, deployment, service, ingress, certificate, and a Neon database branch for the PR, ending with a revision and readiness hook.
5. PR preview URL: This is the final review page. It lists the URL, deployed revision, namespace, TTL, workload list, image tag, database branch, and an access check. It also displays the hourly cost and an isolation score. From here, you either approve, request changes, or close the PR to trigger the cleanup.

Comparing the three preview scenarios

The simulator uses three fixed scenarios to show how different environment shapes impact cost and isolation.

• PR 184 (checkout-v2): This is a coordinated web and API preview using a masked snapshot of stage data. It uses a balanced resource profile with team SSO and an eight-hour TTL. The cost is listed at $0.53/hr with 88% isolation.
• PR 183 (order-status-api): A lean, single-service API preview using synthetic fixtures. With team SSO and a six-hour TTL, this costs $0.15/hr and hits 96% isolation.
• PR 182 (checkout-worker): This bundles the web, API, and worker together with a masked snapshot and balanced profile. It has a twelve-hour TTL, costs $0.69/hr, and has 88% isolation.

Looking at these side-by-side reveals the underlying logic. Synthetic fixtures under team SSO get a 96% isolation score, while masked snapshots drop to 88%. Costs scale based on the number of services and the resource profile. Interestingly, shared-stage data starts at a 48% base isolation score, and using a public link instead of SSO knocks off another 22 points. This is a great talking point when stakeholders ask for a "simple link" to send to clients without realizing the isolation trade-off.

Testing the failure drills

If you enable "Practice a failure," the simulator picks a specific repair scenario based on which PR you select. For example, choosing PR 184 triggers a branch override failure. It's a good way to visualize where the pipeline actually breaks in a real-world GitOps flow.