VibeHost vs Netlify: giving a reviewer access to a private preview

Netlify is the competitor whose default matches VibeHost's. On a recent Netlify team a new project starts private, and previews stay private with it. The difference shows up one step later, when you have to let a specific person in.

Netlify admits that person by signing them in. VibeHost can admit them without an account. Which one you want depends on whether the reviewer is on your team.

What Netlify documents about project visibility

From Netlify's project visibility documentation (last updated 19 August 2026):

"Project visibility controls who can reach your deployed project. A project can be public (anyone with the URL can view it), private (only your team and people you invite can view it), or password protected (public, but requires a shared password to view)."

The default is the part Netlify does better than the rest of the field:

"On Credit-based plans, new projects start private by default when this setting is enabled for your team."

"Previews stay private unless you change the preview visibility setting."

That default turns on by team age, not by plan:

"Teams created on or after July 28, 2026 start with this default setting: Private for new projects. Teams created before then keep this default setting: Public."

The admission rule is a login:

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

And who you can invite is plan-bound:

"This feature is available on Credit-based Free, Personal, and Pro plans only. On a Free and Personal plan, private projects can only be seen by the Team Owner. On Pro plans, you can add unlimited team members to your project or team to view a project."

"On Free and Personal plans, projects are single-seat. To invite others, upgrade to Pro."

So on Free, private works and the audience is one person: you. A visitor who is not in is told to ask:

"Users without access see a Netlify-branded page explaining they don't have access and prompting them to ask the owner for access."

Two limits on the feature are documented on the same page. It does not exist on every plan family:

"Enterprise, Open Source, and Legacy (non-Credit-based) plans don't have project visibility settings."

And private closes an inbound door:

"Third-party webhooks. A private project cannot receive webhooks from services like Slack or Stripe. Receiving third-party webhooks requires the project to be public."

What Netlify documents about preview URLs and passwords

Outside the credit-based visibility model, a preview URL is a link anyone can open unless you protect it. From Netlify's deploy overview (last updated 26 August 2026):

"Preview URLs for Deploy Previews or Branch deploys can be shared with anyone with the link, unless you set up the following:"

The two things it then lists are password protection and team login protection. The same page separates being unindexed from being unreachable:

"Requests to Deploy Previews, unpublished production deploys, and old branch deploys will have an X-Robots-Tag: noindex header included in the response."

That keeps a preview out of search results. It does not stop a person who has the URL.

The shared password is included further down the ladder than on most platforms. From Netlify's password protection documentation (last updated 28 July 2026):

"Basic password protection for your entire site is available on all Pro plans."

Netlify is explicit that the password and the private setting are alternatives rather than layers:

"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."

And about what a shared password buys you:

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

The login-based gate excludes one role by design:

"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."

What Netlify documents about deploying without git

Netlify has more no-git paths than most. From Netlify's create deploys documentation (last updated 28 July 2026):

"You can create a new site by dragging a project folder containing your site files (like .html files) to Netlify Drop."

"You can also use the CLI to create manual deploys without continuous deployment. For example, you can deploy directly to your production site from the command line with netlify deploy --prod."

"You can use the API to create deploys manually using a file digest or a ZIP file."

A manual deploy skips the build:

"When you create a deploy manually without continuous deployment, Netlify does not run a build command."

The default carries over to those paths too:

"On Credit-based plans, if your team has private by default enabled, new projects start private no matter how you create them."

There is even an anonymous path, with an hour on the clock:

"To deploy without logging in or creating a Netlify account, use netlify deploy --allow-anonymous. This creates a temporary project with a live URL that you can claim within one hour."

Previews, though, come from git or from Netlify's own agents. From Netlify's Deploy Previews documentation:

"By default, Netlify automatically builds Deploy Previews when you do one of the following:"

The two triggers it lists are an agent run that changes a file and a pull or merge request in a connected repository. On deploy sizing, Netlify's deploy overview documents one ceiling worth knowing:

"While Netlify doesn't have a limit on the number of files per deploy, we do have a limit of 54,000 files per directory."

Netlify's bandwidth and credit allowances are not stated on the documentation pages read for this comparison, so the rows below say so rather than guessing.

How VibeHost admits a reviewer

Access lives on the app and is evaluated at the edge on every request. A newly created app starts private. Visibility is one of public, workspace, or private, and a private app admits a visitor by exactly one of three paths.

Share link. A minted URL whose holder needs no account and never signs in. The plaintext token is returned once at creation; the server stores a hash and a short display prefix. Optional expiry up to a 90-day ceiling, or none. The visitor's browser carries a signed cookie for 24 hours, and the gate re-reads the link's revocation state from the database on every request — so revoking a link stops that visitor's next page load rather than waiting for a cookie to expire. Share links covers the mechanics.

