LlamaPen: a browser GUI for Ollama and other local LLM servers

The gap LlamaPen fills between a local model and a usable chat window

Ollama ships a command line and an HTTP API. That is enough to pull a model and send a prompt, but it is not a chat interface: no message history you can scroll, no rendered markdown, no math, no model download screen. LlamaPen is the layer above that API. The README describes it as "a no-install needed GUI for Ollama and other local LLM providers," and the key word is no-install: the app runs in a browser, so a phone on the same network can reach the same interface as a desktop.

The intended user is someone who already runs models on their own hardware. Ollama is pre-configured, so an Ollama user opens the app and starts typing. The README also lists one-click presets for llama.cpp, LM Studio, Jan and vLLM, plus a manual path for anything else speaking the OpenAI-compatible API. Hosted APIs can be added the same way, but the framing throughout is local first: "Requests only ever go to the providers you configure yourself."

That last sentence is the design promise. There is no relay server in the middle. The browser holds the conversation and sends it directly to the endpoint you entered.

How the Vue app, Dexie storage and provider layer fit together

The package.json shows the shape of the thing. It is a Vue 3 app built with Vite, using Pinia for state and pinia-plugin-persistedstate for persistence, Dexie for IndexedDB access, and two official client libraries: ollama and openai. That pairing explains the provider model. Ollama gets its own client; everything else is reached through the OpenAI-compatible client, which is why LM Studio, Jan, vLLM and arbitrary servers can share one code path.

Rendering is a separate concern. marked handles markdown, marked-katex-extension and katex handle LaTeX, highlight.js handles code blocks, and dompurify sanitises the result before it reaches the DOM. Any chat app that renders model output as HTML needs that sanitising step, and its presence is a good sign rather than an afterthought.

Chat storage is local. The README states that "All chats are stored locally in your browser," and Dexie is the IndexedDB wrapper that makes that practical for larger histories. The upside is stated as privacy and "near-instant chat load times." The trade-off is equally clear: browser storage is per-browser and per-origin. Clearing site data removes the conversations, and a container restart does not move them anywhere. There is no server-side database in the architecture, so there is nothing to back up centrally.

The Dockerfile confirms the deployment model. A build stage on oven/bun:1.3.13-slim runs bun install --frozen-lockfile and bun run build, then the output is copied into nginx:1.31-alpine and served on port 80. The shipped artefact is static files plus an nginx config. Nothing in the image talks to your models; the browser does.

Installing LlamaPen with Docker and a first chat against Ollama

The README recommends Docker and gives the image pull directly. Run it, then open the mapped port in a browser.

docker pull ghcr.io/imdarktom/llamapen:latest

docker run -d -p 8080:80 --name llamapen --restart unless-stopped ghcr.io/imdarktom/llamapen:latest

The README notes you can swap 8080 for any port you want. The --restart unless-stopped flag means the container comes back when the machine reboots, which matches the README's claim that it "runs on startup with your computer." After the second command, visit http://localhost:8080 and the app should load.

If you prefer to run from source, the README's manual route needs Git and Bun (1.3+ tested).

git clone https://github.com/ImDarkTom/LlamaPen.git
cd LlamaPen
bun install
bun run local

The bun run local script is defined in package.json as a build followed by a static server on port 8080, and it prints the URL when it starts. The README warns this path is "slightly less preferrable" because package or tool version differences can cause issues, which is a fair warning given the pinned Bun version in the Dockerfile.

One configuration detail matters if your Ollama is not on the default host. The .env.example file contains a single variable:

VITE_DEFAULT_OLLAMA=http://127.0.0.1:11434

Because it is a VITE_ variable, it is baked in at build time, not read at runtime. If you build your own image, set it before bun run build. If you use the published image, the default localhost address applies, and you should change the provider URL inside the app's settings instead. That distinction between build-time and runtime configuration is easy to miss and is worth checking before you debug a connection that was never going to work.

Where LlamaPen stops being the right tool

The local-storage decision is the biggest constraint. Chats live in one browser profile on one device. Open the app on your phone and you are looking at a different, empty history. There is no sync, no account, and no export path documented in the README. If a team needs a shared conversation log, or if you want your history to survive a browser reinstall, this architecture does not provide it, and no configuration option will add it.

The second limitation is the browser as the request origin. The app calls your provider from the page, so the provider has to accept cross-origin requests from wherever LlamaPen is served. Running it on localhost against a local Ollama instance is the well-trodden path. Serving it from a different host or port and pointing it at a model server elsewhere may run into CORS behaviour that the README does not discuss. That is the first thing to test in your own setup, and it is also why the README's manual route warns about environment differences.

Third, LlamaPen is a client, not a runtime. It does not download, quantise or serve weights. The README lists a built-in model and download manager, but the actual inference comes from Ollama or whichever server you point it at. If your problem is running models at all, this project is not the answer.

LlamaPen versus Open WebUI and the plain Ollama CLI

The obvious comparison is Open WebUI, which is also a self-hosted chat front end for local models. The difference is where state lives. Open WebUI is a server application with user accounts and a database, so conversations belong to the deployment and can be shared across devices and people. LlamaPen has no server-side state; the container serves static files and the browser owns the history. That makes LlamaPen simpler to deploy and harder to use as a shared tool.

The other comparison is doing nothing at all and using the ollama command line. The CLI is faster to start and has no image to pull, but it gives you no markdown rendering, no LaTeX, no keyboard-driven navigation and no model manager screen. LlamaPen's value is concentrated in those interface features, not in the transport, which is the same HTTP API underneath.

A smaller point worth noting: the README states that LlamaPen Cloud was discontinued, that all user accounts were deleted and refunds issued, and that OpenRouter and Ollama's native cloud models are now offered as built-in presets instead. Anyone who remembers the hosted version should read the current README rather than older write-ups. The project is now purely a local client.

Licence, maintenance cadence and what an upgrade costs

LlamaPen is AGPL-3.0, stated in the README and present as LICENSE in the repository root. That licence reaches network use: if you modify the code and let users interact with it over a network, the AGPL's source-availability obligations are generally understood to apply. Running the published image unmodified for yourself is a different situation from forking it into a product. This is not legal advice, and the specifics depend on your deployment, so read the licence text and, if the stakes are high, a lawyer.

The commit history visible here suggests a steady cadence rather than a burst. Releases are v1.2.0 on 2026-05-01, v1.3.0 on 2026-06-23 and v1.4.0 on 2026-09-09, and the last push to main was on 2026-09-09, the same day as the latest release. The repository is not archived. That is a healthy signal, but it is a signal about activity, not about support commitments, and the README offers no compatibility policy.

Upgrade cost is low in one sense and non-obvious in another. The container is stateless, so replacing the image is a pull and a restart. Your chats are not in the container, so they are not lost by an upgrade. But they are also not migrated by one, and because VITE_DEFAULT_OLLAMA is compiled in, a self-built image needs a rebuild whenever that value changes. The dependencies are pinned in bun.lock and the Dockerfile uses --frozen-lockfile, so a given image tag resolves to a fixed dependency set.

Editorial conclusion

Adopt LlamaPen if you run Ollama or another local server on your own machine and want a chat front end that stores conversations in the browser rather than in a hosted service. Do not adopt it if you need multi-user accounts, shared conversation history, or a permissively licensed component to embed in a closed product, since the repository is AGPL-3.0. Before relying on it, check the guide at llamapen.app/guide, confirm your provider's base URL against the VITE_DEFAULT_OLLAMA default of http://127.0.0.1:11434, and read the AGPL-3.0 file in the repository root.

Frequently asked questions

Official sources

1. ImDarkTom/LlamaPen on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases