hollama: a chat client that claims to run entirely in the browser and mostly does

One codebase, four adapters, and what browser-only actually rules out

The README opens with a single sentence: a minimal LLM chat app that runs entirely in your browser. That is accurate for the live demo at hollama.fernando.is and for the desktop build, and it is the reason the project has almost no server code. The feature list that follows is short enough to read in one pass: Ollama and OpenAI server support, multi-server support, text and vision models, reasoning models, markdown with syntax highlighting, KaTeX math, code editor features, customizable system prompts, message editing and retry, local browser storage, import and export, and direct model downloads from the Ollama model library inside the UI.

The repository tells you how the browser-only promise is kept. `package.json` carries four SvelteKit adapters in its dependency list: `@sveltejs/adapter-cloudflare`, `@sveltejs/adapter-node`, and two adapter paths named through build scripts, `PUBLIC_ADAPTER=electron-node` for the desktop build and `PUBLIC_ADAPTER=docker-node` for the container build. The `dev` and `build` scripts are unremarkable:

npm run dev
npm run build

So the same application is emitted in three shapes. Served statically from a CDN it is a pure client that talks directly to whatever server you configure. Built for Node or Electron it can carry a small local server, which is how the Electron app opens external links in your system browser rather than inside an app window. That last behaviour shipped in 0.36.0 as a fix for issue 324.

The practical reading of the headline is that your prompts and chats are not sent to an application server. They still go wherever you point the app, which for Ollama is usually `localhost:11434` on your own machine.

A year when desktop users were told to stay on an old build

The release history contains the most useful thing in the repository, and it is a warning rather than a feature. Version 0.35.3, published 2025-10-10, carries an explicit notice that it is a Docker-only release and that the most current version of Hollama for macOS, Linux or Windows is 0.35.1. Version 0.35.4, published two days later on 2025-10-12, repeats the same notice word for word. Both releases exist to fix one thing: port mapping for VITE after a container update, tracked as issues 335 and 336.

After that comes 0.36.0 on 2026-10-05, roughly a year later, and it is the first release that closes a long list of desktop-era issues. Sessions now stay in sync across browser tabs, closing issues 127 and 165. External links open in the system browser on desktop, closing issue 324. And reasoning that Ollama or an OpenAI compatible server sends in a separate field is now displayed, closing issues 313, 260 and 195 at once.

Both facts are true at once. The desktop channel was stuck on 0.35.1 while Docker-only patches accumulated, and then a single release three weeks before this snapshot moved the whole line forward. Nothing in the tree says whether desktop artifacts ship on the same cadence going forward. If you install the desktop app, the practical move is to check which channel the fix you need actually appeared in rather than assuming the highest tag is what you are running.

Version numbers come from `.releaserc.json` and the semantic-release packages in `devDependencies`, with `@semantic-release/npm` among them, which explains the commit-hash suffix style and the automatic changelog bodies.

No runtime dependencies at all, because nothing is installed from npm

Open `package.json` and you will not find a `dependencies` block. Every library is listed under `devDependencies`, from `@playwright/test` through `electron`, `codemirror`, `bits-ui`, `@lucide/svelte` and `date-fns`. That is not sloppiness. It is the correct shape for an application whose output is a bundle: Vite compiles the libraries into `build/`, and nothing fetches them at runtime.

It has one visible consequence in the container image. The production stage copies only the node binary out of the builder and then copies the built output:

ENV PUBLIC_ADAPTER='docker-node'
ENV PORT=4173
EXPOSE 4173
CMD ["node", "build/index.js"]

The Dockerfile comment above the final command says it runs the built application directly with no dependencies needed, and the final image is plain Alpine plus `libstdc++`, a non-root `appuser` in `appgroup`, and a single `COPY` of the build directory. There is no npm, yarn or corepack in the production stage at all. A reader comparing this to a typical Node service will find the image almost aggressively small.

One entry in that dependency list deserves a second look before you build from source. Tailwind's nesting plugin is pinned as `^0.0.0-insiders.565cd3e`, an insiders prerelease rather than a stable release. That is a normal choice during a design system migration and a poor one to inherit, because prerelease identifiers are not covered by ordinary semver compatibility promises. Nothing in the repo explains why it is needed or what would break if it were swapped for the stable build, so if you are vendoring this project, that pin is the first thing to test.

The Docker image is a CORS proxy with a chat UI attached

