VibeHost vs GitHub Pages: hosting a static site that is not public

You pushed a static site to a GitHub repo, turned on Pages, and got a URL. Then someone asked whether the client can see it and nobody else. That is where the two platforms stop looking alike.

GitHub Pages decides access from the repository. VibeHost decides access per app, with three separate mechanisms you can combine. Which one fits depends less on the site and more on who has to open the link.

What GitHub Pages says about visibility

GitHub documents private Pages as an organization-plan feature, not a per-site toggle.

From GitHub's documentation on changing the visibility of your GitHub Pages site:

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

The same page describes who a private site admits:

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

And which repositories qualify at all:

"Access control is available for project sites that are published from a private or internal repository that are owned by the organization."

Two consequences follow from those three sentences. A site published from a public repository has no private option. And a viewer who should see the site needs read access to the repository behind it, which means a GitHub account inside your organization.

The limits page adds a constraint that catches commercial work. From GitHub Pages limits:

"GitHub Pages is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS)."

The same page states the size and traffic ceilings:

"Published GitHub Pages sites may be no larger than 1 GB."

"GitHub Pages sites have a soft bandwidth limit of 100 GB per month."

"GitHub Pages sites have a soft limit of 10 builds per hour."

How VibeHost decides who can open an app

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

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

A share link. You mint a URL, send it, and the recipient opens the app with no account and no sign-in. The token is returned once at creation and the server keeps only a hash. You can attach a label, an expiry between one and ninety days, or no expiry. Revoking it takes effect on the visitor's next request, because the gate re-reads the link's revocation state from the database rather than trusting the cookie it already issued.

An email or team grant. You grant one email address viewer, deployer, or admin on one app. The grant is checked against the email on the account, not against workspace membership, so granting a contractor read access does not add them to your workspace. If the email 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 workspace that owns it. This is the path that does require membership.

Password protection is a separate gate that composes with the three above, not a fourth way in. A signed-in visitor with no grant who knows the password still does not get through: they clear the password prompt and then land on a 403 page with a button to request access. Password protection is on the Business plan only.

The mechanics of each path are 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 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.

Where GitHub Pages is the better answer

Pick GitHub Pages when the site is meant to be public, the source already lives in a GitHub repo, and the audience is the open internet: project documentation, an open-source landing page, a personal site. The build runs on GitHub, the deploy is a push, and there is nothing to set up.

Pick GitHub Pages also when your organization is already on Enterprise Cloud and every viewer is already an organization member. In that case repository read access is the access control you want, and adding a second system on top would be worse.

Where VibeHost is the better answer

Pick VibeHost when the viewer is outside your organization and should not need to create an account: a client reviewing a landing page, a designer checking a mockup, a stakeholder looking at one build before a launch. That is what share links are for.

Pick VibeHost when the site should be private on a free plan. private is the default visibility, and it does not depend on plan tier.

Pick VibeHost when the deploy comes out of an agent rather than a git push. The server has no git knowledge at all: the unit of deploy is a tarball, and previews are named channels (production, pr-42, dark-mode) rather than branches. 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.

Pick VibeHost when the work is commercial. GitHub's own limits page rules that out for the free Pages tier.

What VibeHost does not do

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. If you need server-side cron, a long-running stateful backend, or arbitrary worker processes, this is not the platform.

Password protection is a Business feature. On Free you have visibility, grants, and share links, but no shared password.

Custom domains are zero on Free. Free apps live on *.vibehost.space and carry a watermark on the link preview card.

Sources

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

• GitHub Pages — Changing the visibility of your GitHub Pages site
• GitHub Pages — GitHub Pages limits

See also

• All six platforms compared — the same access questions across VibeHost, Vercel, Netlify, Cloudflare Pages, Render, and GitHub Pages
• 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
• Migration walkthroughs for the platforms that have one: Netlify, Replit, Weebly, and Vercel, whose full walkthrough is still being written and currently points at the Netlify steps