What types of projects does prev support?

prev supports self-contained web projects — static sites, React/Vue/Angular, Next.js, Node.js, Python, Go, PHP, Ruby, Rust, .NET, and Docker containerized applications that expose a single HTTP port.

How fast are preview deployments?

Most small previews are live within 15-30 seconds. The exact time depends on your project size, dependencies, and whether you're deploying from source or a Docker image.

Can I use my own domain?

Yes! Teams plans include custom domains, and Individual plans can add them as an add-on. Configure your wildcard domain in the dashboard, add a TXT record for verification, and your previews are available on your own domain. SSL certificates are automatically provisioned via Let's Encrypt.

All transfers are encrypted via TLS. Source uploads are used to build an isolated container image and are discarded after the build. Runnable images are removed when the preview is destroyed or expires. Teams plans include additional security features like IP allowlists and audit logs.

Can I integrate prev with my CI/CD pipeline?

Yes! The prev CLI works in any CI/CD system — GitHub Actions, GitLab CI, Jenkins, CircleCI, and more. Just install the CLI and run prev in your pipeline to get a preview URL for every build.

What happens when a preview expires?

When a preview reaches its TTL, it's automatically stopped and cleaned up. Audit logs keep the operational record for Teams accounts. You can also manually destroy previews at any time using prev destroy.

Could prev replace our staging or UAT infrastructure?

In many cases, yes. If your staging server exists primarily to let stakeholders review changes before production, prev can replace that workflow at a fraction of the cost. Great fit: frontend reviews, design sign-offs, client demos, QA testing of UI changes, PR previews in CI/CD. Not a fit: if your staging requires a shared database with production-like data, long-running background workers, or multi-service orchestration. prev is designed for self-contained, single-container applications.

What are the resource limits per preview?

Each preview runs in its own container with 256 MB RAM by default. Memory-heavier frameworks get more: 384 MB for Ruby and Next.js, 512 MB for .NET. Preview containers are ephemeral — there is no persistent container disk between deploys. You can pass environment variables at deploy time via prev create . --env KEY=VALUE or an .env file. Previews expose a single HTTP port (auto-detected or set with --port).

How is prev different from ngrok, Netlify, or Vercel?

ngrok creates tunnels to your local machine — your computer must stay on, and it exposes your local environment. prev deploys your code to cloud infrastructure independently. Netlify and Vercel are full hosting platforms designed for production deployments with git integration, serverless functions, and CDNs. prev is purpose-built for temporary preview environments: one CLI command, any project type, automatic cleanup. No git integration required, no vendor lock-in, and it works with Docker images too.

Stop Burning
$2,000/Month
On Always-On Staging.

Q: Do you offer multiple regions?

Region selection and multi-region previews are coming soon.

Prev gives every client, QA pass, sales demo, and stakeholder review its own temporary preview URL. No shared staging queue, no server maintenance, no deploy handoffs.

Start 7-Day Free Trial See the ROI

Built for agencies SaaS teams freelancers CTOs

Review command center Launch week website changes

3 live previews

01 Change ready

Homepage copy

02 Preview URL

acme-redesign.prev.sh

03 Approval

Client sign-off

Typical deploy <30s

Review queue None

Cleanup Automatic

Shareable preview https://acme-redesign.prev.sh

Client approvalsOne link per change. QA reviewsParallel environments. Sales demosStable demo URLs. Agency deliveryLess staging overhead. Launch reviewsFast sign-off links. Stakeholder updatesOne URL per audience.

The Hidden Cost

Staging is rarely just a server bill.

Always-on staging quietly turns into maintenance, interruptions, blocked approvals, and demos that overwrite each other.

Idle infrastructure

Permanent staging sits online even when nobody is reviewing anything.

Deploy interruptions

Engineers become the bottleneck whenever someone needs a demo pushed live.

Shared environment conflicts

QA, sales, founders, and clients all compete for the same staging slot.

Slow stakeholder feedback

Approvals stall when reviewers wait on staging access instead of opening a URL.

Use Cases

Give every review its own place to happen.

Agencies & freelancers

Client approval links that do not block the next project.

Send one URL per change request, keep revisions isolated, and avoid explaining staging windows to non-technical clients.

Design sign-off
Copy reviews
Client demos

CTOs & product leaders

Shorter feedback loops without building another platform.

Give teams a repeatable review workflow without asking engineering to maintain permanent staging infrastructure.

PR previews
QA passes
Stakeholder reviews

Founders & sales teams

Reliable demo URLs for prospects and internal reviews.

Keep demos independent from QA and production work, then let them expire when the conversation is over.

Sales demos
Investor updates
Launch reviews

ROI

If staging costs more attention than value, make it temporary.

Prev is built for the reviews that do not need a permanent environment: stakeholder approvals, client demos, QA checks, and quick launch validations.

Compare plans

Always-on staging host Replace or reduce

Manual deploy handoffs One review URL

Competing demos and QA Parallel previews

Typical small preview deploy Under 30 seconds

How It Works

From change to review URL, without another staging server.

Your team deploys a temporary preview, shares the link, and lets Prev handle HTTPS, isolation, TTL, and cleanup.

Create a preview

Deploy a self-contained web app from source or Docker.

Share the URL

Send the preview to clients, QA, sales, or internal stakeholders.

Let it expire

Previews shut down automatically after their TTL.

View Technical Details

Operational Guardrails

Enough control for serious review workflows.

TLS

Automatic HTTPS

Every prev.sh preview gets HTTPS automatically. Verified custom domains get certificates via Let's Encrypt.

TTL

Automatic cleanup

Previews expire in hours or days, so review environments do not become permanent infrastructure.

ACL

Access control

Password-protect previews or restrict access with IP allowlists on Teams plans.

LOG

Dashboard visibility

Track live previews, TTL, URLs, audit logs, and cleanup from the web dashboard.

Pricing

Start small. Scale when reviews get busy.

7-day free trial on all plans. Cancel anytime.

Individual

$19/mo

8 previews, 7 day TTL, password protection

Teams

$199/mo

20 previews, 14 day TTL, custom domains

Compare All Plans

FAQ

What decision makers usually ask first.

In many review workflows, yes. Prev is a strong fit when staging exists mainly for stakeholder review, QA validation, design sign-off, client demos, or PR previews. If your staging environment needs shared production-like data, long-running workers, or multi-service orchestration, a dedicated staging setup may still be the better fit.

Prev is built for teams and solo operators that regularly need temporary web previews: agencies, SaaS teams, founders, freelancers, CTOs, QA teams, and product teams that want review links without maintaining extra infrastructure.

Someone technical needs to create the preview, but reviewers do not. Stakeholders just open a URL. The technical details are documented on the How It Works page and in the docs.

Most small previews are live within 15-30 seconds. Larger projects may take longer depending on project size, dependencies, and whether the preview is deployed from source or a Docker image.