How to Export v0 Code to GitHub

If you built an app in v0 by Vercel and want the code in a GitHub repository you own, whether as a backup, to keep working on it in an editor, or to hand it to a developer, this is the guide. Git is optional in v0, and you connect it per project. Once it's connected, the repository becomes the source of truth for your code.

Before you start

• A GitHub account. It's free at github.com.
• A v0 project you can open and change.

Export your v0 project to GitHub

If anything about the connection needs fixing later, you can manage or repair it from the same place: Project menu ... → Settings → GitHub.

What changes after you export

GitHub becomes the source of truth. v0's docs are direct about this: once a repository is connected, it holds your project's code, and if you delete the repository the code may become unrecoverable. Don't delete it to start fresh.

v0 works on a branch, not on your main branch. When v0 has a code change to push, it creates a working branch from the chat's base branch (named something like v0/main-abc123) and commits every change there automatically. It doesn't push straight to the base branch. Each working branch gets its own Vercel preview deployment, so you can check the app before anything reaches production.

Publishing merges a pull request. When you select Publish, v0 creates a pull request for the working branch (or reuses the open one), merges it into the base branch and waits for the production deployment. v0 follows your repository's rules: required checks, required reviews and other branch protections can block the merge. When that happens, v0 keeps the pull request open and explains what needs attention. Sort it out, then select Publish again. After a publish, the same chat carries on, and the next change starts a new working branch.

Changes from elsewhere come in through Pull Changes. If you or a teammate merge work into the base branch from another editor, Pull Changes in the branch menu brings it into the chat's working branch. If there are conflicts, the branch menu offers Fix Conflicts.

Environment variables live on Vercel. v0 inherits environment variables from the connected Vercel project. You add or edit them under Project menu ... → Settings → Environment Variables, where v0's docs say they're encrypted and stored on Vercel. Integrations you add from v0 put their variables there automatically. One thing that trips people up: the v0 preview can only read variables from the Development environment, so a key that's only set for Production won't work in the preview.

Before you ship: what to check in the exported repo

With the code in front of you, go through these before launch. The examples assume a Next.js app.

1. No secrets behind NEXT_PUBLIC_. Next.js inlines any NEXT_PUBLIC_ variable into the JavaScript sent to the browser. Keys for Stripe, an AI provider or a Supabase service role must stay unprefixed and only be read on the server. See Secret API key exposed in client bundle.
2. No .env files committed. Next.js's own docs say you almost never want to commit .env files, and v0 already keeps your variables on Vercel. Check the repository for .env* files. If one held a real key, rotate the key first, then remove the file. More on why: secret exposure.
3. API routes check who's calling and what they sent. Every route that reads or writes user data should confirm the caller on the server and validate the request body. See Auth check only in client code and Missing input validation.
4. Database access is locked down. If your app uses Supabase, enable row level security with real policies on every table. See Missing row level security.
5. One error doesn't blank the whole page. Add error boundaries and handle failed requests with a clear message. See Missing error boundary.
6. Sign-in and AI endpoints are rate limited. See No rate limiting on sensitive endpoints.

For the bigger picture, v0 to Production: What Vercel's AI Misses covers what v0 does well and what it leaves for you.

Have FinishKit review it

Because v0 creates a private repository, start with the FinishKit GitHub App. When you install it, you choose which repositories it can access, so you can limit it to this one. FinishKit reviews the repo across eight production readiness dimensions and gives you a Finish Plan ranked by what blocks launch. For a public repo, the free quick readiness check is a fast first pass from the URL alone, with a short set of checks instead of the full review.

Sources: v0: GitHub, v0: External APIs, v0: Vercel integration, v0: FAQs, Next.js: Environment variables.