Dyad: a local AI app builder that runs on your own API keys

What Dyad solves, and who it is built for

Hosted app builders such as v0, Lovable, Replit and Bolt generate code in someone else's environment. Your prompts, your project files and your provider credentials pass through a service you do not operate, and the generated project lives behind that service's account and billing. Dyad takes the opposite position: it is a desktop application that runs the generation loop locally. The README states the goal plainly, describing it as "a local, open-source AI app builder" that is "fast, private, and fully under your control." The repository description calls it an alternative to v0, Lovable, Replit and Bolt.

The intended audience is stated in that same description: power users. That word is doing real work here. The advertised features are local execution, bring-your-own API keys, and Mac or Windows support. There is no hosted account in the loop, and the README says no sign-up is required. Someone who wants a browser tab and a monthly subscription is not the target. Someone who already holds an OpenAI, Anthropic or Google key, or runs Ollama on their own machine, and wants the builder to use it, is.

How the local generation loop is put together

The repository layout shows an Electron application. package.json sets the entry point to .vite/build/main_bootstrap.js and the build tooling is Electron Forge, with forge.config.ts at the top level and separate Vite configs for the main process, the preload script and a code-explorer worker. The UI layer is React and TypeScript, with Storybook and Playwright present for component work and end-to-end tests. Persistence is SQLite through Drizzle: there is a drizzle/ directory and a drizzle.config.ts at the root.

Model access is the part worth understanding before you install anything. The environment template lists OPENAI_API_KEY, ANTHROPIC_API_KEY and GOOGLE_API_KEY as optional, and separately defines OLLAMA_HOST for local models, with the comment that the default for Ollama is http://127.0.0.1:11434. That means the app can talk either to a hosted provider using a key you supply, or to a model server running on your own machine. The npm scripts also show a DYAD_ENGINE_URL variable and a dev:engine script pointing at http://localhost:8080/v1, so a build can be directed at a different engine endpoint than the default. The README does not document what that engine does or when you would point at it, which is a gap if you plan to work on the model layer.

Installing Dyad and generating a first app

The README does not give build-from-source instructions for end users. It points to a download page at dyad.sh with per-platform builds and states that no sign-up is required. If you want the packaged application, that page is the documented route, and the README does not describe a package-manager install for it.

Building from source is a different path, and the repository is the only guide. You need Node and npm, and the scripts in package.json define the workflow. The dev script sets NODE_ENV to development and starts the supervisor:

npm install
npm run dev

The dev:engine variant is the one to use when you want the app to talk to a local engine instead of the default endpoint:

npm run dev:engine

Provider credentials come from a .env file. The repository ships .env.example, and the header comment says to copy it to a file named .env and fill in your private keys, and that the real .env should not be committed. A minimal version for a hosted provider plus a local Ollama server looks like this:

OPENAI_API_KEY=
OLLAMA_HOST=

After the app starts, the workflow the README implies is: choose a model backed by one of those keys, describe the app you want, and let Dyad write the project files. The README does not document the generation screen, the prompt format or how to switch providers mid-project, so expect to learn that from the application itself. What you should see is a desktop window, not a browser tab, and no login screen, because the README states there is no sign-up.

The licence split is the real constraint

The README is explicit that this repository is not one licence. Code outside src/pro is Apache 2.0. Code inside src/pro is under the Functional Source License 1.1 with an Apache 2.0 future licence, which the README links to fsl.software. package.json also carries an MIT licence field, which does not match either of the two files the README points at. That mismatch is worth resolving with the LICENSE and src/pro/LICENSE files before you make any decision that depends on terms.

The practical consequence is that "open source" applies to the bulk of the tree but not to everything. If you are evaluating Dyad for a commercial product, or planning to fork and redistribute, the src/pro directory is where you need to read carefully. The README does not explain what functionality lives in src/pro, so you cannot tell from the documentation alone whether the part you care about is Apache 2.0 or fair-source. This is not a legal opinion, and the licence files are the authority, not this article.

Where Dyad is the wrong tool

The README does not document rollback, undo, or how to recover a project after a bad generation. For an AI builder that writes files into your project, that is a significant omission. Version control is your safety net, and the documentation does not describe an in-app one. If you are not comfortable managing git yourself, a hosted builder that keeps revision history for you may be the safer choice.

The second limitation is provider cost. Bring-your-own-keys means the token bill lands on your account, and the README does not describe any usage tracking or spend limit. A hosted builder bundles that into a subscription. If predictable monthly cost matters more than local execution, Dyad inverts the value proposition.

Third, platform support is stated as Mac and Windows. The README does not claim Linux desktop builds, even though the repository contains a .devcontainer/ directory and the project is developed on Linux tooling. Treat Linux as a source-build experiment, not a supported target, until you confirm otherwise. Finally, the README does not describe collaboration, sharing, or a hosted preview URL, so a team that needs to hand a running app to a non-technical reviewer will not find that here.

Dyad against v0, Lovable and Bolt

The README names v0, Lovable, Replit and Bolt as the comparison set. The difference is architectural, not cosmetic. Those products run the model call and the project workspace on their infrastructure; you reach them through a browser and an account. Dyad runs as an Electron app on your machine, stores state in a local SQLite database through Drizzle, and reaches models either with keys you paste into .env or through OLLAMA_HOST at http://127.0.0.1:11434.

That changes three things. Privacy: prompts and file contents stay on your machine, except for whatever the chosen provider receives. Cost model: you pay providers directly, at their rates, with no markup and no bundled quota. Control: you can point the app at a different engine with DYAD_ENGINE_URL, which a hosted product does not expose. The cost is that you own the setup, the key management and the recovery story. A hosted builder sells exactly those three things back to you.

Maintenance, upgrades and what the repository tells you

The repository is not archived, and the last push was on 2026-09-09. Release v1.14.0 landed the same day, after two betas on 2026-09-04 and 2026-09-07. That cadence, with beta builds preceding a stable tag, is the pattern visible in the release list. The package.json version is 1.15.0, ahead of the latest published release, which is normal for a main branch between tags.

Upgrade cost is mostly the Electron and Forge toolchain. The repository carries a native/ directory, a makers/ directory for platform installers, and a rebuild:keychain-reader script that runs before package, make and publish. That script name suggests a native dependency that must be rebuilt per platform, which is the kind of thing that breaks on toolchain upgrades. The README does not describe an update mechanism inside the app, so plan on reinstalling from the download page when a new version lands. The community channel named in the README is r/dyadbuilders on Reddit, which is where upgrade problems are most likely to surface first.

Editorial conclusion

Adopt Dyad if you want an AI app builder that keeps your code and keys on your own machine and you are willing to read the repository instead of a setup guide. Do not adopt it if you need a fully permissive licence across the whole tree, since src/pro is under the Functional Source License, or if you expect the README to walk you through configuration. Before committing, verify the licence boundary in LICENSE and src/pro/LICENSE, and confirm which provider or OLLAMA_HOST your build talks to.

Frequently asked questions

Official sources

1. dyad-sh/dyad on GitHub
2. Issues
3. Project website
4. README
5. Releases