Open-source alternatives to Vercel v0: 4 AI application builder tools compared
Moving application generation off Vercel v0 means running the model calls and the preview yourself, and the same open-source list answers the same question for Lovable and Bolt.new. Only dyad-sh/dyad generates an application from a prompt on your own machine; the other three are environments or an editor rather than a builder.
What Vercel v0 does, and why people look elsewhere
Vercel v0 is a hosted tool that writes a working web application from a prompt or a screenshot: it generates the project files and hosts a preview you can share.
- the generated project and its preview run on the vendor's infrastructure
- the editor is a web application, so the project you keep is a copy held by the vendor
- export produces source files rather than the hosted preview, so the settings around the deployment do not travel with the code
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| dyad-sh/dyad | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 22, 2026 | TypeScript | 22,044 | See analysis |
| coder/coder | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last dayLast push October 23, 2026 | Go | 17,156 | See analysis |
| codesandbox/codesandbox-client | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 22, 2026 | JavaScript | 13,653 | Command documented |
| gitpod-io/gitpod | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last six monthsLast push October 21, 2026 | TypeScript | 13,806 | Command documented |
Each alternative in detail
dyad-sh/dyadLocal, open-source AI app builder for power users ✨ v0 / Lovable / Replit / Bolt alternative 🌟 Star if you like it!
- Best for
- A developer who wants the Vercel v0 loop, a prompt in and a working application out, without the project and its preview sitting on a vendor's servers, and who is willing to supply their own model keys.
- What you give up
- It is a desktop application, so it does nothing for a team that needs a shared generation service with accounts, permissions and a hosted preview. The split licence is the real condition: everything outside src/pro is Apache 2.0, while the pro folder is fair-source under the Functional Source License, so which features you get depends on where they live and the terms of that folder have to be read before you ship them.
coder/coderSecure environments for developers and their agents. Coder Agents runs a native AI coding agent whose loop executes in the control plane on your infrastructure, with no API keys in workspaces.
- Best for
- A platform team that wants to run coding agents on infrastructure it controls, with Terraform-defined workspaces, no model credentials inside the workspace, and an audit trail of which user did what.
- What you give up
- It is not an application builder: nothing in it turns a prompt into a project, so it changes where the generated code runs rather than where it comes from. It also expects a real operations team, because a production deployment wants PostgreSQL, an external access URL and WireGuard tunnels, and the templates that describe your infrastructure live in a separate registry.
codesandbox/codesandbox-clientAn online IDE for rapid web development
- Best for
- A team that wants to embed the browser IDE, or reuse the bundler that runs inside the browser, inside its own product, and is willing to take on a JavaScript monorepo.
- What you give up
- This repository is the client, not the service: the Phoenix API server, the Nginx configuration and the Git extractor are separate repositories, so there is no way to run a complete CodeSandbox from this one. The licence is unsettled too, because package.json declares GPL-3.0 while GitHub reports the licence file as unclassifiable, and the postinstall chain pulls build steps you need to read before running it.
- First install step
- Full setup guide
yarn install
gitpod-io/gitpodThe developer platform for on-demand cloud development environments to create software faster and more securely.
- Best for
- An organisation that standardised on the .gitpod.yml workflow and still wants to run the AGPL-3.0 codebase itself, against its own Kubernetes cluster and its own workspace images.
- What you give up
- The README no longer recommends this version for new users and records that the hosted offering for it was retired on October 15, 2025, so adopting it means adopting a codebase whose successor is elsewhere. The install path under install/ has to be checked against your Kubernetes target, the workspace images your definitions refer to live in a separate repository, and the package.json split mixes AGPL-3.0 with a package whose licence is unclassified.
- First install step
- Full setup guide
yarn build
One builder and three environments: what each project really is
Four projects, four different jobs, and only one of them does what Vercel v0 does.
dyad-sh/dyad is the builder. It is a desktop application that writes a working web application from a prompt, using your own model keys, on your own machine. The output is a directory of project files you own and can open in any editor. That is the same loop as Vercel v0, with the preview moved from a hosted URL to a local server you start.
coder/coder is not a builder at all. It is a self-hosted platform for cloud development environments and for AI agents that work inside them. Workspaces are described in Terraform through templates for EC2 machines, Kubernetes pods or Docker containers, reached over a WireGuard tunnel and shut down when nobody is using them. Its agent feature is the part that matters on this page: the agent loop runs in the control plane on your infrastructure rather than inside the workspace, so model credentials never sit in the environment a developer is working in, and every action carries the user's identity.
gitpod-io/gitpod is the older generation of that idea: a .gitpod.yml file describing an on-demand, pre-configured environment, built from a Docker image you choose.
codesandbox/codesandbox-client is neither. It is the source of a browser IDE: a Lerna and Yarn workspaces monorepo that builds the web application, the bundler that runs inside the browser, and an embeddable editor.
Where the preview goes when you leave Vercel v0
Vercel v0 does two things that are easy to take for granted: it writes the project files, and it hosts a preview you can send to someone. Export gives you the source and leaves the deployment settings behind, which is one reason people start looking elsewhere.
dyad-sh/dyad keeps the first half of that loop and hands the second one back to you. The application runs on your machine and you decide where to put it. There is no hosted preview to share from inside the tool, so sharing means deploying the files somewhere yourself, which is one more thing to own and also the whole point of the exercise.
coder/coder and gitpod-io/gitpod generate nothing, so they do not replace the generation step. They answer the other half: where the generated application is built, run and reviewed, and who may work on it. For a team that has already settled on a builder, they are the second part of a two-part answer.
codesandbox/codesandbox-client sits in a third place. The hosted service behind it offers a browser IDE that can be shared as a link, and this repository is the front end of that service. The server half lives elsewhere, in a Phoenix API server, an Nginx configuration and a Git extractor, each in its own repository, so a team that wants the hosted feel has to assemble it from parts.
The candidates that are not on the list deserve a sentence. Lovable and Bolt.new answer the same search with the same shape of product, and the same open-source projects cover them, which is why this page answers for those names as well. The other hosted builders have no repository a reader can install, so there is nothing to point at, and the desktop-only builders that write an application and hand you a folder cannot be self-hosted at all, which makes them a different category from everything here.
What each one costs to run
dyad-sh/dyad has the smallest running cost of the four and the largest one-off. It is a downloadable application for Mac or Windows with no sign-up, so there is no server, no database and no queue to run. What it needs instead is your own model keys, which means a model provider account, its own limits and its own billing, and a machine that can hold a development server.
coder/coder is the opposite: a server you operate. A first run uses a built-in database and an evaluation URL, which is fine for a look, while a production deployment is expected to point at PostgreSQL and an external access URL. Around that sit the WireGuard tunnels that connect a browser to a workspace, a Terraform provider for the deployment itself, and a registry of templates and modules describing the infrastructure a workspace needs. The agent loop is the part that changes the bill, because inference happens on your side rather than in a hosted editor.
gitpod-io/gitpod wants a Kubernetes cluster. The install path sits under install/ in the repository, and the workspace images your definitions refer to are published separately in a sibling repository, so there is a dependency to track that is not in the code you cloned.
codesandbox/codesandbox-client costs a JavaScript build rather than a server: a Yarn install across a Lerna monorepo, with a postinstall chain to read first. Whether the resulting client can stand alone depends on which server repositories you also bring in.
Licences: Apache-2.0 with a fair-source corner, two AGPL-3.0 and one GPL-3.0
This list contains four different licence situations, and three of them carry conditions a company should look at before the first deployment.
dyad-sh/dyad is the mixed one. Everything in the repository outside src/pro is Apache 2.0, which is permissive: you can modify it, host it and ship it without publishing anything. The src/pro folder is under the Functional Source License, which is fair-source rather than open source, so the rights come with conditions attached and that licence file has to be read for the ones that apply to your use. The practical consequence is that which features you get depends on where in the repository they live, and both files need reading before you decide what you may ship.
coder/coder and gitpod-io/gitpod are AGPL-3.0, which is network copyleft. Run either unmodified for your own staff and you publish nothing. Modify it, let others reach the modified instance over a network, and the licence asks you to offer them the source of your modified version. That obligation is the one to check against your policy, and gitpod adds a second question because its package.json mixes AGPL-3.0 with a package whose licence GitHub cannot classify.
codesandbox/codesandbox-client declares GPL-3.0 in package.json while GitHub reports the licence file as unclassifiable. GPL-3.0 is copyleft, and its obligation attaches when you distribute the code rather than when you serve it over a network, which is the difference from the AGPL pair above. Embed the client and never distribute it and the trigger does not fire; ship it inside a product and it does.
Choosing by scenario, and where each one is the weaker choice
For a solo developer who wants the Vercel v0 loop without a vendor holding the project, dyad-sh/dyad is the only candidate on this list that does that job. It is the weakest option for a team that needs shared accounts, permissions and a preview URL a colleague can open without installing anything.
For a team that has already chosen a builder and now needs somewhere safe to run the generated code, coder/coder is the one to look at, and the appeal is not the environments themselves but the agent loop with no model credentials inside a workspace. Its cost is a control plane, a database and a template library you maintain. gitpod-io/gitpod serves the same need for teams that standardised on .gitpod.yml, with the added complication that its README points new users elsewhere and its hosted offering was retired in 2025.
For a product team that wants a browser IDE inside its own application, codesandbox/codesandbox-client is the only project here of that kind, and the assumption to check first is whether you also want to assemble the server side.
The weaker choice in each pairing is worth saying. dyad is the weaker option when the output has to reach people who will not install a desktop application. coder is the weaker option when generation is what is missing, because it generates nothing. gitpod is the weaker option when you need a supported path forward, because the repository itself no longer points to one for new users. codesandbox-client is the weaker option when what you wanted was the hosted service, because the hosted service is not this repository.
Bottom line
Take dyad-sh/dyad if you want the prompt-to-application loop on your own machine, coder/coder if the question is where generated code runs and who runs it, codesandbox/codesandbox-client if you are embedding a browser IDE, and gitpod-io/gitpod only if your team is already committed to the .gitpod.yml workflow. Before committing, read the two licence files in dyad-sh/dyad, check the postinstall chain in codesandbox/codesandbox-client, and confirm that the agent loop in coder/coder keeps credentials out of the workspace as you expect.
Sources
Was this useful?