What is the easiest way to share an app I built with AI?

Package it into a single .vibeapp file with Vibe and send it. The recipient opens it like a document on macOS 14+ and it runs in a sandboxed VM — no GitHub, Docker, Node, Python, or cloud account required.

How is a .vibeapp different from sharing a GitHub repo?

A GitHub repo requires the recipient to clone it, install the right runtimes and dependencies, and start the services themselves. A .vibeapp bundles everything — code, services, and runtime — into one signed file that just opens and runs.

Can I share an AI-built app without deploying it to the cloud?

Yes. Cloud hosting (Vercel, Railway, Render, Fly) needs an account, always-on infrastructure, and ongoing cost, and it isn't something you can hand to someone. A .vibeapp runs locally on the recipient's Mac, sandboxed, with no hosting bill.

How to share a vibe-coded app

"Vibe-coded" apps are usually more than a single HTML file: a web server, a database, maybe a worker — several services that have to start together. That makes them awkward to share. Below is how the common approaches compare for the person on the receiving end.

What the recipient does	Vibe (.vibeapp)	GitHub repo	Cloud deploy	Static HTML
Install dev tools (Docker/Node/Python)	None	Required	Required to deploy	None
Clone / build / configure	No — just open the file	Clone, install, run	Set up hosting + env	Open in browser
Backend, database & state	Yes, included	Yes, if they set it up	Yes	No backend at all
Runs sandboxed / safe to open	Isolated VM, signed	Runs on host	On the server	Browser sandbox
Ongoing cost	Free, local	Free	Hosting bill	Free

Option 1 — Send a GitHub repo

The default for developers, but it pushes all the work onto the recipient: clone the repo, install the right Node or Python version, run npm install or pip install, stand up a database, and read the README to figure out the start command. Great for collaborators, painful for "just take a look at this."

Option 2 — Ask them to set up Docker locally

Shipping a docker-compose.yml is more reproducible, but the recipient still needs Docker Desktop installed and running, and has to trust and execute containers directly on their machine.

Option 3 — Deploy to a cloud provider

Vercel, Railway, Render, or Fly will host it — but that means an account, a deploy pipeline, always-on infrastructure, and a recurring bill. It's how you publish a product, not how you hand a build to a friend, a client, or a teammate for a quick look. See Vibe vs cloud hosting.

Option 4 — Share static HTML

If the app is front-end only, a static file works. The moment it needs a server, a database, or persistent state, static HTML can't carry it.

Option 5 — Send a .vibeapp file

With Vibe you package the whole app — services, runtime, and all — into one signed .vibeapp file. The recipient double-clicks it on macOS 14+; the Vibe player verifies the Ed25519 signature and runs everything inside an isolated Alpine Linux VM. No GitHub, no Docker, no Node, no cloud account. State auto-saves every 30 seconds, and you can optionally encrypt the package with a password before sharing.

If you use an AI coding tool, you don't even package it by hand: install the hooks once and say /vibe it. Compare it directly with sharing a GitHub repo →