Put your app on your own site, or your own computer

You made an app on Vibes DIY. Now it can live where your people already are. Paste one line into your own web page and the app shows up there. Or run one command and the whole app runs on your laptop, a Raspberry Pi in the closet, or the server your club already pays for.

One line on your own page

Your blog, your shop site, your garden club's page: any page that lets you paste a bit of HTML can carry your app. Open your published app, choose Share in the vibe menu, press Embed, then Copy script tag. You get one line:

html<script src="https://vibes.diy/vibe/your-handle/your-app/anywhere.js" async></script>

Paste it where you want the app to appear. That's it. The app grows with its content, so the page around it never shows a little scrolling box.

Here is one, placed on this page by that same line:

Three small options cover most pages. Add data-height="480" for a fixed height, data-mount="#my-spot" to place the app inside an element you already have, or data-title="Our garden" to name it for screen readers. The line points back at vibes.diy, so your page always gets the newest way of showing your app. The sharing docs have the full set, including a plain <iframe> for pages that take no scripts.

One command on your own machine

The second way takes the whole app home. With Node installed, sign in once, then run your app:

shnpx vibes-diy login
npx vibes-diy run your-handle/your-app

It pulls your published app into a folder and starts it. It prints an address to share and a private owner link for you. Open the owner link once and you use the app as its owner. Everyone else who opens the address is a visitor, with exactly what your app's access rules give a signed-out visitor on vibes.diy.

Everything the app keeps lives in that folder: a sqlite database, the pictures people upload, and the keys the run made for itself. Stop it, start it again, and every document is still there. The run starts with a fresh database of its own, so it is a clean home for the app.

To keep it up for good, put it behind a reverse proxy with wildcard DNS, tell it its public address, and run it under systemd like any other service:

shnpx vibes-diy run your-handle/your-app --dir /srv/my-app \
  --state-dir /var/lib/my-app --base-url https://vibes.example.com

AI features in your app use the model service you choose: set LLM_BACKEND_URL to an OpenRouter-style chat completions address (for example https://openrouter.ai/api/v1/chat/completions) and LLM_BACKEND_KEY to its key before you start. Making and changing the app stays on vibes.diy, where the builder lives. Change it there, pull the new version, and restart.

The CLI docs walk through every flag.

Your backend comes along

Some apps carry a backend.js: routes under /_api/ that talk to other services or keep server-side logic. Those come with you. A run answers your app's /_api/ routes from your own machine, and what they write lands in the same folder as everything else.

The backend runs in workerd, Cloudflare's own runtime and the same engine it runs on at vibes.diy. vibes-diy brings it along as an optional package. So a route that works on vibes.diy works the same way on your Pi, down to who may write what. workerd needs a 64-bit system, so on a Pi that means 64-bit Raspberry Pi OS; on a 32-bit one the page, data and access rules still run.

Under run, backend.js answers requests today. Its timed and on-change handlers are the next piece we're bringing over, along with the live notification bell.

The same code, in a new place

A run is not a second copy of the platform. It hosts the same server code that vibes.diy runs, in one Node process with a sqlite file where the cloud has Postgres. So an access rule means exactly the same thing on your laptop as it does on vibes.diy, and an app behaves the same in both homes.

That also gives AI agents a real app server on localhost. An agent working on an app can run it, write to it and read the result on its own machine, with the same rules the published app follows.