What Happens to Preview Environment Data After You Merge?

Every team that adopts per-pull-request environments eventually asks a version of the same question, usually right after their first real merge: where did all that test data just go? It's a fair thing to wonder. A preview can accumulate real activity fast: seeded fixtures, a manually clicked-through checkout flow, a QA reviewer's throwaway account. None of it should still exist an hour after merge, and in a well-run setup, none of it does.

The Short Answer

Nothing persists. When a pull request merges or is closed, its preview environment and any database it provisioned get deleted, not archived and not migrated anywhere. The commit that ships is the code. The data that lived inside the preview while the PR was open never travels with it, because the two were never the same thing to begin with.

That distinction is worth sitting with. A preview environment's database is a byproduct of testing that one PR, not a draft of production. It exists so a reviewer or an automated test can click through a real, running application without touching anyone else's data. Once the PR merges, the code that mattered goes out through the normal deploy pipeline. The preview's database already did its job, and it has nothing further to contribute once that job is done.

The Preview Environment Data Lifecycle

Every preview moves through the same four stages, whether it's backed by a fresh seed, a branched copy, or one of the safer production-shaped patterns teams reach for when they need more realism than a static fixture, a pattern covered in more depth in ephemeral, per-PR environments with tests built in.

What Should Persist After a Merge? (Nothing, by Default)

By default, nothing should carry over, and that's a deliberate property of the design, not a gap in it. Preview data is throwaway on purpose: a seeded fixture set, a synthetic dataset, or a masked or branched copy of production, built to make the preview behave realistically for the duration of one PR. None of those is the source of truth. Production is.

Promoting preview data would invert that relationship. A database mutated by whatever a reviewer clicked, whatever a flaky test half-completed, or whatever a manual QA pass left in a weird state has no business becoming part of production's history. The PR's actual output, the thing that's supposed to persist, is the code diff that got reviewed and merged. The data was only ever there to prove that diff worked. This is really the same underlying question the wider preview environment data isolation discussion covers: isolation matters not just while a PR is open, but at the moment it closes, when the boundary either holds and the preview disappears cleanly, or it doesn't and something lingers that shouldn't.

How Autonoma Turns Teardown Into a Guarantee, Not an Assumption

The gap that causes most of the failure modes below isn't a missing policy. Almost every team already intends to delete preview data after merge. The gap is that intention isn't automation, and automation that only sometimes runs is functionally the same as not having it: the PRs that get closed instead of merged, the branch someone abandoned mid-review, the environment a script was supposed to clean up but silently didn't.

We built our platform around treating teardown as a guarantee tied to the pull request's own lifecycle, not a separate job someone has to remember to trust. At Autonoma, PreviewKit is our managed preview-environments product: it provisions, routes, and tears down full-stack, isolated per-PR previews, including their database isolation. Autonoma's integrated web E2E testing runs against those previews, with Planner setting up database state and Diffs Agent keeping the relevant tests aligned as the PR changes.

A merge promotes the reviewed code, not the temporary database state that made the review possible.

If the default is deletion, the natural follow-up is whether deletion itself is ever the risky move, and is it safe to delete preview environment data is worth reading on its own: the short version is that the risk almost always runs the other way, toward keeping preview data around longer than it needs to exist, not toward tearing it down too soon.

Failure Modes: Orphaned Preview Data

None of this is theoretical when teardown isn't reliable. An environment that outlives its PR doesn't just sit there harmlessly. It keeps its database running, which is a cost line that never stops accruing for work that finished weeks ago. It keeps whatever credentials and secrets it was issued live and reachable, on infrastructure nobody is actively watching anymore.

If that environment was seeded from a cloned production snapshot, the exposure gets worse: real or near-real customer data can sit behind a low-trust preview URL long after the reason for provisioning it disappeared. Multiply one forgotten environment across a team that ships dozens of PRs a week and you get branch sprawl, a growing set of half-abandoned environments that expand your attack surface without adding any value, each one a small, unmonitored copy of your stack that a leaky link or a stale credential could turn into an actual incident.

The Quotable Version

Preview environment data after a merge is gone, and it's supposed to be. A pull request's environment and its database exist to prove the code works, not to become a draft of production. When the PR merges or closes, that data is torn down along with it: nothing promoted, nothing archived, nothing left running that someone has to remember to clean up later. The teams that get burned aren't the ones who deleted preview data too aggressively. They're the ones whose teardown quietly stopped happening at all. PreviewKit, Autonoma's managed preview-environments product, makes that lifecycle part of the per-PR environment: it provisions the isolated stack, runs integrated web E2E tests against it, and tears it down when the PR merges or closes.

FAQ