UPage: a self-hosted LLM page builder built on bolt.diy, under a modified GPLv3

The gap UPage fills between a prompt box and a finished page

Most LLM coding tools hand you a chat window and a diff. You still have to run the dev server, open a browser, and judge the result. UPage closes that loop: the README describes a visual editor with live preview, so the generated page is rendered next to the conversation that produced it, and layout or style adjustments happen in the editor rather than in a text buffer. The project also generates several related pages in one pass, which matters because a landing page without a pricing page and a contact page is not a site. Export is plain HTML, CSS and JavaScript, so the output is not locked to a proprietary runtime.

The intended user is not a front-end engineer. It is someone who can describe what a page should say and roughly how it should look, and who would otherwise start from a template or hand the job to a designer. The repository is TypeScript and the README credits bolt.diy for the code structure it was built on, so anyone who has used bolt.diy will recognise the shape of the thing: an agent loop, a file system abstraction, and a preview surface.

What it is not is a CMS. There is no mention of content collections, scheduling, or a database of articles. Halo, from the same organisation, is the project for that.

How the generation loop is wired: default model, minor model, vision sidecar

The environment variables reveal the architecture more clearly than the feature list does. There are three model roles. LLM_DEFAULT_MODEL builds pages, which is where the expensive, long-context work happens. LLM_MINOR_MODEL handles other tasks, described in the README only as such; the documentation does not enumerate which tasks, and that is a gap worth noting if you are trying to size a budget. The third role is a vision path: LLM_VISION_PROVIDER and LLM_VISION_MODEL, with their own VISION_PROVIDER_BASE_URL and VISION_PROVIDER_API_KEY.

The README explains the reason for the separate vision configuration. When the default model cannot read images, UPage uses the vision model to read the picture and produce a visual summary, which is then fed into generation. That is a summarisation hop, not a direct multimodal pass, and the quality of the resulting page depends on how much of the reference image survives that summary. The README's own tip says you can skip the vision variables entirely if your default model already reads images.

Storage behaviour is the other mechanism worth understanding. Uploaded reference images are written to disk on first send, and later turns in the same conversation reuse a file reference instead of retransmitting base64. This is a deliberate cost and latency decision, and it is why the README states that the storage directory must be persisted in production.

Deploying UPage with the documented docker run command

The README gives one command. On a Linux host with Docker installed:

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

LLM_PROVIDER is set to OpenAI, and the README states this is compatible with APIs that follow the OpenAI specification. PROVIDER_BASE_URL is optional for some providers and required for others; the README names Ollama and LMStudio as examples of providers that need it, and gives https://api.openai.com/v1 as the OpenAI form. PROVIDER_API_KEY is required by most providers. The interface is then available at http://localhost:3000. A 1Panel app store entry also exists, which is the lower-effort path if you already run 1Panel.

Three volumes are mounted. ./data and ./logs are self-explanatory. ./storage is the one the README singles out: because uploaded reference images land there and are reused by reference in later turns, losing that volume means losing the images the conversation depends on. Mount it somewhere backed up. The README does not describe a backup or migration procedure for it, so treat that as your responsibility.

Where UPage will disappoint you

The vision sidecar is a real constraint, not a footnote. If you pick a text-only default model and do not configure LLM_VISION_PROVIDER and LLM_VISION_MODEL, image references stop working. The README frames the sidecar as optional, which is true in the sense that the container will run without it, but the feature that depends on it will not. Anyone evaluating UPage against a screenshot or a Figma export should check image support before anything else.

The second limitation is harder to work around. Pages come out as HTML, CSS and JavaScript generated by a model. If your organisation has a component library, a design token file, or a strict accessibility review, the generated markup has to be reconciled with all of that by hand. The README's export feature makes the code portable; it does not make it conform to your system. For a one-off campaign page that is fine. For a product surface that ships weekly, you will spend the saved time on review.

The third is the licence, discussed below, and the fourth is simply that this is a young project. The release history shows v1.0.0 in September 2025, v1.0.1 a fortnight later, and v2.0.0 in May 2026. That is a small number of releases across a short window, and the README does not document an upgrade path between major versions. Plan for the possibility that v2 to v3 is a manual migration.

