Bring an Existing App

Pick the vibe type

Type	Files	Good for
Static site	index.html plus CSS, scripts and images; no worker	A page or small site
Worker only	A root worker.js or worker.ts; no page	Data your AI reads and writes through MCP tools, with nothing for people to open
Worker + page	The worker plus index.html	The same, with a simple page to see and edit the records
Vue + worker	A Vue and Vite frontend (built to dist/) plus worker.ts	A full web app with a build step

What moves over well, and what doesn't

Static files move over as they are. A backend moves over if it fits in one root worker file. The worker can use npm packages that run on Cloudflare Workers, meaning plain JavaScript modules built on web APIs (for example nanoid, zod or a date library): list them in package.json with a lockfile. Node-only code doesn't run: fs, child_process, net, native add-ons, and server frameworks such as Express, Django or a Next.js server. Watch for node: imports, because they can build successfully and then be undefined at runtime. Keep the logic, and let your coding agent rewrite the handlers as worker functions.

Keep server code in the worker file. A vibe without a dist/ build serves its files as they are, and that includes any local modules your worker imports (import './lib/helper.js') and any data or config files in the folder, such as a JSON file the worker reads: anyone who can open the vibe could fetch them. Only the root worker file is kept private today. Until that changes, keep server-only code in the root worker file, or build your frontend to dist/ so only dist/ is served.

Steps

1. Register it. In your project folder, run vibe init my-app with no template. It creates the vibe, writes .vibe-coded.json, and adds .vibe-coded/ and .dev.vars to .gitignore; your other files are untouched.
2. Shape the backend (skip for a static site). One root file, worker.js or worker.ts, exporting { async fetch(request, env) }. It routes POST /api/<name> to your functions and returns { success: true, data } or { success: false, error }.
3. Swap the storage. Use env.VIBE_STORAGE (key-value, every plan), env.VIBE_D1 (SQL, Pro or Pro+) or env.VIBE_R2 (files, Pro or Pro+). Secrets you set with vibe secrets arrive as env.NAME.
4. Expose functions to your AI. Annotate each one your AI should call. The platform turns every annotated async function into an MCP tool when it builds:

   /**
    * @mcp-expose
    * @description Log a run against a pair of shoes
    * @param {string} shoe - Shoe name, or part of it
    * @param {number} miles - Distance in miles
    */
   async function log_run(shoe, miles, env) {
     // ...your existing logic, using env.VIBE_STORAGE
     return { success: true, data: { shoe, miles } };
   }

   Use snake_case names, keep env as the last parameter, and route /api/log_run to the function.
5. Move the old server files out. Once the worker does the job, move files it no longer needs out of the vibe folder: the old server (server.js, framework config), modules the worker doesn't import, and seed or data files you've imported. A vibe without a dist/ build serves every file in its folder.
6. Check it, then ship it. vibe dev runs it locally. vibe preview builds it and reports the tool count. vibe call log_run '{"shoe":"pegasus","miles":5}' tries a tool. vibe publish makes it live, and vibe connect adds it to Claude Code.

Or ask your agent

With the skill installed, your coding agent knows these rules. Open the project and say what you want, for example: “Adapt this project for vibe-coded.ai and expose adding, listing and updating orders as MCP tools.” Then check its work with vibe call.

More detail: Anatomy of a Vibe for the file layout, and the CLI guide for every command.