# LoLLMs WebUI: a local multi-model chat front end that is being wound down in favour of a new lollms project

> LoLLMs WebUI is a Python web interface for running local and remote language models through multiple bindings, personalities and extensions. The README states it keeps minimal support and will eventually be replaced by the newer lollms project, which is the first thing to weigh before adopting it.

**ParisNeo/lollms-webui** — Lord of Large Language and Multi modal Systems Web User Interface

- Repository: https://github.com/ParisNeo/lollms-webui
- Website: https://lollms.com
- Stars: 4,790 · Forks: 587
- Language: Python
- License: Apache-2.0
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/parisneo-lollms-webui

## What LoLLMs WebUI actually replaces in a local LLM setup

Running a model locally usually means picking one runtime and living with it. A GGUF file needs llama.cpp style tooling, an EXLLama v2 quantised model needs its own loader, and a hosted OpenAI or Anthropic key needs a different client entirely. LoLLMs WebUI puts a browser front end over all of them. The README lists bindings for Hugging Face local models, GGUF/GGML local models, EXLLama v2 local models in EXT, AWQ and GPTQ formats, Ollama, vllm, OpenAI, Anthropic, Open-router and Novita-ai. You choose a binding, a model and a personality, and the same chat window serves the result.

The audience is the person who already has a GPU or an API key and does not want a separate UI per runtime. The repository also ships personalities and a zoo structure, and the README claims access to over 500 AI expert conditioning sets and more than 2500 fine tuned models across domains. Treat those numbers as the project's own marketing copy rather than a measured inventory. What is verifiable from the repository layout is the mechanism: personalities and bindings live in zoo directories, and the web directory holds the interface itself.

The description on the repository calls it local, single user and multi model/modal. That single-user framing matters. This is not a multi-tenant chat server with accounts and quotas. The newer lollms project is the one described as having multi users and MCP compatibility, which tells you where the maintainer's effort is pointed.

## How bindings, personalities and the FastAPI backend fit together

The dependency list in requirements.txt is the clearest view of the architecture. fastapi and uvicorn serve the interface, python-socketio handles the streaming channel between browser and backend, and lollms_client is the library that talks to model backends. That split means the web UI is a thin layer: it collects a prompt, a selected binding, a selected model and a selected personality, hands them to lollms_client, and streams tokens back over the socket.

Several entries in the same file hint at the extension surface rather than the chat path. safe_store appears to be the local storage layer, freedom-search and scrapemaster point at web retrieval, and PyQT5 is present even though this is a web interface, which suggests some component still expects a Qt environment. That last one is worth noting because it pulls GUI system libraries into what you might otherwise expect to be a headless deployment.

The Dockerfile confirms the runtime shape. It starts from python:3.11-slim, installs git, build-essential and a set of OpenGL and X libraries including libgl1, libglib2.0-0, libsm6, libxext6 and libxrender-dev, clones the repository with submodules, installs requirements.txt, installs torch, and installs lollms_core in editable mode. The image then writes a global_paths_cfg.yaml that points lollms_path at /app/lollms-webui/lollms_core/lollms and lollms_personal_path at /app/personal_data. Personal data and model storage are therefore expected to live outside the code tree, which is what makes the volume mounts in docker-compose.yml meaningful.

## Installing LoLLMs WebUI and sending a first prompt

The README offers two routes. The automatic route is a script from the scripts folder: lollms_installer.bat on Windows, lollms_installer.sh on Linux, lollms_installer_macos.sh on macOS. The manual route, which the README says returned in version 10.14, starts from a Python 3.11 requirement. The README text available here stops right after that sentence, so read ManualInstall.md in the repository for the remaining steps rather than guessing them.

If you prefer containers, the repository ships a Dockerfile and a docker-compose.yml. The compose file maps the container port 9621 and reads an optional PORT variable from the environment:

```yaml
services:
  lollms-webui:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "${PORT:-9621}:9621"
    volumes:
      - ./personal_data:/app/personal_data
      - ./models:/app/models
      - ./custom_personalities:/app/custom_personalities
    environment:
      - ALLOWED_CLIENT_IP=172.18.0.1
    restart: unless-stopped
```