Email or team grant. One address gets viewer, deployer, or admin on one app. The grant is matched against the email on the account with no workspace-membership condition, so a client with read access on one app is not a workspace member and does not count toward the member cap. If the address is not registered yet, the grant waits and takes effect the first time that person signs in.

Workspace visibility. Setting an app to workspace admits any signed-in member of the owning workspace. This is the one path that does require membership.

Password protection composes with the three above rather than being a fourth entrance, which is the opposite of Netlify's arrangement. On Netlify a password replaces the login gate; on VibeHost it is an extra condition on top of one. A signed-in visitor with no grant who knows the password clears the prompt and then gets a 403 page offering to request access. Password protection is a Business feature, and Free has no shared-password option at all.

There is no repository and no build. You point the CLI at a directory that contains index.html; it packs a .tar.gz and POSTs it, and the server validates the archive, deduplicates blobs against what it already holds, and assembles a release. Previews are named channels — production, pr-42, dark-mode — and the server holds no git knowledge, so a preview appears because you deployed to a channel. Concepts covers the model, and pull request previews shows the channel-per-pull-request workflow when your CI does the pushing.

Side-by-side comparison

VibeHost plan-dependent figures appear inline below so the rows read side by side. The authoritative per-plan table is on the limits page, generated from the same object the API enforces.

Plan numbers

Over the storage cap, deploys return 402 — free up space or upgrade. Usage-based overage billing is not live yet, so going over is never a charge today. Bandwidth is metered and shown on the usage card, but nothing is blocked when you go over it.

Business is priced per workspace, not per member and not per app. Adding the fourth person to a workspace is what moves you off Free, and after that the member count does not change the bill.

When to pick Netlify

Pick Netlify when the site needs more than static files. Functions, edge functions, and a build system that handles most frameworks are all there, and VibeHost has none of them.

Pick Netlify when the release process should be git-driven and previews should track pull requests. Netlify builds a Deploy Preview per pull or merge request without you wiring anything up. VibeHost has no equivalent.

Pick Netlify when you want a shared password one tier down. It is included on Pro rather than sold as an add-on, and on VibeHost it is a Business feature.

Pick Netlify when every reviewer is already on your team and you are on Pro. Unlimited members with project-scoped access is the right shape for that, and adding a second system on top would be worse.

Pick Netlify when the project has to receive third-party webhooks and stay restricted. Netlify documents that combination as unavailable, which at least tells you where the wall is; VibeHost has no build hooks to receive in the first place.

When to pick VibeHost

Pick VibeHost when the reviewer is outside your team and should not have to create an account. A share link asks the holder for nothing, and revoking it stops their next request. Netlify's private mode is a login by definition.

Pick VibeHost when you need more than one named viewer without upgrading. Netlify's own docs put a Free private project at Team-Owner-only and call projects single-seat until Pro. On VibeHost an email grant is per app, carries a role, and is not workspace membership.

Pick VibeHost when a password should narrow access rather than replace it. On Netlify a private project does not take a password, and a password-protected project is public plus a prompt. On VibeHost the two compose, so a leaked password still does not open a private app.

Pick VibeHost when there is no repository. The artifact is the unit of deploy and the server holds no git state. Ten coding agents and CLIs, two chat clients over MCP, and five AI canvas surfaces through a Chrome extension are documented paths to the same API, and none of them needs a git remote.

What VibeHost does not do

No functions, no edge functions, no builds. npm run build runs on your machine or your agent's; the server validates, deduplicates, and assembles.

Static only. The static runtime is the only generally available one; a server-rendered runtime for Next.js apps with API routes and middleware is in private beta. No databases, no cron, no workers.

No git integration at all. No repo linking, no push-to-deploy, no automatic per-pull-request preview. Channels are the substitute and they are manual.

No custom domains and no password protection on Free. Free apps live on *.vibehost.space with a watermark on the link preview card.

Sources

Every Netlify quote on this page comes from Netlify's own documentation:

• Netlify — Project visibility
• Netlify — Password protection
• Netlify — Deploy overview
• Netlify — Create deploys
• Netlify — Deploy Previews

See also

• All six platforms compared — the same access questions across Vercel, Cloudflare Pages, Render, and GitHub Pages
• VibeHost vs Vercel — the platform that charges $150 per month for the password gate
• One-on-one comparisons: Cloudflare Pages, Render, GitHub Pages, Replit
• Concepts — workspaces, apps, channels, grants, and why the server holds no git state
• Share links — minting, expiry, and revocation
• Limits — per-plan caps, generated from what the API enforces
• Move from Netlify to VibeHost — _redirects and _headers carry over