VibeHost vs Cloudflare Pages: restricting a preview URL

You opened a pull request and Cloudflare Pages handed you a preview URL. You paste it into a channel. Then you notice nothing stopped a stranger from opening it either.

Both platforms will give you a URL per change. They differ on what that URL admits by default and what it takes to change that.

What Cloudflare documents about preview access

Cloudflare states the default plainly. From Cloudflare's preview deployments documentation:

"By default, these deployment URLs are public."

The same page describes both the default and the remedy:

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

And names the mechanism:

"You can use Cloudflare Access to manage access to your deployment previews."

The trigger for a preview is a git event. From the same page:

"Every time you open a new pull request on your GitHub repository, Cloudflare Pages will create a unique preview URL."

"Each new branch you create will receive a new, randomly-generated hash in front of your pages.dev subdomain."

Cloudflare Pages does support a non-git path. Cloudflare's Pages overview documents both connecting a Git provider and a Direct Upload path for prebuilt assets, so a repository is not strictly required to deploy — only to get the automatic per-branch and per-pull-request previews.

Cloudflare's documented limits

From Cloudflare Pages limits:

"Cloudflare Pages sites can contain up to 20,000 files on the Free plan."

"Paid plans (such as Pro, Business, and Enterprise plans) can have up to 100,000 files per site."

"The maximum file size for a single Cloudflare Pages site asset is 25 MiB."

"Builds will timeout after 20 minutes."

The same page lists 500 builds per month and one concurrent build on the Free plan, rising to 5 concurrent builds on Pro and 20 on Business, and 100 custom domains per project on Free. It also caps the routing files:

"A _headers file can have a maximum of 100 header rules."

"A _redirects file can have a maximum of 2,000 static redirects and 100 dynamic redirects, for a combined total of 2,100 redirects."

That 100-custom-domain free allowance is genuinely more generous than VibeHost's, which is zero on Free and 20 on Business. Worth saying out loud before the rest of this page.

How VibeHost gates a deploy

VibeHost stores a visibility value on the app and evaluates it at the edge on every request. A newly created app starts private. The three values are public, workspace, and private.

A private app admits a visitor by exactly one of three paths:

Share link. A minted URL whose holder needs no account and does not sign in. The plaintext token is returned once at creation; the server keeps a hash and a short display prefix. Optional expiry between 1 and 90 days, or no expiry. The visitor's browser holds a signed cookie for 24 hours, and the gate re-reads the link's revocation state from the database on every request, so revoking applies to the visitor's next page load rather than whenever a cookie happens to expire.

Email or team grant. One email address gets viewer, deployer, or admin on one app. The email grant is matched against the account's email with no workspace-membership condition, so granting a reviewer read access does not add them to the workspace. A grant against an unregistered address waits and activates on that person's first sign-in.

Workspace visibility. workspace admits any signed-in member of the owning workspace.

Password protection is a Business feature and a separate composing gate, not a fourth entrance. Clearing the password does not by itself grant read on a non-public app: a signed-in visitor with no grant who knows the password clears the prompt and then lands on a 403 page offering to request access.

Previews are named channels rather than git branches — production, pr-42, dark-mode — and the server holds no git knowledge. A preview exists because you deployed to a channel, not because a branch or pull request appeared. The model is laid out in concepts, and the gate itself in grants and visibility and share links.

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 per workspace. Members do not carry a seat price, which is why granting a reviewer access to one app has no billing consequence.

When to pick Cloudflare Pages

Pick Cloudflare Pages when the site is public and traffic is the main concern. The edge is the product, the free file allowance is large, and 100 custom domains per project on the free plan is not something VibeHost matches.

Pick it when your team already runs Cloudflare Access. If every reviewer is already in your Zero Trust policies, using the identity system you already operate beats introducing a second one.

Pick it when you want the build to start from your repository. Cloudflare builds from a git push. VibeHost builds too — nextjs and node apps compile server-side in a sandboxed Builder Job — but it builds what you upload, so a repository is never the trigger. A static app has no build step on either side of the wire.

Pick it when the workflow genuinely is git-shaped. If previews should appear because a pull request appeared, the automatic per-pull-request URL is the thing you want.

When to pick VibeHost

Pick VibeHost when a preview must not be publicly reachable the moment it exists. private is the created state, not a setting to remember.

Pick VibeHost when the reviewer must not need an account. Cloudflare's documented answer to a restricted preview is to require the visitor to authenticate. A VibeHost share link asks the holder for nothing, and revokes on the next request.

Pick VibeHost when the deploy comes from an agent rather than a git event. 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 repository.

Pick VibeHost when access needs to be per app and per person rather than per policy. An email grant on one app is one row, and removing it is one command.

What VibeHost does not do

Zero custom domains on Free. Cloudflare's free allowance here is far larger. Free VibeHost apps live on *.vibehost.space and carry a watermark on the link preview card.

No password protection on Free. Visibility, grants, and share links work there; the shared-password gate is Business only.

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. There are no functions, no cron, and no long-running processes.

No builds. npm run build runs on your machine or your agent's. The server validates, deduplicates blobs, and assembles the release.

Sources

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

• Cloudflare Pages — Preview deployments
• Cloudflare Pages — Pages overview
• Cloudflare Pages — Limits

See also

• All six platforms compared — the same access questions across five other hosts
• Concepts — workspaces, apps, channels, grants, and why the server holds no git state
• Limits — per-plan caps, generated from what the API enforces
• Share private deploys — the private-app-plus-share-link pattern end to end
• Pull request previews — the channel-per-pull-request workflow when your CI does the pushing