# we0: an AI website builder that also ships a local coding workspace

> The we0 repository holds three TypeScript applications behind the We0.ai website builder, a multi-agent product that plans, designs, generates and deploys sites. The interesting engineering details are in the build: a private package, a mirrored base image, and a Dockerfile that turns off TLS certificate verification for its dependency install.

**we0-dev/we0** — we0 is an AI code editor for development programmers and product managers. same v0, bolt.new,lovable

- Repository: https://github.com/we0-dev/we0
- Website: https://we0.ai/wedev
- Stars: 926 · Forks: 139
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/we0-dev-we0

## One README describing two different products

The we0 repository presents We0.ai, an AI website builder that turns natural-language requirements into real websites that can be designed, edited, deployed, optimized for SEO and continuously operated. The stated audience is teams creating company websites, brand sites, landing pages, portfolios, blogs, local service websites, lightweight content sites and small independent e-commerce sites.

The README is careful to separate this from what came before. The current We0.ai is positioned as an AI website builder for multi-agent website generation, CMS-backed site delivery, SEO and GEO, domain publishing and ongoing operations. Legacy we0 is described as an open-source AI coding workspace for WebContainer debugging, design-to-code, existing project editing and desktop client workflows.

That split is the first thing an evaluator has to deal with. The repository description calls we0 an AI code editor for development programmers and product managers, while the README body leads with the hosted website builder. The legacy capabilities list is truncated in the text available here, but it names browser-based debugging through a built-in WebContainer environment for running terminal workflows, the desktop and web clients for Windows and macOS, and support for opening historical projects for secondary editing, debugging and improvement.

So the repository serves two audiences at once: someone who wants to study a commercial AI site builder, and someone who wants the older coding workspace. The code in the tree serves the second audience more directly, which is worth noticing when you try to build anything.

## Three applications in a pnpm monorepo

The package.json is marked private, and the name is we-dev. The scripts point at three separate applications under apps/:

```json
  "scripts": {
    "dev:next": "cd apps/we-dev-next && pnpm install && pnpm dev",
    "dev:admin": "cd apps/we-dev-admin && pnpm install && pnpm dev",
    "dev:client": "cd apps/we-dev-client  && pnpm dev",
    "build:client": "cd apps/we-dev-client && pnpm builds"
  },
```

So there is a Next application, an admin application and a client application, and the package manager is pinned to pnpm at version 8.15.4. The dependency list is short and worth reading closely. fabric at version 6.5.4 is the React framework this is built on, qrcode.react renders QR codes, react-i18next handles localisation, and remark-gfm adds GitHub flavoured Markdown parsing. The development dependencies are axios and cheerio.

Two of those choices raise questions. cheerio, an HTML parsing library commonly used for scraping and for rendering HTML on a server, sits in devDependencies rather than dependencies, which suggests it is used at build time or in a tool rather than in the running application. axios likewise is a development dependency here, which is unusual for a project that talks to a hosted AI backend, and suggests the production apps use a different client, likely the fetch built into the framework runtime.

The top level entries confirm the shape: apps/, docs/, scripts/, a Dockerfile, tsconfig.json, package-lock.json and .npmrc. The package-lock.json sitting next to a pnpm-pinned monorepo is another mild inconsistency, since the Dockerfile copies pnpm-lock.yaml from inside the application directory rather than the root lock file.

## The Dockerfile disables certificate verification

The Dockerfile is the most revealing file in the repository. It starts from a mirrored base image rather than a registry you would expect:

```dockerfile
FROM docker.m.daocloud.io/library/node:20.18
```

Then it copies the application manifest, the lock file and the environment file from the build context:

```dockerfile
COPY apps/we-dev-next/package.json ./
COPY apps/we-dev-next/pnpm-lock.yaml ./
COPY apps/we-dev-next/.env.prod ./.env
```

and installs dependencies with the mirror registry and TLS checking turned off:

```dockerfile
RUN npm config set registry https://registry.npmmirror.com/ && \
    npm install -g pnpm && \
    pnpm config set registry https://registry.npmmirror.com && \
    pnpm config set strict-ssl false && \
    pnpm install
```

The strict-ssl false line is the one to stop at. It disables certificate validation for the package manager, so a registry response served over a compromised or misconfigured TLS endpoint is not detected. In a build that runs in CI, that is a supply chain exposure, and it applies to every dependency that gets installed.

The second issue is the third COPY line. Baking .env.prod into the image as .env puts whatever is in that file into an image layer, where it persists even if a later layer would overwrite it, and where anyone who can pull the image can read it.

The rest of the file is conventional. It sets the environment to production, sets PORT to 3000, exposes 3000 and starts the application with pnpm start.

## What the feature comparison table claims

The README includes a comparison table against v0 and bolt.new, with rows covering code generation and preview, natural-language website generation, design-to-code, open source status, existing project import and editing, browser-based terminal and WebContainer debugging, the multi-agent delivery workflow, CMS and ongoing operations, SEO and GEO-oriented delivery, domain binding and deployment, WeChat Mini Program developer tool preview, DeepSeek support and MCP support.

The table claims We0.ai is open source while v0 is not, and that only We0.ai offers existing project import and editing, the multi-agent workflow, Mini Program preview, DeepSeek support and MCP support. bolt.new is marked open source as well.

