v0 does not produce one universal file format.
Depending on the project, it may create React components, a Next.js application, TypeScript, Tailwind CSS, shadcn/ui components, API routes, or a simpler HTML-based interface. You can edit the generated code, connect GitHub, upload or import projects, and publish directly to Vercel.
So “export from v0” is not a complete technical requirement.
The useful question is:
What did v0 generate, and what must remain available when the project is public?
The shortest path: publish from v0
v0 has a direct publication workflow connected to Vercel.
For a project designed around v0 and Vercel, this is usually the default:
- Open the project or chat.
- Use the Publish action.
- Publish to production.
- Use the generated Vercel URL.
- Add a custom domain through the project settings when needed.
- Publish later changes deliberately.
This path is especially suitable when the project uses:
- Next.js server features;
- API routes;
- environment variables;
- databases;
- authentication;
- server-side integrations;
- Vercel-specific services.
Moving such a project to a static-only workflow would remove capabilities it depends on.
What code export means
v0 lets you work with the generated code outside the chat. Current v0 documentation describes several routes:
- edit code directly in v0;
- export code for local work;
- use bidirectional GitHub integration;
- import an existing GitHub repository or ZIP;
- publish through Vercel.
The exported result is source code, not necessarily a finished static bundle.
That distinction matters.
Source code
Source code may require:
npm install
npm run build
It may also require:
- environment variables;
- a Node.js runtime;
- framework configuration;
- server functions;
- external services.
Static output
A static output contains files a browser can load directly:
- HTML;
- CSS;
- client-side JavaScript;
- images;
- fonts;
- other public assets.
It does not require a server process for application logic after publication.
How to inspect a v0 project
Start with four places.
1. package.json
Look at:
- scripts;
- dependencies;
- framework version;
- build command.
Common signals such as next, react, and typescript tell you that the project is a codebase, not a single HTML document.
2. The application folders
Depending on the project, inspect folders such as:
app/
pages/
components/
public/
Look for API routes, server actions, middleware, or database code.
3. Environment variables
Search for:
process.env
NEXT_PUBLIC_
Values prefixed for browser access are visible to visitors after they are included in client-side code. Private credentials must remain server-side.
4. Network behavior
Use the browser developer tools and check what the page calls:
- internal API routes;
- Supabase;
- database services;
- analytics;
- image providers;
- third-party forms;
- AI model APIs.
A page can look static while depending on remote runtime behavior.
Three practical output categories
Category A: UI component
The output is a section or component intended to be added to another product.
Examples:
- pricing table;
- dashboard card;
- navigation;
- checkout layout;
- form component.
Best next step: integrate it into the existing codebase.
Category B: full application
The output has application routing, authentication, server logic, or data.
Best next step: keep it in the v0/Vercel workflow or move it into a conventional development workflow.
Category C: static landing page
The output is a marketing page that can operate with HTML, CSS, browser JavaScript, public assets, and a form endpoint.
Best next step: use a static publication workflow such as Deplion when you want AI-controlled updates, project versions, rollback, domains, and lead collection.
Preparing a v0 landing page for static publication
Do this only for Category C.
Step 1: Ask v0 to remove runtime dependencies
Example prompt:
Convert this project into a static landing page.
Keep the current design, responsive behavior, and copy.
Use only HTML, CSS, browser JavaScript, and public assets.
Remove API routes, server actions, authentication, and database dependencies.
Do not expose any private keys.
Preserve the contact form fields.
This prompt changes the architecture. Review the result carefully.
Step 2: Build and test it locally
Use the scripts defined by the project rather than assuming a command.
Typical projects may use:
npm install
npm run build
Then inspect the generated output directory.
Open the result through a local web server and test:
- direct page loads;
- internal navigation;
- asset paths;
- mobile layout;
- client-side interactions;
- forms;
- 404 behavior.
Step 3: Decide how the form will work
A static page cannot safely contain private email credentials or database passwords.
Use a dedicated form-processing service. Deplion includes lead collection for published projects, allowing the page to submit an enquiry without adding a private application backend.
The form should still provide:
- labels;
- validation;
- loading state;
- success state;
- error state;
- spam-resistant behavior.
Step 4: Publish through an MCP assistant
Connect an MCP-compatible assistant to:
https://deplion.cc/mcp/deplion
Then provide the reviewed files and a bounded instruction:
Create a new Deplion project from this static v0 export.
Verify asset paths and the contact form.
Publish the project and return the review URL.
Step 5: Connect the final domain after review
Do not combine code conversion, first publication, form setup, and DNS changes into one unverified step.
A safer order is:
- publish to the project URL;
- test;
- correct issues;
- publish the approved version;
- attach the custom domain.
v0/Vercel versus Deplion
| Requirement | v0 + Vercel | Static export + Deplion |
|---|---|---|
| Next.js server features | Strong fit | Not applicable |
| API routes and private runtime logic | Strong fit | Not applicable |
| Continue generation inside v0 | Native | v0 remains the authoring tool |
| Static campaign page | Supported | Focused use case |
| Lead inbox for the page | Requires chosen integration | Built into project workflow |
| AI maintenance through MCP | Depends on connected workflow | Core workflow |
| Snapshot versions and rollback | Deployment and Git options | Project version workflow |
| Multiple small client landing pages | Possible | Intended operating model |
Neither path is universally better. They solve different operating requirements.
Common export mistakes
Mistake 1: Treating source as a finished site
A repository can be complete source code and still require a build, runtime, environment variables, or external services.
Mistake 2: publishing secrets
Never place private keys in browser JavaScript or public files.
Mistake 3: losing image paths
Generated applications often rely on framework image handling. Static conversion can break paths or optimization behavior.
Mistake 4: assuming forms will continue to work
A form UI and a form-processing workflow are separate things.
Mistake 5: rebuilding instead of reverting
When an AI edit damages a working page, restore the previous known-good release first. Diagnose the change second.
A useful handoff prompt
When the project is ready to leave v0 as a static landing page:
Prepare a handoff package for this project.
Include:
1. the final static files;
2. a list of external dependencies;
3. all required public configuration;
4. confirmation that no private keys are included;
5. the expected form fields and success behavior;
6. the final page title and meta description;
7. a list of known limitations.
This makes the next step inspectable rather than implicit.
The main idea
v0 gives you code and a direct path to Vercel. In many cases, that is the correct production workflow.
Export becomes useful when you want to own or move the code. Before choosing where it goes, identify whether the result is a component, a full application, or a static landing page.
For a static landing page, Deplion adds a practical operating layer: MCP-based publication, domains, lead collection, versions, and rollback—while v0 remains the place where the design and code are created.