# Thunderbolt by Thunderbird: a self-hosted AI client you can point at your own models

> Thunderbird's Thunderbolt is an open-source, cross-platform AI client aimed at on-prem deployment, with no public inference endpoint of its own. Here is what the repository actually provides, how to get it running locally, and where it still falls short.

**thunderbird/thunderbolt** — AI You Control: Choose your models. Own your data. Eliminate vendor lock-in.

- Repository: https://github.com/thunderbird/thunderbolt
- Website: https://thunderbolt.io
- Stars: 4,773 · Forks: 328
- Language: TypeScript
- License: MPL-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/thunderbird-thunderbolt

## What Thunderbird's Thunderbolt is actually for

Thunderbolt is an open-source, cross-platform AI client that the README describes as deployable on-prem anywhere. The stated audience is enterprise customers who want to run it inside their own infrastructure, and the project tagline is about choosing your models, owning your data and avoiding vendor lock-in. It is not an inference service. The README is explicit that there is no public inference endpoint, so every model you talk to is one you supply: a local runtime such as Ollama or llama.cpp, or an API key for any OpenAI-compatible provider entered in the settings screen. That single constraint defines the product. If you were looking for a hosted assistant, this is the wrong repository. If you were looking for a client shell that keeps the model choice and the data path under your control, this is the shape of it. The README also notes the project is early and under active development, is undergoing a security audit, and is preparing for enterprise production readiness, so the intended deployment target is ahead of the current state.

## Architecture: Tauri shell, Vite frontend, Bun backend, PowerSync

The repository layout tells you more than the README does. There is a src-tauri/ directory, which is where the Tauri desktop and mobile shell lives, and a Vite frontend under src/ with a web/ directory alongside it. The backend is a separate Bun application in backend/, and the Makefile starts Postgres plus PowerSync in Docker before running the backend on port 8000 and the frontend on port 1420. PowerSync appears again as its own top-level directory, powersync-service/, which is consistent with a client that syncs state through a local database rather than holding everything in memory. There is a cli/ directory and a crates/ directory, so parts of the toolchain are Rust. The .env.example exposes VITE_THUNDERBOLT_CLOUD_URL, which defaults to http://localhost:8000/v1, and a VITE_IROH_RELAY_URL that routes an ACP/MCP bridge transport through a relay; unset, it uses the n0 public relays. That bridge is how the client talks to agent tooling, and the fact that it is a build-time Vite variable means changing the relay requires a rebuild, not a runtime toggle. The CLI bridge reads the same setting from THUNDERBOLT_IROH_RELAY_URL at runtime instead.

## Installing Thunderbolt locally with make doctor, setup, up and run

The README gives a four-command local path, and the Makefile confirms each target exists. Start with the doctor target, which the Makefile help text describes as verifying dev tools, env files and mobile SDKs and printing exact install commands for anything missing. Then setup installs frontend and backend dependencies and wires up agent symlinks. The up target starts Postgres and PowerSync in Docker; the Makefile auto-detects podman-compose and falls back to docker compose, and isolates volumes per clone through COMPOSE_PROJECT_NAME so two working trees do not share Postgres data.

```bash
make doctor    # verify your tools — prints exact install commands for anything missing
make setup     # install frontend + backend dependencies, wire up agent symlinks
make up        # start Postgres + PowerSync in Docker
make run       # start the backend (:8000) and frontend (:1420)
```

After make run, the frontend is served on port 1420 and the backend on port 8000. You still need a model provider. The README recommends Ollama or llama.cpp for free local inference, or an OpenAI-compatible API key added in settings. For self-hosting rather than development, the README points at deploy/README.md for Docker Compose or Kubernetes, and at docs/development/quick-start.md for the full dev environment. The .env.example also shows VITE_AUTH_MODE set to sso for enterprise OIDC or SAML, and VITE_AUTH_ENABLE_ANONYMOUS, which must be mirrored by AUTH_ALLOW_ANONYMOUS=true on the backend and is mutually exclusive with SSO.

## The offline-first claim has an asterisk

The README says the project eventually plans to be fully offline-first, and then states plainly that it currently depends on authentication and search functionality. Search can be disabled on the integrations screen in the app, but authentication cannot be removed the same way: you can deploy your own backend with Docker and sign up against it, which keeps the traffic on your hardware but still means a backend is in the loop. Anyone evaluating Thunderbolt for an air-gapped network should treat that as a blocking question rather than a configuration detail. There is a second gap that matters for procurement. The README says there is no public inference endpoint and that you add your own providers, so the quality of the assistant is entirely a function of the models you attach. A team expecting a turnkey product will spend its first week on Ollama or a provider key before it sees anything useful. The third caveat is timing: the README describes the project as still early, under active development and undergoing a security audit. The last push to the repository was on 2026-09-10, and release v0.1.130 was tagged the same day, so the code is moving, but a security audit in progress is not the same as a completed one.

