Where to host a vibe-coded app when you just want the link

The tool wrote the whole thing and now it wants a deploy pipeline. If the app is one self-contained file, paste it here and skip that part.

Paste your app

One self-contained HTML file. The preview runs it before you publish.

Paste your HTML or Markdownor drop a file hereSupports .md and .html, up to 50 MB · 1 MB on Free
Visibility

Vibe coding produces working software from a conversation, and then hands you a hosting problem nobody in the conversation mentioned. The usual advice — a Git repo, a build command, environment variables, a platform account — is written for an application you intend to run for years. A lot of what actually comes out of these sessions is not that. It is one HTML file with the CSS and JavaScript inlined: a calculator, a dashboard over some numbers you pasted in, a scheduling grid, a prototype you want three colleagues to click before you decide whether it is worth building properly. For that, the deploy pipeline is the expensive part of the project. Paste the file here and you get a URL immediately, with no repo, no build step, and nothing left running that you have to remember to shut down.

Publishing a vibe-coded page

  1. 1.

    Ask the tool for a single self-contained HTML file, with the CSS and JavaScript inlined.

  2. 2.

    Copy the whole document, from the opening doctype to the closing tag, and paste it above.

  3. 3.

    Check the preview — it runs the real page, so the interactive parts either work here or they do not.

  4. 4.

    Publish, and send the link. Nothing is installed and nothing keeps running afterwards.

A real example

Say you spent an evening with an agent building an internal tool that takes a pasted CSV of support tickets and draws a chart of response times by weekday, with a dropdown to filter by team. It runs perfectly in the preview pane. You want your team lead to try it before standup. The honest options are: push it to a repo and wire up a static host, which is twenty minutes and an account they may not have; send them the .html file, which most mail clients will strip and which will not open on a phone; or screenshot it, which loses the dropdown. Instead, copy the file from the opening doctype to the closing tag, paste it above, and publish. The chart draws and the dropdown filters, because a published page runs its own JavaScript in a sandboxed frame rather than being flattened into static markup. Your lead opens it on a phone on the way in. The part that will not survive the trip is anything that reached a service through a key the agent had locally — a database call, a private API. Self-contained travels; anything that phones home with your credentials does not, and should not.

Questions about host a vibe coded app

Is this a replacement for Vercel or Netlify?

No, and it is worth being clear about which problem you have. Those platforms are the right answer for an app you are going to keep: a repo, a build, a framework, a custom domain, previews per branch. This is the right answer when the artefact is one file and the goal is for a specific person to look at it today. Plenty of work is genuinely the second kind, and treating it like the first is how a five-minute task becomes an afternoon.

My agent split the app into separate HTML, CSS and JavaScript files.

Ask it to inline them — "put the CSS and JS into the HTML file so it works as a single file" is a request every current coding model handles in one pass. A single-file build is also what makes the result portable in general: it opens from a local disk, attaches to a message, and publishes here without a build step.

Will the interactive parts actually run, or do I get a screenshot?

They run. Published HTML executes its own scripts, so charts draw, inputs accept typing, filters filter, and canvas animates. The page is served from its own isolated origin rather than inside the app, which is what makes running author-written JavaScript safe to allow. Browser storage works too, so a page that remembers a setting between visits keeps doing that.

What about the database my app talks to?

A published page has no server and no secrets, so anything requiring a private key will not work, and you should not want it to — a key shipped in a page a stranger can open is a key you have given away. Pages that read from a service with public, row-restricted credentials do work; several people run exactly that against their own backend. If the app needs privileged data, it has outgrown this and wants a real deploy.

How long does the link last?

A free page stays live for seven days (3 days if published as private), which suits the review-it- before-standup case this page is about. If it turns out to be something you keep sending, a paid plan makes it permanent and lets you republish at the same URL, so the link you already gave people keeps working when the app changes.

Keep your links forever

Free public pages initially last 7 days; private pages last 3 days. Paid plans support permanent links; trial expiry rules differ.

See pricing

Related use cases