ollama-gui: a Vue web interface for local Ollama models

What ollama-gui actually solves, and for whom

Ollama exposes an HTTP API on port 11434. That is enough for scripts and curl, and not enough for a conversation you want to scroll back through. ollama-gui fills that gap with a browser front end: a chat window, Markdown rendering, and history that survives a page reload. The README describes it as "a modern web interface for chatting with your local LLMs through Ollama".

The audience is narrow on purpose. You need Ollama installed and running, and you need either Docker or Node.js plus Yarn. If you already run Open WebUI or LM Studio and are happy with it, this project does not add a capability you are missing. It is for people who want a small Vue codebase they can read in an afternoon, or who want the UI and the model server started by one compose file.

How the Vue front end talks to the Ollama API

The stack is Vue 3, Vite, Tailwind CSS and VueUse, with markdown-it plus highlight.js for message rendering and Dexie over IndexedDB for persistence. The repository layout matches that: src/ holds the application, vite.config.ts holds the build and dev-server configuration, and compose.yml holds the two-service deployment.

The data flow is short. The browser calls the Ollama HTTP API, streams the response into the chat view, renders Markdown and code blocks, and writes the conversation to IndexedDB through Dexie. Nothing is stored server side by the GUI itself, which is why the README calls it "privacy-focused: All processing happens locally". That claim is about the GUI layer. The model still runs in Ollama, and if you point the GUI at a remote endpoint, the traffic leaves your machine.

The interesting design choice is the development proxy. Vite forwards API requests to the local Ollama instance so that other devices on your network can reach both the UI and the API without CORS configuration. It exists only under `yarn dev`. The README is explicit: "This proxy feature is only available during development." In a production build you configure CORS on Ollama or put a reverse proxy in front of it. That is a real fork in the road, and it is the part people get wrong.

Installing ollama-gui with Docker Compose

The Docker path is the one the README recommends for people who do not want to think about CORS. The compose file defines two services: `ollama` on port 11434 with a bind mount at ./ollama_data, and `ollama-gui`, built from the Dockerfile, published on port 8080. Because both run in the same compose network, the browser talks to the GUI and the GUI talks to Ollama without cross-origin setup.

Start it with:

docker compose up -d

Then open http://localhost:8080. The README gives that address. To stop everything, `docker compose down`.

Models are not included. Pull one inside the Ollama container:

docker exec -it ollama bash
ollama pull deepseek-r1:7b

The README uses deepseek-r1:7b as its example. Downloaded models land in ./ollama_data in the repository, and the README notes you can change that path in compose.yml. After pulling, the README says to run `docker compose restart`.

GPU users get a commented block in compose.yml:

    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: all
    #           capabilities: [gpu]

Uncomment those lines to request an NVIDIA device. If you leave them commented, Ollama runs on CPU, which is slower but works.

Running ollama-gui from source with Yarn

Local development needs Ollama, Node.js v16 or newer, and Yarn. The README's sequence pulls a model, starts the server, clones the repository, installs dependencies and starts Vite:

ollama pull mistral
ollama serve

git clone https://github.com/HelgeSverre/ollama-gui.git
cd ollama-gui
yarn install
yarn dev

To reach the UI from another machine on your network, `yarn dev --host` is the documented flag, and the README gives http://192.168.1.100:5173 as an example address. Port 5173 is Vite's default, and 11434 is Ollama's.

If you point the GUI at a custom Ollama endpoint, the README says to disable the dev proxy with the environment variable VITE_NO_PROXY:

VITE_NO_PROXY=true yarn dev

For a production build, `yarn build` runs vue-tsc and vite build. The README states plainly that the resulting static files contain no proxy server, so you either set OLLAMA_ORIGINS on the Ollama side or forward /api through nginx, Apache or Caddy. The hosted demo at ollama-gui.vercel.app follows the first route:

OLLAMA_ORIGINS=https://ollama-gui.vercel.app ollama serve

That command is worth reading twice. Using the hosted front end means your local Ollama accepts requests from that origin.

Where ollama-gui stops short

The roadmap is the honest summary of what is missing. Chat history, Markdown formatting and code cleanup are checked. Model library browsing and installation, mobile-responsive design, and file uploads with OCR support are not. So there is no way to pull a model from inside the interface; you do it in a terminal or inside the Ollama container. There is no file attachment path, which rules it out for document question answering workflows. And mobile layouts are explicitly unfinished, so a phone browser is not a target.

There is a second limitation in the deployment story. The Dockerfile copies the build output into nginx and declares `EXPOSE 8080`, but the nginx base image serves on port 80 by default, and compose.yml maps 8080:80. The README's instruction to open http://localhost:8080 works because of that mapping. If you adapt the image outside compose, the exposed port and the port nginx actually listens on are not the same number, and you have to reconcile them yourself. The README does not document this, and it does not document rollback or upgrade steps for the containers either.

Finally, the project has no releases listed. Version in package.json is 0.0.0 and it is marked private, so there is no published artifact to pin. You are tracking the main branch.

ollama-gui vs Open WebUI and vs the CLI

The comparison people search for is against Open WebUI, and the difference is scope. Open WebUI is a full application with user accounts and a model management surface. ollama-gui is a single-purpose chat client: one Vue app, one Ollama endpoint, history in the browser's IndexedDB. If your team needs multiple users and shared state, ollama-gui is the wrong shape, because its persistence lives in each browser profile rather than on a server.

Against the CLI, the trade is different. `ollama run` gives you a terminal session with no history beyond your shell and no Markdown rendering. ollama-gui gives you scrollback, formatted code blocks and dark mode, at the cost of running a web server and, in the Docker case, a second container. If your work is scripted or you pipe output into other tools, the CLI wins outright. If you want to read a long answer with code in it, the GUI does.

The third option worth naming is the hosted demo. It removes the build step entirely, but it moves your prompts through a third-party origin unless you run Ollama with OLLAMA_ORIGINS set to that domain, and even then the browser is talking to a page you do not host. For anything sensitive, the Docker path keeps both halves on your machine.

Licence and the cost of tracking main

ollama-gui is released under the MIT License, per the LICENSE.md file and the badge in the README. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and licence text are preserved. This is not legal advice, and the licence covers this project's code, not Ollama itself or any model weights you pull through it. Check those separately.

The maintenance picture is modest. The last push to the default branch was on 2026-08-06, which is recent enough that the project is not dormant. That said, there are no tagged releases, the package version is 0.0.0, and the roadmap still lists three unchecked items. Upgrading means pulling from main and rebuilding, and because the Dockerfile installs dependencies with `yarn install` against a committed yarn.lock, a rebuild can pick up different transitive versions than the last one. If you deploy this, pin the image you build rather than rebuilding from main on every deploy.

Editorial conclusion

Adopt ollama-gui if you want a browser chat client for a local Ollama server and you are comfortable with either Docker Compose or a Yarn dev server. Skip it if you need model browsing and installation from the UI, mobile layouts, or file uploads: all three are unchecked on the roadmap. Before committing, run docker compose up -d and confirm the GUI answers on port 8080, then check whether the Dockerfile's EXPOSE 8080 matches the nginx default port in your own deployment.

Frequently asked questions

Official sources

1. HelgeSverre/ollama-gui on GitHub
2. Issues
3. License: MIT
4. Project website
5. README