"Do we still need staging?" is the wrong first question. The better question is: which workflows are blocked because staging is shared?

Preview environments and staging solve different problems. Staging is a durable place for release validation. Preview environments are disposable places for review. When teams confuse those jobs, staging becomes overloaded and reviews slow down.

The Short Version

  • Staging is for validating a release candidate or a shared integration state.
  • Preview environments are for reviewing one branch, one pull request, or one client-facing change at a time.

If a workflow needs to be stable for days, touched by many services, or seeded with production-like data, staging may still be the right place. If a workflow needs a link for a specific change and should disappear after review, it belongs in a preview.

What Changes for Developers

Developers stop treating deploys like a scarce resource.

With shared staging, deploying is a social action. You ask whether someone is using it. You warn the team before overwriting it. You clean up state that another branch left behind. With previews, deploying is part of the review itself. 

prev create . --subdomain pr-184-checkout --ttl 3d

The developer gets a URL for that change and can hand it to QA, product, sales, or the client without touching anyone else's environment.

What Changes for Reviewers

Reviewers stop asking "what am I looking at?"

A staging URL often hides context. Is this the newest commit? Did another branch deploy after the link was shared? Is the database state from the current test or last week's demo?

A preview URL carries intent. It points to a specific branch or review. The reviewer can open it, leave feedback, and come back later without worrying that the next deploy changed the subject.

What Changes for Staging

Staging gets smaller and more useful.

Instead of being the dumping ground for every unfinished branch, staging can focus on work that actually needs a durable shared environment:

  • Release candidate validation
  • Cross-service integration testing
  • Production-like data rehearsals
  • Long-running QA plans

That makes staging less noisy. It also makes staging more trustworthy, because fewer temporary review branches are constantly mutating it.

What Changes for Clients

Clients get a URL that matches the thing they are supposed to review.

That sounds small, but it changes the tone of the entire review. Instead of sending screenshots, Loom videos, or a shared staging link with caveats, you send one preview URL. The client can open it on their own machine, share it internally, and approve the exact version you shipped for review.

For agencies, that is the difference between "please imagine the final thing" and "click here, this is the thing."

What prev Is Good At

prev is built for self-contained web apps that serve HTTP. It works well when you need a temporary, isolated environment for:

  • Pull request reviews
  • Client demos
  • QA passes
  • Design and product review
  • Short-lived branch testing

Attach managed databases when a preview needs its own data store. Use TTLs so old work disappears automatically. Add password protection or IP allowlists when the preview should not be public.

Where Previews Are Not Enough

Preview environments are not a magic replacement for every system.

If your review depends on a large multi-service architecture, shared service discovery, long-running background jobs, or a production-like data set that cannot be copied safely, keep staging in the workflow. The goal is not to delete staging. The goal is to stop using staging for work that should be temporary.

How to Start

Start with one project and one workflow: pull request review. 

curl -fsSL https://prev.sh/install.sh | sh
cd your-project
prev create . --ttl 3d

Once the manual flow works, move it into CI/CD so every pull request gets a preview automatically. Then keep staging for the release checks that actually need staging.

Start a 7-day trial and see what changes when every review gets its own URL.