OpenUI: prompt-to-UI generation with a self-hosted LiteLLM backend
OpenUI let's you describe UI using your imagination, then see it rendered live.
At a glance
- What is it?
- W&B's OpenUI turns a natural language description into rendered UI, then converts the result to React, Svelte or Web Components. The README is unusually candid about its limits, and the model routing is the part that decides whether it works for you.
- Who is it for?
- Adopt OpenUI if you want a self-hosted prompt-to-UI loop and you are willing to run the backend, supply your own model keys, and treat the generated markup as a starting point rather than a finished component. Skip it if you need a polished hosted design tool, or if your team cannot run a Python service alongside a frontend dev server.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The slog OpenUI is trying to remove
The README opens with a plain complaint: building UI components can be a slog. OpenUI's answer is to let you describe a UI in natural language and see it rendered live, then iterate by asking for changes. The second half of the pitch matters more than the first. Once you have something you like, the tool will convert the HTML into React, Svelte, Web Components, or another target, so the output is not trapped in the playground.
The audience is narrow but real. W&B states it is using OpenUI internally to prototype next-generation tooling built on top of LLMs. That tells you the project is a working instrument rather than a product with a roadmap aimed at you. Developers who already pay for a model API, or who run models locally, are the intended users. The README compares the project to v0 and describes it as open source and, in its own words, not as polished. That self-assessment is worth taking at face value when you decide how much to depend on it.
How the model routing actually works
The architecture visible in the README is a Python backend that serves a TypeScript frontend. The backend does not talk to each provider through bespoke code. It generates a LiteLLM configuration automatically from the environment variables you set, and LiteLLM handles the provider differences. That is why the same server can present OpenAI, Groq, Gemini, Anthropic, Cohere and Mistral models, plus anything reachable through an OpenAI-compatible endpoint.
If the generated config is not what you want, you can override it. The README gives a resolution order: a litellm-config.yaml in the current working directory, then /app/litellm-config.yaml when running in a container, then an arbitrary path from the OPENUI_LITELLM_CONFIG environment variable. That order is the single most important thing to understand about deployment, because a stray config file in the wrong directory silently changes which models appear in the selector.
Ollama sits alongside this rather than inside it. You install Ollama, pull a model such as llava, and the server talks to it at http://127.0.0.1:11434 unless OLLAMA_HOST points elsewhere. Models you pull show up in the settings modal, which is reached from the gear icon in the upper left corner of the application.
Getting a server running: Docker, source, or a dev container
Docker is the path the README labels preferred. One command forwards your keys from the shell and points the container at an Ollama instance on the host:
export ANTHROPIC_API_KEY=xxx export OPENAI_API_KEY=xxx docker run --rm --name openui -p 7878:7878 -e OPENAI_API_KEY -e ANTHROPIC_API_KEY -e OLLAMA_HOST=http://host.docker.internal:11434 ghcr.io/wandb/openui
The service listens on port 7878. The host.docker.internal address is the part people miss: a container cannot reach 127.0.0.1 on your machine, so the Ollama host variable has to be rewritten for the container network.
Running from source assumes git and uv. The README's sequence clones the repository, changes into the backend directory, runs uv sync --frozen --extra litellm, activates the virtual environment, exports a key, and starts the server with python -m openui. The --extra litellm flag is what pulls in the LiteLLM dependency, so a plain sync without it will not give you the multi-provider path.
There is also a dev container configured in the repository, which the README calls the quickest way to get started, and a Codespace flow. In the Codespace you run python -m openui --dev in one terminal and npm run dev from the frontend directory in another. The frontend dev server opens on port 5173, and the README says changes to both frontend and backend reload automatically. Gitpod is offered as a third option, preconfigured with OpenAI, and it launches the app on start.
Ollama and Groq: two very different local stories
The Groq path is the least demanding. Set GROQ_API_KEY and pick a Groq model from the settings icon in the nav bar. Nothing else changes.
The Ollama path is more involved and the README is unusually honest about it. The docker-compose route carries a disclaimer that it is likely to be very slow, that a GPU may require changing the tag of the ollama container, and that Mac users should run Ollama natively to take advantage of M1 or M2 hardware. The compose flow is two commands from the repository root: docker-compose up -d, then docker exec into the openui-ollama-1 container to pull llava. If you change the frontend or backend you need docker-compose build for the changes to appear.
The model choice is constrained in a way that is easy to overlook. The README notes that llava is one of the only Ollama models that supports images currently. If your workflow depends on feeding screenshots or mockups into the tool, that sentence limits your local options considerably. Text-only prompts are a different matter, and the README mentions that any model you pull, for example llama, will appear in the settings modal.
Where the project's own documentation sets the boundary
The most useful sentence in the README is the comparison to v0: open source, and not as polished. That is not modesty, it is a scoping statement. Expect the rough edges of an internal tool that was released rather than a product with a support contract.
There is no release history in the material provided, so there is nothing to say about versioning cadence, changelogs, or upgrade paths. The repository is not archived and the last push is recent, but a commit date tells you the project is alive, not that any particular interface is stable. If you build on the backend's HTTP surface, treat it as something that can move.
The licence is Apache-2.0. That is a permissive licence, which generally means you can use the code in commercial settings and modify it, subject to the conditions in the licence text itself. It is not legal advice; read the LICENSE file and, if the stakes are high, get a lawyer to read it too. The practical point is that OpenUI does not impose the copyleft obligations a GPL-licensed generator would.
One limitation is structural rather than documented: the tool depends on a model that is good at producing markup. A weak or heavily quantized local model will produce markup you then have to fix by hand, which removes most of the speed advantage. The README's own warning about compose being slow points at the same trade-off from the hardware side.
How this differs from v0 and from plain component libraries
v0 is the comparison the README itself makes, and the difference is not only the licence. v0 is a hosted product: you send a prompt, the vendor runs the model, and you get output in a browser. OpenUI inverts that. You run the backend, you hold the API keys, and the model routing is yours to configure through LiteLLM. That means your prompts and your generated UI do not leave your infrastructure when you point OPENAI_COMPATIBLE_ENDPOINT at a server you control, which is the reason to choose it over a hosted tool in the first place.
The trade is operational. With v0 there is no container to run, no OLLAMA_HOST to get wrong, no config resolution order to reason about. With OpenUI you own all of that, and you also own the consequences when a model provider changes an API. The second comparison is to component libraries such as a Tailwind-based kit. Those give you vetted, accessible components with known behaviour. OpenUI gives you generated markup that may or may not be accessible, and the README makes no accessibility claims. The two are not substitutes: one is a catalogue, the other is a drafting tool. If you need a button that behaves correctly in every browser, a library is the answer. If you need to see five layout ideas before lunch, OpenUI is the answer.
Maintenance cost and what to check before adopting
The upgrade surface has three parts. The Python backend pulls LiteLLM as an optional extra, so a LiteLLM release can change which providers behave correctly. The frontend is a separate npm project with its own dependency tree. And the container image is published to ghcr.io, which means you can pin a tag or track the default, and tracking the default means accepting whatever lands.
Because there are no releases in the material provided, there is no documented upgrade procedure. The README does tell you one operational fact worth remembering: after changing frontend or backend code under docker-compose, you must run docker-compose build for the changes to take effect. That is the kind of detail that costs an afternoon when it is forgotten.
Before adopting, verify the model path end to end. Set a single key, start the server, and confirm the model appears in the settings modal. Then confirm the image path if you need it, remembering the README's note that llava is one of the few Ollama models supporting images. Finally, check the LiteLLM config resolution order in your actual deployment directory, because a litellm-config.yaml sitting in the working directory takes precedence over everything else.
Editorial conclusion
Adopt OpenUI if you want a self-hosted prompt-to-UI loop and you are willing to run the backend, supply your own model keys, and treat the generated markup as a starting point rather than a finished component. Skip it if you need a polished hosted design tool, or if your team cannot run a Python service alongside a frontend dev server. Before you commit, verify two things: that your chosen model actually accepts images if you plan to work from screenshots, and that the LiteLLM config resolution order (litellm-config.yaml in the current directory, then /app/litellm-config.yaml in Docker, then OPENUI_LITELLM_CONFIG) picks up the file you expect in your deployment.
Community notes