OpenUI

Last reviewed Aug 26, 2026 · 706 words

Type "a pricing page with three tiers, the middle one highlighted, dark mode", and OpenUI shows you the rendered page as the model streams it. Say "make the buttons rounder" and watch it change. Click Convert and get React, Svelte, Vue or Web Components. That loop takes seconds, costs a fraction of a cent per turn on a hosted model or nothing at all on Ollama, and is the whole point of the tool. What you get is a prototype: HTML and Tailwind that looks right and has no state, no data and no accessibility beyond what the model remembered to add. Used for what it is, it is the fastest way I know to get a layout in front of a stakeholder.

Setup is one container and one variable

docker run -d --name openui -p 7878:7878 \
  -e OPENAI_API_KEY=sk-... \
  ghcr.io/wandb/openui

Port 7878 is the UI. For local models, set OLLAMA_HOST=http://host.docker.internal:11434 (or wherever Ollama listens) instead of, or alongside, the OpenAI key, and the model picker lists whatever Ollama has pulled. Groq and anything fronted by LiteLLM work through the same mechanism. The project came out of Weights & Biases, and the 1 GB RAM rating is about right because the container does nothing heavy itself; the model does all the work elsewhere.

Which model to point it at

Output quality tracks the model's HTML and Tailwind fluency far more than its general intelligence. Small local coding models produce usable single-component layouts; a full landing page with consistent spacing wants a mid-sized or hosted model. My rule for Ollama users: a current 7B to 14B coder model in 8 to 12 GB of VRAM is plenty for components, and switch to a hosted model for whole pages. Because every iteration re-sends the current HTML as context, long sessions get expensive on hosted models, so start a fresh chat when you change subject.

What the output is, precisely

Each generation is a single HTML document styled with Tailwind classes, using placeholder images and no JavaScript beyond what a static mockup needs. The Convert step asks the model to rewrite that into a framework component, so React output is a plausible functional component with Tailwind, not a wired-up app. Expect to rename things, extract props and replace the placeholders. The image path exists too: upload a screenshot of an existing interface and ask for a recreation, which is useful for "make it look like this, but ours".

Where it sits next to the rest of the AI stack

OpenUI is a single-purpose front end, not a chat UI. Open WebUI is where you talk to models in general; OpenUI is where you go for the specific job of seeing a layout. It has no authentication of its own, so keep it on the LAN or behind the reverse proxy's login. It stores nothing you would miss: sessions live in the browser, and any output you want, you copy out. That also makes it safe to delete and recreate the container whenever you like, which is the right mental model for the AI category as a whole: the state lives in your prompts and your models, not in the tools.

Honest limits

Prototype-level output, as the project itself says. No design-system enforcement, so 10 generations will use 10 shades of blue unless you put hex values in the prompt. It cannot see your existing codebase or component library. Repository activity has slowed since its 2024 burst, so treat it as a stable tool rather than an evolving one, and check the commit log before making a team depend on it.

What I'd do

Run it on the AI box next to Ollama with a mid-sized local coder model as the default and a hosted key for the occasional full page. Use it live in meetings: describe, render, adjust, screenshot, done. Convert to React only for pieces you will actually build, and rewrite the result rather than pasting it. It replaces the first hour of every front-end ticket and none of the rest, which for a free container is a fair deal.