The presence of a Docker image at all is worth explaining, because a purely client-side app should not need one. The usual reason is the browser's same-origin policy: a page served from hollama.fernando.is cannot read a streaming response from `localhost:11434` unless Ollama is configured with permissive origins, so a self hosted hollama in a browser becomes a proxy that terminates the request server side and forwards it.

That framing explains several otherwise odd details. `SELF_HOSTING.md` exists as a separate document rather than a section, which fits a deployment whose interesting part is the network path rather than the app. The image exposes port 4173, the vite preview default, and runs the SvelteKit node output directly. The builder stage sets `PUBLIC_ADAPTER='docker-node'` before the build, so the adapter is chosen at compile time, which means a container image cannot be re-pointed at a different adapter at runtime.

The feature that most rewards this arrangement is model downloads from inside the UI. Pulling a model through a chat client means writing to the Ollama server rather than just reading from it, and the release notes for 0.36.0 also show the reverse direction: reasoning fields that some servers send separately are now rendered. Both changes are about the shape of the payload, not the chat logic.

Tests, screenshots and the translation setup

The `tests/` directory does double duty. It holds the Playwright suite and, more unusually, the images used in the README, which live under `tests/docs.test.ts-snapshots/` and are named session, settings, session-new and knowledge. Keeping documentation screenshots inside the test output directory means they are produced by the same run that checks the UI, so a broken layout is likely to be caught before a human notices the screenshot is stale.

The test script, invoked as a plain npm target, reflects a deliberate choice:

npm run test

The underlying Playwright invocation carries `--trace on --ignore-snapshots` means the visual baselines in that folder are not asserted against, so the images are documentation artifacts rather than regression gates. Tracing is on, which suits a browser application whose failures are often timing related. `playwright.config.ts` sits at the root next to `eslint.config.js` and `prettier.config`, and `npm run check` runs `svelte-check` for type errors while `npm run lint` runs Prettier in check mode followed by ESLint.

Internationalization runs through `typesafe-i18n`, with a `.typesafe-i18n.json` config and a dedicated script that the `dev` script runs concurrently with vite so translations compile alongside the app. Version 0.36.0 added Georgian, and the locale count is the kind of thing worth counting yourself in the source tree rather than inferring from the feature list, since the README only says multi-language interface without a number.

Where this fits against the other local clients

The search results around this project cluster it with LibreChat, Web Ollama, ChatUI, Chatbox, AnythingLLM and Mikupad, and the comparison is worth making concrete. AnythingLLM and LibreChat are multi-user server applications with accounts, document ingestion and a workspace model, so their storage is not in your browser and their feature lists are much longer. Mikupad is a notebook-shaped client with a strong editing surface. ChatUI and Web Ollama sit closest to hollama in ambition.

What separates hollama is the export path. The README lists import and export of stored data as a first-class feature, and with browser storage as the only store, that export is the entire backup strategy. For a user who has been running a local model and accumulating transcripts, an app whose backup is a file you can read is meaningfully different from one whose backup requires understanding the server.

The project has 1,189 stars, 96 forks and 62 open issues, is MIT licensed, and was pushed on 2026-10-05. Sixty-two open issues against 96 forks suggests an active user base filing real reports, which matches the shape of the 0.36.0 fixes: session sync, external link handling and reasoning display are complaints from people actually using it daily rather than feature requests from people evaluating it.

If you are choosing, the deciding question is where your chats should live and who should be able to reach the model server. Hollama answers that with browser storage plus an optional local proxy, and it is honest enough about the second part that you can make the call before installing anything.

Editorial conclusion

hollama is a good fit when you want a chat client with no account, no server side database and an export button you actually trust, especially against a local Ollama instance. The interesting engineering is in the adapters rather than the chat UI: the same SvelteKit codebase builds for Cloudflare, for Node behind Docker, and for Electron, and the choice of adapter is what decides whether your traffic touches a server. Two practical caveats to carry forward. Desktop releases lagged a year behind the Docker line, so check which channel a fix actually shipped in. And the Dockerfile functions as a proxy so the browser can reach Ollama without cross origin failures, which means a self hosted hollama does hold server side state worth reading SELF_HOSTING.md for before you expose it.

Frequently asked questions

Official sources

1. fmaclen/hollama on GitHub
2. License: MIT
3. Project website
4. README
5. Releases