Note the mismatch between that mapping and the Dockerfile, which declares EXPOSE 9600 and starts the app with a host and a remote-access flag. The compose file is the file that decides which port your browser reaches, so use 9621 unless you change it. The ALLOWED_CLIENT_IP value in the repository is a Docker bridge address, not a general access control list.

The container entrypoint is worth reading before you run it:

```dockerfile
CMD ["python", "/app/app.py", "--host", "0.0.0.0", "--force-accept-remote-access"]
```

That combination binds the interface to every network interface and accepts remote access without a prompt. On a laptop behind a home router that is probably fine. On a shared network it is not, and the compose file's port mapping is what decides whether anyone else can reach it. The environment file .env.example at the top level is where you should look for the variables the project expects.

For a manual install, the README's stated starting point is Python 3.11, and requirements.txt pins numpy to the 1.26 series and requires Pillow at 9.5.0 or later alongside fastapi, uvicorn, python-socketio, tiktoken, lollms_client at 1.6.10 or later, safe_store at 2.1.0 or later, freedom-search at 0.1.9 or later and scrapemaster at 0.2.0 or later:

```bash
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
pip install -e lollms_core
python app.py
```

After the server starts, open the port the process reports and pick a binding, a model and a personality from the interface. That three-part selection is the first real action in LoLLMs WebUI, and it is also where most first-run problems appear: an unpopulated binding list means the backend did not find a usable runtime.

## The maintenance signal you cannot ignore

The README opens with a pointer to a new lollms project and states plainly that this web UI keeps minimal support and will eventually be completely replaced. That is the maintainer's own description, not an inference. The last push to this repository was on 2026-09-07, so the code has not been abandoned, but the direction of travel is documented in the first paragraph of the README.

The release cadence tells a similar story. The most recent release listed is v14, named Saïph, dated 2024-11-11. Before that came v13, named feather, on 2024-10-07, and v12, named Strawberry, on 2024-09-01. Those are roughly monthly intervals through late 2024, and the release list here stops there. Anyone depending on tagged releases rather than the main branch should check whether newer tags exist before planning an upgrade path.

There is also a version inconsistency inside the repository. setup.py declares version 5.0.2 while the releases run to v14. The packaging metadata and the release naming are not in sync, which matters if you intend to install from a package index rather than cloning. It is a small thing, but it is the kind of small thing that costs an afternoon when you are trying to pin a version.

## Where LoLLMs WebUI is the wrong tool

The most concrete limitation is the single-user framing in the repository description. If you need several people sharing one deployment with separate conversation histories and access boundaries, this is not the project the README describes as fitting that job. The newer lollms project is the one described as multi user.

The second limitation is the dependency surface. The container installs torch and a stack of OpenGL and X libraries to satisfy PyQT5, which is a heavy footprint for what is fundamentally a browser interface. On a headless server you are paying for a GUI toolkit you may never open. The numpy pin to 1.26 plus Pillow at 9.5.0 or later can also conflict with other Python packages in a shared environment, so a dedicated virtual environment or container is the realistic deployment.

The third is documentation depth. The README's manual install section ends mid-thought in the text available, and the README does not document rollback or a downgrade procedure between releases. The Dockerfile writes a global_paths_cfg.yaml with lollms_path and lollms_personal_path keys, but the README does not explain what happens to your stored conversations when those paths change. If you are evaluating this for anything beyond personal use, that gap is the one to close first by reading ManualInstall.md and the configuration files in configs/.

## How it compares with a single-runtime front end such as GPT4All

GPT4All appears in the same search space as LoLLMs WebUI, and the difference is architectural rather than cosmetic. GPT4All is a desktop application built around local model files. LoLLMs WebUI is a server process with a browser client, and its distinguishing feature is the binding layer: the same interface can point at a local GGUF file, an EXLLama v2 quantisation, an Ollama or vllm service, or a hosted OpenAI, Anthropic, Open-router or Novita-ai endpoint. The README also lists prompt routing to different models depending on task complexity, which a single-runtime desktop client does not attempt.

That breadth is the trade. A desktop client that targets one runtime can keep its dependency list short and its install simple. LoLLMs WebUI carries FastAPI, socket.io, a storage layer, search and scraping libraries, and a Qt dependency, and it asks you to choose a binding before anything works. If you only ever run one local model and never want a remote endpoint, the extra surface buys you very little.

A second comparison point is the extension model. Personalities are first-class objects here, with predefined welcome messages per the feature list, and the repository has zoos/ and extensions/ directories at the top level. A tool that treats system prompts as a text field you retype each session is a different product from one that ships a personality zoo. Neither is better in the abstract; they serve different habits.

## Licence and the cost of keeping it running

The repository is Apache-2.0, and setup.py declares the classifier License :: OSI Approved :: Apache 2.0 License. That is a permissive licence, which means redistribution and modification are allowed under its terms. It says nothing about the models you connect it to. A GGUF file, an EXLLama v2 quantisation or a hosted API endpoint each carry their own licence or terms, and the Apache-2.0 grant on this interface does not extend to them. That is not legal advice; it is the boundary you need to check with whoever owns the model licence you intend to serve.

The upgrade cost is the more practical concern. Because the README states the project will eventually be replaced, every upgrade decision has to answer a question the README does not: whether the newer lollms project reads the same personal_data layout and the same global_paths_cfg.yaml keys. The Dockerfile shows lollms_personal_path pointing at /app/personal_data, and docker-compose.yml mounts ./personal_data into that path, so your conversations and configurations live in a directory you control. Keeping that directory outside the image is the one piece of future-proofing the repository files actually support.

## Conclusion

Adopt LoLLMs WebUI if you want a single web interface that can switch between Hugging Face, GGUF, EXLLama v2, Ollama, vllm, OpenAI, Anthropic, Open-router and Novita-ai bindings without leaving the browser, and if you accept that the README states support is minimal and the project will eventually be replaced by the newer lollms project. Skip it if you need a long-lived platform with a documented upgrade guarantee, or if your machine cannot run the Python 3.11 stack and its pinned dependencies. Before committing, verify the current binding you intend to use still appears in the bindings list, check what the release notes for v14 say about migration, and read ManualInstall.md rather than relying on the README, which stops mid-sentence after the Python 3.11 requirement.

## FAQ

### What is a web UI, and what does LoLLMs WebUI add to it?

A web UI is a browser-based interface to a program that runs on your machine or a server. LoLLMs WebUI serves a chat interface through FastAPI and uvicorn, then routes each prompt to a chosen binding such as Hugging Face, GGUF, EXLLama v2, Ollama, vllm, OpenAI, Anthropic, Open-router or Novita-ai.

### How do I install LoLLMs WebUI with Docker?

The repository ships a Dockerfile and a docker-compose.yml. The compose file builds from the local context, maps port 9621 with a PORT override, and mounts ./personal_data, ./models and ./custom_personalities as volumes. The Dockerfile starts from python:3.11-slim, clones the repository with submodules, installs requirements.txt and torch, and installs lollms_core in editable mode.

### Which model bindings does LoLLMs WebUI support?

The README lists Hugging Face local models, GGUF/GGML local models, EXLLama v2 local models in EXT, AWQ and GPTQ formats, Ollama, vllm, OpenAI, Anthropic, Open-router and Novita-ai. It also states support for prompt routing to different models depending on task complexity.

### Is LoLLMs WebUI still maintained?

The last push to the repository was on 2026-09-07, and the most recent release listed is v14 from 2024-11-11. The README states that the web UI keeps minimal support and will eventually be completely replaced by the newer lollms project, which is the maintainer's own description.

### What port does LoLLMs WebUI run on?

The docker-compose.yml maps ${PORT:-9621}:9621, so the browser reaches port 9621 unless you set PORT. The Dockerfile declares EXPOSE 9600 and starts app.py with --host 0.0.0.0 and --force-accept-remote-access, so the compose mapping is the file that decides the port you actually use.

## Sources

- [License: Apache-2.0](https://github.com/ParisNeo/lollms-webui/blob/main/LICENSE)
- [ParisNeo/lollms-webui on GitHub](https://github.com/ParisNeo/lollms-webui)
- [Project website](https://lollms.com)
- [README](https://github.com/ParisNeo/lollms-webui/blob/main/README.md)
- [Releases](https://github.com/ParisNeo/lollms-webui/releases)

---

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