# UPage Review: A Self-Hosted LLM Web Builder for Teams That Want Their Code Back

> UPage is a Docker-deployed, TypeScript web builder that turns natural language prompts into exportable HTML, CSS and JS. The interesting part is not the generation, it is the license and the vision sidecar.

**halo-dev/upage** — 🔥 一款基于大模型的可视化网页构建平台，Lovable 开源替代。

- Repository: https://github.com/halo-dev/upage
- Website: https://upage.ai
- Stars: 553 · Forks: 104
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/halo-dev-upage

## The gap UPage fills between prompt tools and hand-written front ends

Most LLM page generators produce a single artifact you can look at but not own. You paste a prompt, get a rendered page inside someone else's editor, and the exit path is a screenshot or a copy-paste of markup that has already drifted from the preview. UPage takes the opposite position on the exit path. The README states that the platform generates standard HTML/CSS/JS and that this code can be exported for integration into an existing project or for further development. The output is the deliverable, not the session.

The audience follows from that. This is for a developer or a small product team that wants a first draft of a marketing page, a landing page, or a multi-page site skeleton, and wants that draft as files rather than as a hosted project. It is also for teams with a compliance or data-residency reason to keep the generation loop inside their own network, since the documented deployment is a Docker container on a Linux server with your own provider credentials.

UPage is built on the code structure of bolt.diy, which the README credits. That lineage explains the shape of the tool: a chat-driven build loop, a live preview, and a file-oriented output model rather than a proprietary document format.

## How the generation loop is wired: providers, models and the vision sidecar

The architecture visible in the repository is a React Router application with a Prisma data layer and a server entry point, packaged as a single container. The AI layer is assembled from the Vercel AI SDK provider packages. The package.json lists separate adapters for Amazon Bedrock, Anthropic, Cohere, DeepSeek, Google, Mistral, OpenAI and an OpenAI-compatible adapter, alongside agentic helper packages. That is the mechanism behind the claim of broad model support: each provider is a distinct dependency, not a generic passthrough.

Model selection is split across two environment variables. LLM_DEFAULT_MODEL is described in the README as the model used to build pages, while LLM_MINOR_MODEL is used for other tasks. Splitting them lets you spend a strong model on generation and a cheap one on the auxiliary calls, which is the practical reason the distinction exists.

The more interesting design choice is the vision sidecar. When the default model cannot read images, UPage falls back to a separately configured vision provider and model to read the picture and produce a visual summary. The README is explicit that this is optional, and that if your default model already handles images you can leave LLM_VISION_PROVIDER and LLM_VISION_MODEL unset. This is a clean separation, but it doubles the credential surface: you may end up managing two base URLs and two API keys.

Image handling also has a storage consequence. The README states that user-uploaded reference images are written to disk after the first send and reused by file reference in later turns, specifically to avoid re-transmitting base64 on every message. That is the right call for token cost, and it means the storage volume is part of the runtime, not a cache you can throw away.

## Installing UPage with Docker and generating a first page

The README's quick start assumes a Linux server with Docker installed. The command below is the documented one-shot invocation. Replace the placeholder values with your provider's base URL, key and model names before running it. The container listens on port 3000 and the three volume mounts map the data, log and storage directories to the working directory.

```bash
docker run -d \
  --name upage \
  --restart unless-stopped \
  -p 3000:3000 \
  -e LLM_PROVIDER=OpenAI \
  -e PROVIDER_BASE_URL=your-provider-base-url \
  -e PROVIDER_API_KEY=your-openai-api-key \
  -e LLM_DEFAULT_MODEL=your-default-model \
  -e LLM_MINOR_MODEL=your-minor-model \
  -v ./data:/app/data \
  -v ./logs:/app/logs \
  -v ./storage:/app/storage \
  halohub/upage:latest
```

After the container starts, the README says the interface is reachable at http://localhost:3000. If you are pointing at a local inference server rather than a hosted API, note the warning in .env.example about not using http://localhost:11434 for Ollama because of IPv6 issues, and using http://127.0.0.1:11434 instead. That same file lists the enabled providers, which include Anthropic, Cohere, DeepSeek, DouBao, Ernie, Google, Groq, HuggingFace, Hyperbolic, Kimi, Mistral, Ollama, OpenAI, OpenRouter, Perplexity, Qwen, xAI, ZhiPu, Together, LMStudio, AmazonBedrock and Github.

If you would rather not hand-write the container invocation, the repository ships two compose files for local work. The production one is the closer match to the quick start.

```bash
docker compose -f docker-compose-prod.yaml up
```

For a source checkout instead of a container, the package scripts show the expected sequence: a setup step that runs Prisma migrations and generates the client, then the dev server.

```bash
pnpm install
pnpm run setup
pnpm run dev
```

The first real use is the one the README describes: open the editor, describe the page you want in natural language, and let the build loop produce it. If you want the model to work from a visual reference, upload the image; that upload is what lands in ./storage and gets reused by reference on later turns.

## Where UPage gets in your way

The license is the first constraint and it is not a small one. The repository is under the FIT2CLOUD Open Source License, which the README describes as essentially GPLv3 with extra restrictions. Two of those restrictions are stated plainly: you may not replace or modify UPage's logo and copyright information, and derivative works must comply with GPLv3. For an internal tool this is irrelevant. For anyone whose plan is to white-label the editor and ship it as part of a commercial product, it is a hard stop unless you obtain a commercial license, which the README says is available by contacting support@fit2cloud.com. Note that the repository metadata reports the license as NOASSERTION, so the LICENSE.txt file is the authoritative text, not the machine-readable field.