## How Thunderbolt differs from LibreChat and Open WebUI

The obvious comparison is with self-hosted chat frontends such as LibreChat or Open WebUI. Those are web applications you run in a browser, and they typically assume a server you reach over HTTP. Thunderbolt ships a Tauri shell, so the same codebase targets web, iOS, Android, macOS, Linux and Windows, and the README lists all six. That is a real architectural difference: a native shell can hold local state, signing keys and platform integrations that a browser tab cannot, and the repository includes docs/features/tauri-signing-keys.md for release signing. The trade-off runs the other way too. A browser-based frontend is trivial to put behind an existing reverse proxy and identity provider, while Thunderbolt carries a Bun backend, Postgres and PowerSync, which is a heavier footprint for a small team. The other differentiator is the ACP/MCP bridge and the iroh relay configuration in .env.example, which points at agent tooling rather than plain chat. If your need is a chat UI over an API key, Thunderbolt is more machinery than you need. If your need is a client that can run agent workflows against models you host, the extra pieces are the point.

## Licence, telemetry and the cost of keeping up

Thunderbolt is licensed under MPL-2.0, a file-level copyleft licence, and the repository carries both LICENSE and a separate TELEMETRY.md describing data collection and the privacy policy. MPL-2.0 is not the GPL: modifications to existing files stay under the same licence, but you can combine the code with differently licensed files in a larger work. That is a general description of the licence family, not legal advice, and any deployment that embeds Thunderbolt in a commercial product should have counsel read LICENSE and TELEMETRY.md together, because the second file governs what leaves the machine. On upgrade cost, the release cadence is the thing to plan around. The recent releases include v0.1.130 on 2026-09-10 plus nightly builds such as v0.1.129-nightly.20260910 and v0.1.129-nightly.20260909, so the project publishes both tagged and nightly artifacts. A pinned deployment tracking only tagged releases will fall behind the nightly line, and the README warns the project is early and under active development, which in practice means configuration keys and environment variables can move between versions. The Makefile's COMPOSE_PROJECT_NAME isolation helps here: separate clones keep separate Postgres volumes, so you can stand up a candidate version beside the one in use.

## Where to look before you commit

The documentation index in the README is the map. docs/architecture/README.md holds the system architecture and diagrams, deploy/README.md covers Docker Compose and Kubernetes, docs/development/quick-start.md covers setup and testing, and docs/faq.md answers common questions. There is also AGENTS.md and CLAUDE.md at the repository root, which is a signal about how the project expects contributors to work with coding agents. For a team deciding whether to adopt, the useful sequence is to read the architecture document first, then run make doctor on a target machine to see what the toolchain actually demands, then stand up the Docker Compose deployment from deploy/README.md rather than the development path. The development path starts Postgres and PowerSync through make up and runs the frontend from Vite, which is convenient but not the same as the deployment topology. Bugs and ideas go through the GitHub issue tracker, and security vulnerabilities have a separate reporting form that the README asks you not to bypass with a public issue.

## Conclusion

Adopt Thunderbolt if you want a Tauri-based desktop and mobile client whose model providers you choose and whose backend you can run yourself with Docker Compose or Kubernetes, and you accept that authentication and search still reach out to a backend. Do not adopt it yet if you need a fully offline client or a public inference endpoint, because the README states neither exists. Before committing, run make doctor and make setup on a clean machine, read deploy/README.md for the Compose and Kubernetes paths, and check TELEMETRY.md against your own data-handling rules.

## FAQ

### How do I install Thunderbolt for local use?

The README gives four commands: make doctor to verify your tools, make setup to install dependencies and wire up agent symlinks, make up to start Postgres and PowerSync in Docker, and make run to start the backend on port 8000 and the frontend on port 1420. For self-hosting rather than development, the README points at deploy/README.md for Docker Compose or Kubernetes.

### How do I use Thunderbolt with a model?

There is no public inference endpoint, so you add your own model providers. The README recommends Ollama or llama.cpp for free local inference, or you can enter an API key for any OpenAI-compatible provider in the settings.

### What does Thunderbolt mean in this project?

Here Thunderbolt is the name of an open-source, cross-platform AI client from the thunderbird organization, described in the README as deployable on-prem anywhere and aimed at enterprise customers who want to self-host it. It is unrelated to the hardware port of the same name.

## Sources

- [License: MPL-2.0](https://github.com/thunderbird/thunderbolt/blob/main/LICENSE)
- [Project website](https://thunderbolt.io)
- [README](https://github.com/thunderbird/thunderbolt/blob/main/README.md)
- [Releases](https://github.com/thunderbird/thunderbolt/releases)
- [thunderbird/thunderbolt on GitHub](https://github.com/thunderbird/thunderbolt)

---

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