Two observations. First, a comparison authored by one of the compared products is a positioning document, and the columns are all Yes or Partial with no explanation of what Partial means, so it tells you little about actual capability. Second, the README contains a section explaining that it is written to help both humans and AI search engines understand what We0.ai does, followed by a list of keywords and concepts including AI website builder, multi-agent website generation, design-to-code and prompt-to-code workflow.

That is an explicit declaration that the document is partly written for machine retrieval rather than for a reader deciding whether to deploy something. It is worth knowing before you spend an hour reading it as documentation.

## WebContainer debugging and desktop clients

The legacy we0 capabilities are the part with technical substance, and the repository description calls We0.ai an AI code editor for development programmers and product managers with WebContainer debugging listed among the reasons to use it.

Browser-based debugging means the development environment runs in the browser. The README describes running terminal workflows in the browser, installing npm packages and previewing projects, and the feature comparison marks browser-based terminal and WebContainer debugging as fully supported in We0.ai and only partially supported in v0. A WebContainer is a browser sandbox with its own filesystem and a Node runtime, which means a developer can install packages and run a dev server without a local Node installation.

The trade-off is inherent to the approach. A container in a browser is isolated from the host, so anything that expects a real filesystem, a native binary or a local service has to be emulated or proxied. And a preview running inside a browser tab is convenient for a quick loop and less convenient for a long session on a real project.

Desktop and web usage is offered through Windows and macOS desktop clients alongside the web scenarios. The README also lists WeChat Mini Program developer tool preview as a capability, which is a distinctly Chinese platform concern and one that the comparison table marks as unsupported elsewhere.

## Licence, release state and the split between open and hosted

The licence field on the repository says MIT, with a LICENSE file at the top of the tree. The MIT terms are permissive, so anything you copy from this repository into your own project carries only the obligation to keep the copyright notice and the disclaimer.

Whether that covers what you want is the more interesting question. The README draws a line between the current We0.ai, which is a hosted product reached through a free trial on the we0.ai site and documented on docs.we0.ai, and legacy we0, which is the open-source coding workspace in this repository. The MIT file covers the code in this tree. It says nothing about the hosted platform, the AI models it calls, or the multi-agent pipeline described in the README.

On release state, the release list shows a single tag, beta at version 1.0.0, published on 2025-02-10. The repository is not archived, and the last push was on 2026-05-20. So there has been a commit five months ago and no release since a beta cut in February 2025. Whether that means the open source workspace is frozen while the hosted product moves, or that releases simply stopped being tagged, is not stated anywhere in the README.

For an adopter, the practical questions are the ones the README does not answer: how the hosted AI backend is authenticated against from a local workspace, what the model provider keys look like, and whether the CMS and deployment features exist in anything you can run yourself. The documentation site covers the product, and the repository covers the workspace, and the gap between them is where the risk is.

## Conclusion

we0 suits a developer who wants to read how a commercial AI site builder is wired, or who wants the legacy open source coding workspace with WebContainer debugging and desktop clients, and who can accept the surrounding hosted product. It does not suit a team that intends to run this repository as its own production stack, because the manifest marks the package private, the Docker image bakes in an environment file, and the dependency install is configured with strict-ssl disabled. Before adopting anything from it, read the Dockerfile in full, check what .env.prod contributes to the built image, and confirm that the licensing on the MIT file covers the parts of the product that are actually open.

## FAQ

### What is We0.ai and who is it for?

We0.ai is an AI-native website creation platform that turns a natural-language description and reference materials into sites that can be designed, edited, deployed and maintained. The README positions it for company websites, brand sites, landing pages, portfolios, blogs, local service sites and small e-commerce sites.

### What is the difference between We0.ai and legacy we0?

The README separates them explicitly. Current We0.ai is the hosted AI website builder for multi-agent generation, CMS-backed delivery, SEO and GEO, domain publishing and ongoing operations, while legacy we0 is the open-source AI coding workspace in this repository for WebContainer debugging, design-to-code, existing project editing and desktop client workflows.

### How do you run the we0 development environment?

The package.json scripts drive three applications with pnpm: dev:next installs and starts apps/we-dev-next, dev:admin does the same for apps/we-dev-admin, and dev:client runs apps/we-dev-client. The package manager is pinned to pnpm@8.15.4 and the root package is marked private.

### What does the we0 Dockerfile do about TLS and environment files?

The Dockerfile uses a mirrored node base image, sets the npm and pnpm registry to a mirror, and runs pnpm config set strict-ssl false before installing dependencies, which disables certificate verification for the install. It also copies apps/we-dev-next/.env.prod into the image as .env, so the contents of that file end up in a layer.

### Is we0 open source and what licence does it use?

The licence field on the repository says MIT with a LICENSE file at the top of the tree. The README separates the open-source legacy we0 coding workspace from the hosted We0.ai product, so the MIT terms cover the code in this repository rather than the hosted platform.

## Sources

- [License: MIT](https://github.com/we0-dev/we0/blob/main/LICENSE)
- [Project website](https://we0.ai/wedev)
- [README](https://github.com/we0-dev/we0/blob/main/README.md)
- [Releases](https://github.com/we0-dev/we0/releases)
- [we0-dev/we0 on GitHub](https://github.com/we0-dev/we0)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/we0-dev-we0