Export v0 code: getting your project out of v0 and running it yourself

Symptom

Both are normal. v0 is built around a connected Vercel project and, optionally, a GitHub repository. The code moves through GitHub; the keys stay in Vercel.

Why it happens

The export route is GitHub

v0's FAQ answers "Can I edit the generated code?" with export to work locally or edit in v0, and points to the GitHub integration as the way to keep both in sync. In the current docs, the Code tab offers Copy file contents and Download file for the open file, which is fine for one component, not a whole app. For a full project, GitHub is the route the docs describe.

There is also a ZIP route for developers: v0's Platform API has a Download Chat Files endpoint, GET /v2/chats/{chatId}/files/download, that returns a chat's source as a ZIP. It needs a v0 API key, so it suits automation more than a one-off export.

Keys never leave Vercel

v0's docs say environment variables are inherited from the connected Vercel project, and integrations such as Supabase, Neon or Stripe add their variables there automatically. None of that is in the repository, which is correct: secrets should not be. A fresh clone therefore has no .env.local.

Some services assume Vercel

v0's docs say it is pre-configured to use Vercel AI Gateway, with no extra setup, and Vercel's docs say deployed code on Vercel that uses the AI SDK authenticates with the project's OIDC token when AI_GATEWAY_API_KEY is not set. Off Vercel there is no such token. The same applies to anything provisioned through the Marketplace: it works anywhere, but only once you copy its keys.

The fix

1. Connect GitHub. In v0, open Project menu then Settings then GitHub and select Connect. Choose the owner under Git Scope, enter a Repository Name and select Create Repository. v0 creates a private repository and pushes the current code. v0's docs warn that once connected, the repository becomes the source of truth, and if you delete it the code may become unrecoverable. Treat it accordingly.

2. Clone it and install with the right package manager. The lockfile tells you which one v0 used; its sandbox has pnpm, npm, yarn and bun available.

git clone git@github.com:your-org/your-v0-app.git
cd your-v0-app
 
# use the manager that matches the lockfile in the repo
ls pnpm-lock.yaml package-lock.json yarn.lock bun.lock* 2>/dev/null
pnpm install

3. Pull the variables from Vercel. Link the folder to the same Vercel project v0 created, then pull the Development environment into .env.local:

npx vercel link          # choose the existing project v0 created
npx vercel env pull      # writes Development variables to .env.local
pnpm dev

Vercel's docs note that Secret variables cannot be read back, so vercel env pull writes a placeholder for any Secret with no local value. Fill those in by hand from the provider's dashboard. If you would rather not write secrets to disk, vercel env run -- next dev runs the dev server with the variables in memory.

4. Check .gitignore before your first commit. Make sure .env*.local and .vercel are ignored. Then search the history for anything that looks like a key, because a prototype sometimes picks up a pasted secret along the way:

git grep -nE "sk_(test|live)_|-----BEGIN|SUPABASE_SERVICE_ROLE" -- . ':!*.md'

5. Replace Vercel-only pieces if you host elsewhere. List what the code reads from process.env and where each value came from:

// scripts/list-env.ts: run with `npx tsx scripts/list-env.ts`
import { execSync } from "node:child_process";
 
const out = execSync(`git grep -hoE "process\\.env\\.[A-Z0-9_]+" -- "*.ts" "*.tsx"`).toString();
const names = [...new Set(out.trim().split("\n").map((l) => l.replace("process.env.", "")))].sort();
console.log(names.join("\n"));

For AI features, create an AI Gateway API key and set AI_GATEWAY_API_KEY on the new host, or switch to a provider SDK with its own key. For databases, copy the connection string from the provider. Then deploy and test every integration once.

How to prevent it

• Connect GitHub early, before the project is worth losing. Every chat change then lands on a branch with a pull request and a preview.
• Keep v0 and your local copy in step. v0 never pushes directly to the base branch; merge its pull requests, then use Pull Changes in the branch menu to bring your own commits back into the chat. v0's FAQ suggests the same pattern for working with someone in Cursor or Claude Code: share the repository, push and pull.
• Commit a list of variable names, without values, in your README so the next person knows what to set.
• Decide hosting before you rewrite anything. If you stay on Vercel, nothing about the export forces a migration.
• Know the way back in. v0's FAQ says you can import an existing project from a GitHub repository, a Vercel project or a ZIP file, using the + icon in the prompt bar. Importing from GitHub starts a chat on the branch you pick and does not duplicate a repository you can write to, so you can hand a cleaned-up codebase back to v0 for UI work later.

My general guide to exporting AI-built code compares this with Lovable and Bolt. If the goal is simply to get live, deploying a v0 app to production may be all you need, and handing over AI-generated code covers what a developer needs from you. The prototype to product guide puts it all in order.

When to get help

Exporting is usually the moment people realise the prototype needs work before real users arrive. Run the free vibe code health check on the exported repository to see where it stands. If it needs auth, data and payments made solid, the Rescue Sprint takes it to production, whether it's live yet or not.