Preview environment
A preview environment is a temporary deployment of a single branch or pull request, created automatically when the change is pushed and destroyed when it is merged or closed. It gives reviewers, testers and stakeholders a live URL for exactly one change, isolated from every other change in flight, without waiting for a shared staging slot.
The longer version
The pipeline builds the branch, deploys it to its own address, usually a generated subdomain, and posts the link on the pull request. Each preview carries only the code of its branch plus whatever backing services the pipeline wires in: sometimes a fresh database seeded with fixtures, sometimes a shared one that every preview reads from. When the branch is updated, the preview is rebuilt; when it is merged, the preview is torn down. The environment exists for as long as the change is under review and no longer.
Staging is one shared rehearsal of what is about to ship, so it holds many merged changes at once and is meant to mirror production. A preview holds one unmerged change and mirrors production only as far as the pipeline bothers to. That difference sets what each proves. A preview answers whether this change looks and behaves as intended in isolation. Staging answers whether all of this release works together on production-shaped infrastructure. A preview pass does not replace a staging pass.
The failure in practice is trusting a preview for the wrong question. A preview whose latest build failed keeps serving the previous deployment, so the tester approves code that is not what merges. A preview wired to mock payment or email services passes flows that fail against the real provider. And a bug filed against a preview without the preview's address in the report sends the developer to staging, where the change does not exist yet.
In a team's flow, the preview is where design review, copy review and the first functional pass happen, before the change touches the shared environments. That lets several changes be reviewed in parallel instead of queueing for the one staging slot. The report a reviewer files from a preview has to name the URL and the commit it was built from, because the address will be gone once the change merges.
Common questions
What is the difference between a preview environment and staging?
Staging is a single shared environment holding everything merged and due to ship, built to resemble production. A preview environment is created per branch or pull request, holds one unmerged change, and is deleted when that change merges. Staging proves the release works together; a preview proves one change works on its own.
How long does a preview environment live?
A preview environment lives as long as its pull request stays open and is deleted when the request is merged or closed. Most pipelines also rebuild it on every push, so the address stays the same while the code behind it changes. Anything filed against it should record the commit it was built from.
What should a bug report from a preview environment include?
The preview's address and the commit it was built from, since both disappear when the pull request merges and the bug will otherwise be looked for on staging, where the change does not exist. Browser, viewport and steps matter as on any environment, and a note of which backing services the preview mocks saves the developer from chasing a payment or email failure that only exists in the preview.
Who uses a preview environment?
Everyone who has to approve a change before it merges: the reviewing developer, the designer checking the layout against the mock, the copywriter, the product manager and the tester running the first functional pass. Because each preview belongs to one change, several people can review different changes at the same time without waiting for a slot on staging.
Can a preview environment use production data?
A preview environment should run on seeded fixtures or an anonymised copy, never on live customer data. Previews are created for every branch, live at addresses posted on pull requests and shared in chat, and are torn down without anyone auditing them, so a real customer record on one is a leak waiting to happen. Fixtures also make the same scenario reproducible on every preview.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.