The second constraint is the vision configuration. If your chosen default model cannot read images and you skip the vision variables, the image-reference workflow is simply unavailable. The README frames the sidecar as a recommendation for exactly that case, which means the feature set is not uniform across providers. A team that standardizes on a text-only model should treat image-driven generation as a separate capability with its own cost and credentials.

The third is operational. The README is direct that the storage directory must be persisted in production, because uploaded images are written there and referenced across turns. Running the container without that volume mounted will break multi-turn image conversations in a way that looks like a model failure rather than a configuration one. The Dockerfile sets MAX_UPLOAD_SIZE_MB to 5, so large reference images will be rejected at the upload boundary.

Finally, the README does not document a rollback path for generated changes, nor does it describe how concurrent editors on the same project are reconciled. If your workflow depends on either, verify it before you build a process around this tool.

## UPage compared with bolt.diy and with a hosted builder

The honest comparison starts with bolt.diy, because UPage is built on its code structure and says so. bolt.diy is a general-purpose browser-based AI development environment: you prompt, it writes an application, and the emphasis is on running and iterating on code across a range of stacks. UPage narrows that to web page construction, and the narrowing shows up in three places. It adds a visual editor with live preview for adjusting layout and style, it generates multiple related pages at once so you get a site structure rather than a single file, and it targets responsive output across desktop, tablet and mobile as a default rather than something you configure.

The second comparison is against the hosted category the README positions UPage against, describing it as an open source alternative to Lovable. The real difference is not features, it is custody. A hosted builder keeps the project, the history and the model routing on the vendor's side, and you interact through their account. UPage runs on your server, calls your provider account with your key, and writes files to your disk. The trade is that you own the uptime, the upgrades and the provider bill, and you get no managed support channel beyond the technical group the README points to.

A third option worth naming is plain code generation inside your existing editor, with no builder at all. That has zero deployment surface and no license question, but it also has no live preview loop and no multi-page generation, which is the specific thing UPage is selling.

## Maintenance, upgrades and what the license costs you over time

The repository is not archived. The most recent release is v2.0.0, published on 2026-05-08, and the last push to the default branch was on 2026-08-27. The release history is short and unevenly spaced: v1.0.0 on 2025-09-29, v1.0.1 on 2025-10-11, then v2.0.0 roughly seven months later. That pattern suggests a project that ships in larger increments rather than continuously, which matters if you depend on a specific fix landing quickly.

Upgrading is container-shaped, which is the good news. The documented install pins the image to halohub/upage:latest, so the standard upgrade is pulling a new image and recreating the container with the same volume mounts. The risk sits in the Prisma layer: the package.json setup script runs prisma migrate deploy, and the Dockerfile copies the prisma directory into the runtime image. A version bump that includes a schema migration will apply it against whatever is in your ./data mount. Back that directory up before pulling, since the README does not describe a downgrade procedure.

The license has a maintenance cost of its own. Because you cannot strip the UPage logo and copyright, any internal deployment keeps visible third-party branding. If that is unacceptable for your users, the commercial license conversation is a prerequisite, not an afterthought. This is a description of what the license text says, not legal advice; read LICENSE.txt and talk to counsel if the derivative-work question affects your product.

## Conclusion

Adopt UPage if you want an LLM page builder you can run on your own Linux host, plug into any OpenAI-compatible endpoint, and pull standard HTML/CSS/JS out of. Do not adopt it if you need to rebrand the interface or ship a closed derivative; the FIT2CLOUD Open Source License forbids removing the UPage logo and copyright, and derivatives must stay GPLv3. Before committing, verify two things against your own setup: that your default model handles images, or budget for the separate vision provider variables, and that ./storage is on persistent disk, because uploaded reference images are written there and reused by file reference in later turns.

## FAQ

### What does UPage stand for?

The repository does not expand the name into a phrase. The README presents it only as UPage, described as a large-model-based visual web building platform, and the domain is upage.ai.

### How do I install UPage on my own server?

The README documents a Docker one-liner that runs the halohub/upage:latest image on port 3000 with LLM provider environment variables and three volume mounts for data, logs and storage. It also notes that the 1Panel app store can be used to deploy UPage instead.

### Does UPage need a separate model to read images?

Only if your default model cannot read images. The README says LLM_VISION_PROVIDER and LLM_VISION_MODEL are optional, and that UPage will fall back to the configured vision model to read a picture and produce a visual summary when the default model does not support it.

### Can I remove the UPage logo from my deployment?

The README states that the FIT2CLOUD Open Source License forbids replacing or modifying UPage's logo and copyright information, and that derivative works must comply with GPLv3. Commercial licensing is offered separately via support@fit2cloud.com.

### What code does UPage generate?

The README says it produces standard HTML/CSS/JS that can be exported for integration into an existing project or for further development, and that generated pages are responsive across desktop, tablet and mobile.

## Sources

- [halo-dev/upage on GitHub](https://github.com/halo-dev/upage)
- [Issues](https://github.com/halo-dev/upage/issues)
- [Project website](https://upage.ai)
- [README](https://github.com/halo-dev/upage/blob/main/README.md)
- [Releases](https://github.com/halo-dev/upage/releases)

---

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