# Elements vs v0

v0 is an AI app builder made by Vercel, the cloud hosting company. You describe an app in a chat at v0.app, and [v0's agent](https://v0.app/docs/agentic-features) writes it, by default as a [Next.js app](https://v0.app/docs/full-stack-apps) built with React, Tailwind and shadcn/ui. The project runs in a [Vercel Sandbox](https://v0.app/docs/sandbox), a virtual machine in Vercel's cloud that serves the live preview, and the agent can search the web, run terminal commands and open the app in a browser to test it. Projects can sync with [GitHub](https://v0.app/docs/github), and designs can be imported from Figma. Databases, storage and AI services are added from the Vercel Marketplace, from providers such as Supabase, Neon and Upstash. Publishing [deploys the app to Vercel](https://v0.app/docs/deployments). A v0 account is a Vercel account: v0 charges credits for the agent's work, and the apps it builds run on Vercel's metered hosting.

With Elements you also get an app by asking an AI agent for it, but nothing in the loop belongs to a host. There is no sandbox: the project sits on your computer, and the agent is whichever one you already pay for. There is no marketplace: sign-in, background jobs, realtime and email come in the default framework, and Postgres comes in the box, along with a test runner and a package installer. And there is no default cloud: the deploy command goes over SSH to an Ubuntu server you rent from any provider. Elements is priced per machine, with no credits and no usage meter ([pricing](/pricing)).

The difference is where the work happens and who meters it. In v0, the project, the agent and the finished app all live on Vercel, and the agent's work, the hosting and each Marketplace service are billed separately. With Elements, the project lives on your computer, the agent is the one you choose, and sign-in, realtime and jobs are part of the framework, with their data in a Postgres database that ships with Elements. Your compiler and tests look at each change within moments of saving, and no credit is spent when they do. The finished app runs on a server you control, at your server provider's price.

| | Elements | v0 |
|---|---|---|
| Where you build | Your computer, in your editor | v0's chat, with the project in a Vercel Sandbox that runs for at most 24 hours at a time |
| The agent | Any agent, on your own account with its provider | v0's agent; a ChatGPT plan can cover some responses from OpenAI models |
| How the agent's work is checked | `elements build -json`, run locally after each edit, free | The agent runs commands, reads logs and opens the app in a browser, paid in v0 credits |
| When credits run out | Nothing pauses; Elements has no credits | Generation pauses |
| Where the backend comes from | Built in: database, sign-in and realtime, all in one Postgres database | Marketplace providers such as Supabase or Neon, on accounts of their own, billed on their own plans |
| Where the app runs | Your own server, from any provider that rents Ubuntu machines | Vercel |
| What is metered | Nothing | v0 credits, Vercel usage, and each provider's own plan |
| Price | One subscription, with licenses for your development and deploy machines | A v0 plan, a Vercel plan, and a plan per provider |

## Your Agent Hears About Its Mistakes in Milliseconds

v0's agent finds its mistakes by working in the sandbox: running commands, reading logs and opening the app in a browser, including the fixes it makes automatically as it generates. All of it is agent work paid in [credits](https://v0.app/docs/pricing), and "When credits are used up, generation pauses." When a deploy fails, **Fix with v0** sends the logs to the agent. Paid plans get a daily allowance of free fixes on unedited code, and after that, the [deployment guide](https://v0.app/docs/deployments) says, "fixes cost credits like a normal prompt."

Elements replaces that sandbox work with a build that is already warm. While you work, the project server holds the build graph and build state in memory, so on every save the build state is updated almost instantly: it builds in milliseconds and answers agents and humans in microseconds ([build](/learn/man/build)). Only what a change touches is redone. After each edit your agent runs:

```bash
elements build -json    # "ok", or every error, each with a file and line
```

The answer covers four kinds of mistake:

- **Type errors** in browser code and in server code, each checked against the types it actually has ([typescript](/learn/man/typescript)).
- **Regressions.** Your tests are a step of the build, so the build fails when a change breaks something that already worked ([tests](/learn/man/tests)).
- **Bad migrations.** Schema changes run against the development database as you write them, and a batch that fails rolls back, all of it ([migrations](/learn/man/migrations)).
- **Server-only calls in the browser.** `sql()`, `session.login()` and other server-only code, called from anything the browser loads, fail to compile at the offending line ([rpc](/learn/man/rpc)).

The agent fixes each error from its file and line and asks again, so those errors are fixed before a deploy is attempted. Where v0 opens the app in a sandbox browser, an Elements agent uses the browser already on your computer, taking a screenshot of a changed page in about a second and clicking through it the same way ([browser](/learn/man/browser)). There is no balance that pauses the work.

## Bring the Agent You Choose, on Your Own Account

In v0, the agent's work is billed through v0. A ChatGPT Plus or Pro subscriber can [connect that plan](https://v0.app/docs/chatgpt) so that "eligible AI responses" from supported OpenAI models count toward it, inside v0's agent; image work, delegated subagents and "additional supporting agent work" may still use v0 credits. The sandbox also runs Claude Code, routed through Vercel's AI Gateway, and "Agent requests routed through the Gateway consume your team's AI Gateway credits." Supplying "personal API keys to redirect requests away from the Gateway," or installing another agent, is an [unsupported configuration](https://v0.app/docs/pre-installed-agents).

With Elements, the agent runs on your computer, on your own account with any provider: Claude Code, Codex, Cursor or any agent that can run a command. Nothing sits between the agent and its provider, and Elements takes no share of its work.

An agent's output improves through correction, finding out what it broke as soon as it breaks it, far more than through the stack a platform wraps around it. v0's agent writes into Vercel's choices: Next.js, React, Tailwind, a shadcn/ui component library and Marketplace services, each an API it has to get right and a seam with the next. A library pays off only for what an agent cannot write quickly from standards, and that surface is small; given a choice, an agent writes a component in plain HTML and CSS faster than it adapts one from a kit. An Elements app is TypeScript, HTML, CSS and SQL and ships over SSH to Ubuntu, so any coding agent can start on day one. Its pages add a light reactive layer to standard HTML, called Elements HTML, documented in the manual the agent reads ([html](/learn/man/html)), and its server code is `sql()`, `session.login()` and functions marked `@rpc`. That is the plumbing; past it, Elements stops adding layers and spends its engineering on the check: one coherent system builds everything the agent writes and names each mistake in microseconds.

## Two Commands From Install to a Running App

An Elements project lives on your computer for as long as you work on it. Elements installs once, as one coherent system. `elements create myapp` then makes a project, and `elements start` serves it in your browser with a Postgres database already running on your computer ([getting started](/learn/man/start)). There is no database to provision from a marketplace, no provider terms to accept and no environment variables to copy. The project also comes ready for your agent.

v0's GitHub sync can bring a project to your computer too. What arrives is a Next.js project: it brings no project server, no bundled database, no test runner and no single command that reports failing tests, migration errors and every other build error together. Your agent is back to assembling and checking the stack itself.

## The Backend Is Part of the App, Not a Marketplace

A v0 app gets its backend from the [Vercel Marketplace](https://v0.app/docs/databases). v0's docs say "Adding an integration provisions a new user account on that service and adds the necessary environment variables to your project." An app that needs a database and a cache can end up with two new accounts, a Postgres from Neon or Supabase and a Redis from Upstash, each with its own terms, plan and bill.

In Elements these pieces come with the framework, and the same build checks them with the rest of the app:

- **Sign-in and sessions.** No auth provider account: a session is a row in your database that routes, server functions and pages all read the same way ([session](/learn/man/session), [authentication recipe](/learn/man/recipes/authentication)).
- **Database.** No Neon or Supabase signup: Elements installs Postgres on your computer and on the server you deploy to ([database](/learn/man/database)).
- **Server code.** In place of server actions, an `@rpc` function that pages call directly, with the build checking every call site ([rpc](/learn/man/rpc)).
- **Realtime.** No Redis: a LiveTable pushes row changes to every open browser from that same Postgres ([livetable](/learn/man/livetable), [channel](/learn/man/channel)).
- **Files.** A form's uploads come through as `File` objects, alongside its other fields. Store them in Postgres, as the recipe does, or in any object store ([file upload recipe](/learn/man/recipes/file-upload)).
- **Jobs.** No queue service either: background jobs and cron schedules wait in a table of that same Postgres ([jobs](/learn/man/jobs)).
- **Email.** Write messages in the HTML you already use for pages. Development mail goes to the project server log, so an email account can wait until production, where any SMTP provider does the sending ([email](/learn/man/email)).

Where a Marketplace app spreads its state across several providers, an Elements app keeps its data, sessions, LiveTable change feed and job queue in one standard Postgres, and they travel as a unit. To relocate them, export SQL with `elements db dump`, load it into any Postgres 16 or newer, and change `DB_HOST` ([database cli](/learn/man/database/cli), [setup](/learn/man/deploy/setup)).

## Pages Are Standard HTML, Fast Without Tuning

A v0 app is a Next.js app by default, built from React components that re-render as data changes. React's own docs give [`memo`](https://react.dev/reference/react/memo), `useMemo` and `useCallback` for skipping re-renders that slow a page.

Elements pages are written in Elements HTML: standard HTML with a few added attributes such as `e:if` and `e:for`, and `{}` expressions for values that change ([html](/learn/man/html)). The server renders each page with its data, and the browser then updates only the parts that change, with no `memo`, `useMemo` or `useCallback` to write. Elements also ships a design system, `@elements/style`, with design tokens, self-styling HTML elements, component classes, utilities and dark mode, and a new app is already wired to it, so a new page starts styled ([style](/learn/man/style), [install](/learn/man/style/install)). Elements is not React compatible by design, because standard HTML is what agents already know. The [Next.js comparison](/vs/nextjs) goes further.

## The App Runs on a Server You Control

A v0 app runs on Vercel, and its environment variables are [managed in the connected Vercel project](https://v0.app/docs/vercel-integration). With Elements, configuration is a file in the project that your agent can read and change ([config](/learn/man/config)), and the server's log is a file it can read on the machine ([operations](/learn/man/deploy/operations)).

The server can be any Ubuntu machine with SSH, a small VPS included ([deploy](/learn/man/deploy), [DigitalOcean pricing](https://www.digitalocean.com/pricing/droplets)). Elements prepares it on the first deploy, installing the bundled Postgres, the built-in load balancer and HTTPS certificates from Let's Encrypt, and setting the app to start whenever the machine does. A prototype or a one-server app can stay on that Postgres. Spread across several servers, or wanting backups and scaling run by a provider, the app can use a hosted Postgres such as Amazon RDS or DigitalOcean Managed PostgreSQL through `DB_HOST` ([setup](/learn/man/deploy/setup)). Later deploys send only the changed files, and most land in under a second. Your tests decide whether a release goes live: they run on every machine, pending migrations run once on the first, and any failure leaves the running app in place ([what deploy does](/learn/man/deploy/what-happens)).

## If Your Laptop Is Up, Elements Is Up

v0 builds in a hosted sandbox and assembles the backend from other companies: "Adding an integration provisions a new user account on that service" ([databases](https://v0.app/docs/databases)). Each of those services is one more account, one more bill and one more status page your app depends on. v0's own [status page](https://v0-status.com) lists incidents such as "GitHub integration degraded" and "Upstream Provider issue causing partial outage in v0."

With Elements, the tooling is on your computer and the app is on your server, with its database, sign-in and realtime sharing one Postgres. No marketplace provider's incident can halt your work. If your laptop is up, Elements is up.

## One Price, Known Up Front

v0 is paid for in [credits](https://v0.app/docs/pricing) from a monthly plan. Running the app is a second bill, from Vercel, whose paid plans charge per team member plus [metered usage](https://vercel.com/pricing) for compute, requests and data transfer ([Elements vs Vercel](/vs/vercel)). Each Marketplace provider bills on its own plan on top of both.

Elements is a single subscription ([pricing](/pricing)), licensing both the machine you develop on and the one you deploy to ([purchase](/learn/man/purchase), [licenses](/learn/man/licenses)). Nothing is metered: requests, realtime messages, bandwidth and agent work never appear on the Elements bill. Hosting becomes the monthly price of a VPS, and the agent keeps running on your existing plan. Because `@elements/app` and its sibling runtime packages are under the MIT license, the code you ship is yours outright. That code is TypeScript, HTML, CSS and SQL on standard Node.js and Postgres, so any agent can read it, change it, or port it.

## Questions

### Is Elements a v0 alternative?

Yes. As in v0, you ask an AI agent for the app. Here the agent is your own, the project is on your computer, and the Elements build checks each change within moments of saving. Sign-in, the database, realtime and jobs are built in, and the app deploys to a server you control instead of Vercel.

### Can I move my v0 app to Elements?

Yes. Use v0's GitHub sync to get the code onto your computer, then ask your agent to rebuild the app in Elements, reading the Next.js code as its spec. React components become Elements HTML templates, server actions become `@rpc` functions, API routes become routes in `index.ts`, and `elements build -json` checks every step of the port.

### Can I use Claude Code or my ChatGPT plan with Elements?

Yes. Claude Code, Codex (which runs on a ChatGPT plan), Cursor and any agent that can run a command work with Elements, on your computer and on your own account with the agent's provider, with nothing routed in between. Each new project comes ready for the agent.

### Do I need Vercel, Neon or Supabase with Elements?

No. Elements brings its own Postgres, sign-in, realtime, background jobs and file uploads, and deploys the app over SSH to an Ubuntu server you choose instead of Vercel. If you want a managed Postgres anyway, set `DB_HOST` to its address.

### Does Elements use React or Next.js?

No. Elements pages are written in Elements HTML: standard HTML with a few added attributes for loops, conditions and values that change. Pages render on the server with their data and update in the browser with no re-render tuning, and any agent learns the additions from the manual.