The licence is GPLv3 with branding strings attached

The repository is listed as NOASSERTION by the hosting platform, and the README explains why: it uses the FIT2CLOUD Open Source License, which the README describes as essentially GPLv3 with some additional restrictions. Two are stated. You may not replace or modify UPage's logo and copyright information. Derivative works must comply with GPLv3's open source obligations. Commercial licensing is available through support@fit2cloud.com.

For most self-hosted internal use, the practical effect is nil: you run the container, you generate pages, you ship the pages. The generated HTML, CSS and JavaScript is your output, and nothing in the README suggests the licence reaches it. Where it bites is white-labelling. If your plan is to fork UPage, strip the branding, and offer it as your own hosted builder, the first restriction blocks that, and GPLv3's obligations block the closed-source version of it. This is not legal advice; read the LICENSE file in the repository and get your own opinion if the fork is commercial.

The NOASSERTION label on the repository page is itself a small operational annoyance. Automated licence scanners will not classify it, so if your organisation gates dependencies on an SPDX identifier, UPage will land in the manual review queue.

UPage versus a template-driven site builder

The obvious alternative in this space is a template-based builder, the kind where you pick a layout, drop in content, and the CSS is fixed. Halo is the example closest to hand, since it is a sibling project from the same organisation and the README lists it first among them. The difference in approach is where variability lives. A template builder constrains the output so that every page is structurally consistent and the styling is known in advance. UPage does the opposite: the model decides the markup, so two prompts that describe similar pages can produce different DOM structures, and consistency has to be argued for in the prompt rather than guaranteed by the tool.

That trade is worth naming plainly. Template builders are faster to review and slower to produce something novel. UPage is faster to produce something novel and slower to review. If your pages are variations on a known shape, a template builder wins on cost and predictability, and no amount of model quality changes that. If your pages are genuinely bespoke and the bottleneck is the first draft, UPage's approach is the one that removes work.

There is also the DIY option: run bolt.diy directly, since UPage is built on its code structure. You would get a general coding agent rather than a page-oriented one, and you would give up the visual editor and the multi-page generation described in the README. Whether that trade favours you depends on how much of your work is pages versus everything else.

Maintenance cost and what to watch between releases

Running UPage means running three things you do not control: the container, your model provider, and the network path between them. The container itself is a single image, halohub/upage:latest, with no database and no external service dependency in the documented setup, which keeps operational surface small. The provider is the variable cost. Every page generation consumes tokens on LLM_DEFAULT_MODEL, every ancillary task consumes LLM_MINOR_MODEL, and every image reference consumes the vision model if one is configured. The README does not publish token estimates, so the only way to know your per-page cost is to watch your provider's usage dashboard during a pilot.

The upgrade path is the part to be careful about. The project has shipped one major version bump, from v1.x to v2.0.0, and the README documents no migration steps. The three mounted volumes are the state that would need to survive an upgrade, and the README's only guidance there is that ./storage must be persisted. Before you upgrade a running instance, take a copy of ./data and ./storage, read the release notes for the target version, and check whether the environment variable names changed; the model configuration is entirely environment-driven, so a renamed variable fails silently at startup rather than at build time.

One more thing to verify rather than assume: the README's quick start points to docs.upage.ai for the full guide, and the material here covers only the Docker path. Anything about user accounts, multi-tenancy, or project organisation lives in that documentation and is not visible from the repository description.

Editorial conclusion

Adopt UPage if you want a self-hosted prompt-to-page tool for marketing or landing pages and you are comfortable running a container that talks to an external model API, with the storage directory persisted. Do not adopt it if you need to rebrand the interface, if your pages must come from a fixed design system, or if you cannot send reference images to a third-party model provider. Before committing, verify three things: whether the model you intend to use supports image input (otherwise you must configure LLM_VISION_PROVIDER and LLM_VISION_MODEL), that ./storage is mounted on durable storage because uploaded reference images are written to disk and reused by file reference, and the exact terms of the FIT2CLOUD Open Source License, which the README describes as GPLv3 with additional restrictions on the logo and copyright notices.

Official sources

1. halo-dev/upage on GitHub
2. Issues
3. Project website
4. README
5. Releases