VibeHost vs Render: hosting a static front-end without a git repo

You have a built front-end sitting in a folder. Render wants to know which repository and which branch. If there is no repository, that is the first question you cannot answer.

Render is a full application platform where static sites are one service type. VibeHost hosts static artifacts and nothing else. The comparison is really about what each one assumes you already have.

What Render documents about static sites

From Render's static sites documentation:

"Host your website's frontend (React, Next.js, etc.) over a global CDN."

The deploy trigger is a git push:

"After you link your site's Git repo, Render automatically updates your site with every push to your specified branch."

Render builds for you:

"We build your site with every push to your deployed branch"

And on cost:

"Static sites are fast and free to deploy."

The same page qualifies that free with a shared meter:

"Static sites count against your workspace's monthly included amounts of outbound bandwidth and pipeline minutes."

Custom domains come out of a plan allowance:

"Your workspace includes an amount of custom domains based on its plan"

The page lists 2 included domains on Hobby, 15 on Pro, and 25 on Scale, and then:

"Each custom domain you add beyond this amount costs $0.25 per month."

What Render documents about previews

From Render's pull request previews documentation:

"For Git-backed services, Render can create a service preview for pull requests opened against your linked branch."

Each one is a separate instance:

"For each service preview, Render creates a separate, temporary instance of your service with its own onrender.com URL."

Previews are kept out of search results:

"Render automatically sets the HTTP response header X-Robots-Tag: noindex for all preview instances."

And they are billed like the service they mirror:

"PR Previews are billed at the same rate as your base service. They are always prorated by the second."

"If your base service is a free static site, its PR previews are also free."

Two things follow. A preview exists because a pull request exists — the feature is scoped to "Git-backed services" with a "linked branch". And noindex keeps a preview out of Google, which is a different thing from keeping a person out of the preview.

How VibeHost deploys and gates

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. VibeHost's own architecture documentation puts the end-to-end at roughly three to eight seconds from tarball POST to a healthy URL.

Previews are named channels, not branches: production, pr-42, dark-mode. The server holds no git knowledge, so a preview appears because you deployed to a channel — not because a branch or a pull request appeared somewhere else. Concepts covers the model, and pull request previews shows the channel-per-pull-request workflow when your CI does the pushing.

Access is stored on the app and 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 of 1 to 90 days, 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 the next page load, not the next cookie expiry.

Email or team grant. One address gets viewer, deployer, or admin on one app. An email grant is matched against the account's email with no workspace-membership condition, so a client with read access on one app is not a workspace member and does not change the bill.

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

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

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 people to a workspace does not change the bill.

When to pick Render

Pick Render when the front-end is one part of a larger system. If the same product also needs a web service, a Postgres database, a background worker, or a cron job, running the static site next to them on one platform is the right call. VibeHost hosts none of those.

Pick Render when the workflow already lives in git and you want the platform to build. Link the repo, push, and Render builds and ships. There is no equivalent on VibeHost, by design.

Pick Render when previews should track pull requests one-to-one. A separate temporary instance per pull request is a real thing Render does and VibeHost does not.

Pick Render when you need custom domains on a cheap tier. Two are included on Hobby, and extras are $0.25 per month. VibeHost includes zero on Free.

When to pick VibeHost

Pick VibeHost when there is no repository. The artifact is the unit of deploy. 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.

Pick VibeHost when the preview must be private rather than merely unindexed. noindex keeps a preview out of search results; it does not stop a person with the URL. A VibeHost app starts private and stays that way until you change it.

Pick VibeHost when an external reviewer should not have to create an account. A share link asks the holder for nothing, and revoking it stops their next request.

Pick VibeHost when you are running many small sites. Free carries 100 apps; Business is unlimited and priced per workspace rather than per project.

What VibeHost does not do

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

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 long-running processes.

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 Render quote on this page comes from Render's own documentation:

• Render — Static sites
• Render — Pull request previews

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
• Pull request previews — how to get a URL per pull request without platform git integration
• Share private deploys — the private-app-plus-share-link pattern end to end