OpenUI renders a described interface live, and every documented install uses its latest image

Port 7878 serves the app, port 5173 serves the frontend you are editing

Two ports show up in every path. The packaged app answers on 7878, which is the port in both the Docker run command and the compose file, and that is the address you visit after a normal install. The frontend dev server answers on 5173, and it only exists when you run the server in development mode with `python -m openui --dev`, then move into the frontend directory and run `npm run dev`. Changes to either side reload automatically in that setup. If you instead edit code and run the Docker image, nothing reloads: the compose notes are explicit that you need `docker-compose build` for frontend or backend edits to be reflected in the service. The two modes are not interchangeable, and mixing them leaves you wondering which of the two ports is stale.

The compose model pull names a container the compose file renames

Starting the local model stack is two lines from the root directory:

docker-compose up -d
docker exec -it openui-ollama-1 ollama pull llava

The compose file sets `container_name: ollama` on that service, and the container is created as openui with an Ollama service alongside it. The exec line targets a name in the older compose naming style, so on a fresh bring-up there is no container at that address and the pull never lands where the app looks. That matters because the models you pull are the models the settings gear icon shows you. The same section carries a disclaimer that the compose route will be very slow, that a GPU user may have to change the ollama image tag to one that supports it, and that Mac users should run Ollama natively instead to use the M1/M2.

`uv sync --frozen` will not re-lock, so a lockfile drift stops the install

The source path assumes git and uv, and then does four things in order:

git clone https://github.com/wandb/openui
cd openui/backend
uv sync --frozen --extra litellm
source .venv/bin/activate
# Set API keys for any LLM's you want to use
export OPENAI_API_KEY=xxx
python -m openui

`--frozen` means the resolver will not update the lockfile. The `--extra litellm` part is not optional decoration: without it the LiteLLM support and its `--litellm` flag have nothing to run against. Note also that the separate LiteLLM recipe uses a different toolchain entirely, `pip install .[litellm]` in the same backend directory, which means two installs into two environments if you follow both pages. Run that bracket argument quoted, since an unquoted bracket is a shell glob.

Three config locations decide which LiteLLM model list wins

OpenUI builds a LiteLLM config from your environment variables and then looks for a config of your own in three places, in order: `litellm-config.yaml` in the current directory, `/app/litellm-config.yaml` when running in a Docker container, and an arbitrary path named by `OPENUI_LITELLM_CONFIG`. A custom config therefore beats the generated one, and the current-directory file beats the container path, which means a stray litellm-config.yaml left in the working directory silently wins over the mounted one. Mounting one in Docker takes its own command:

docker run -n openui -p 7878:7878 -v $(pwd)/litellm-config.yaml:/app/litellm-config.yaml ghcr.io/wandb/openui

Notice that the container-name flag here is written differently from the preferred command, which uses `--name openui`. Follow the first form if anything you script depends on the container name.

Seven key variables feed one model selector, and a dummy value stands in for a real one

Keys are all optional at the environment level: `OPENAI_API_KEY`, `GROQ_API_KEY`, `GEMINI_API_KEY`, `ANTHROPIC_API_KEY`, `COHERE_API_KEY`, `MISTRAL_API_KEY`, plus `OPENAI_COMPATIBLE_ENDPOINT` and `OPENAI_COMPATIBLE_API_KEY` for anything LiteLLM speaks to, which is how a localai instance gets listed under LiteLLM in the model selector. Ollama models appear in the same selector through the gear icon, from the default host at `http://127.0.0.1:11434` or whatever `OLLAMA_HOST` points to. With no key and no Ollama reachable, there is no model to call and nothing renders; the Codespaces guidance makes this concrete, telling you to set OPENAI_API_KEY to `xxx` purely so you can get to the Ollama models. Groq models need `GROQ_API_KEY` and a trip to the settings icon in the nav bar.

The Ollama host value is not the same in the two documented topologies

The plain Docker run forwards keys with -e flags and points the app at the host machine:

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 compose file uses a different value for the same variable, `OLLAMA_HOST=http://ollama:11434`, addressing the Ollama service inside the compose network, and it publishes 11434 as well:

  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ${OLLAMA_VOLUME_PATH:-ollama}:/root/.ollama

So the setting that works in one path is wrong in the other. The Ollama volume persists models through a named volume you can redirect with OLLAMA_VOLUME_PATH.

Compose reads a .env file while the Docker run relies on exported flags

The compose service passes exactly three keys through its environment list, OPENAI_API_KEY, ANTHROPIC_API_KEY, and GROQ_API_KEY, then loads everything else from `env_file: .env`. The plain run has no env_file at all; it forwards whichever variables you name after -e. Export GEMINI_API_KEY or MISTRAL_API_KEY in your shell and the compose route will not carry it into the container unless you also put it in .env, while the Docker run route would have forwarded it had you listed it. The repository's top-level listing includes a .env file alongside .gitignore, so read what is already in yours before adding keys, since compose will hand every line to the container. In the Codespaces path the same key is configured as a secret, with the note that trying Ollama there calls for at least 16GB of RAM; the US West region is suggested for a fast boot.

There is no release behind the latest tag

Every documented install path resolves to the same moving target, `ghcr.io/wandb/openui:latest`, in the run command and in the compose file alike. The repository publishes no GitHub releases, so the docs give no version number to pin, and a container you started last month cannot be reproduced from what the docs tell you. The last push to the default branch is dated 2026-09-25, so the code is moving, but movement without releases means an image rebuild is your only upgrade and your only rollback is a rebuild you do not have. If you need a repeatable environment, build from the backend directory instead, where the compose file points a build context at ./backend with its own Dockerfile, and keep your own image tag.

Editorial conclusion

OpenUI suits engineers who want to argue about an interface with a model before writing components, and who are comfortable running a Python backend beside a dev server. It does not suit a team that needs reproducible deployments: no GitHub releases exist, the image is referenced as latest, and the maintainers describe it as open source and not as polished as v0. Before adopting it, check whether your Ollama host and your API keys survive the exact Docker path you plan to use, because the documented options differ from one another.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. wandb/openui on GitHub