Does a reviewer need an account to open a private preview?

You have a preview that should not be public, and one person who needs to look at it — a client, a designer, a stakeholder, someone outside your team. The question that decides everything is whether they have to create an account on your hosting platform to see it.

On most platforms the answer is yes, because privacy is implemented as authentication: the site is private because the viewer must sign in. That is a reasonable design, and it is the wrong shape when the reviewer is not a developer and will never come back.

Here is what each platform documents, quoted, with the date the page was last updated.

The short answer per platform

What each one says

Vercel

Protection is on by default for new projects, on all plans (changelog, 2 November 2023):

"Deployment Protection with Vercel Authentication is now enabled by default."

And Vercel Authentication "[restricts] access to only Vercel users with suitable access rights" (Deployment Protection, last updated 28 August 2026).

For someone outside your team, Vercel's sharing guide (28 August 2026) states the split directly:

"The collaborator does not need to have a Vercel account, but will need to create one if they wish to view a deployment that is protected, use the toolbar, or leave comments."

There is a bypass — a shareable link — but it is rationed. From Vercel's shareable links documentation (28 August 2026):

"Developers on the hobby plan can only create one shareable link in total per account."

Not one per project. One per account. Invites are capped the same way: "Hobby users are limited to one collaborator at any one time."

Netlify

One sentence, from Netlify's project visibility documentation (last updated 19 August 2026):

"Private projects are enforced with Netlify login: only your team and people you invite can view a private project."

Netlify's shared-password option is an alternative rather than a way around the login, and it is one secret for everyone. From Netlify's password protection documentation (28 July 2026):

"If your project is set to private, it already requires users to sign in with their Netlify credentials, so you do not need to configure a password."

"Anyone can use your basic password to access a site deploy"

Worth knowing if you use team login protection: it excludes one role outright.

"Team login protection applies to Developers, Team Owners, and Billing Admins only. Git Contributors will not be able to log in to your site deploys that are protected with team login protection."

Cloudflare Pages

Previews start public, and the documented way to close them requires the visitor to authenticate:

"By default, preview deployments are enabled and available publicly. In your project's settings, you can require visitors to authenticate to view preview deployment."

That authentication is Cloudflare Access, so the reviewer needs an identity your Zero Trust policy recognises.

GitHub Pages

Two separate requirements, both from GitHub's documentation on changing site visibility:

"To publish a GitHub Pages site privately, your organization must use GitHub Enterprise Cloud."

"A privately published site can only be accessed by people with read access to the repository the site is published from."

So the reviewer needs a GitHub account and repository access, and the org needs an Enterprise Cloud plan before the option exists.

What VibeHost does instead

Apps are private when created. To let one person in, you mint a share link, and that link is the credential — there is no account to create, no seat to buy, and no repository to be added to.

vibehost app share-link create --app client-pitch \
  --label "Acme Q2 review" \
  --expires-in 14d

The recipient opens the URL and is in. Each link is separately labelled, separately expiring and separately revocable, so cutting off one reviewer does not disturb anyone else.

Share links are one of four access mechanisms, and they do not bypass everything — a password gate still applies if you set one. The composition rules, the visibility enum and the grant roles are documented in full on Grants and visibility; the link mechanics, expiry syntax and revocation are on Share links. This page does not restate them.

Choosing between the two shapes

Account-based privacy is the better fit when your reviewers are engineers who already have accounts on the platform, when you want a per-person audit trail of who opened what, or when access should follow an identity provider you already run.

A capability link is the better fit when the reviewer is a client or a stakeholder who should not have to create a developer account to look at a page, when you are sending the same build to several parties and want to revoke them independently, or when you want the preview private from the moment it exists without paying for a protection tier.

If you need the audit trail, VibeHost also supports per-email grants — those do require the viewer to sign in, deliberately, because that is what produces the trail. Both shapes are available; they answer different questions.

Related

• Grants and visibility — the four mechanisms and how they compose
• Share links — minting, expiry, revocation, and what a link does not bypass
• Share a preview with a client — the per-recipient pattern end to end
• Vercel vs Netlify — the same question, between the two incumbents