Thunderbolt: a self-hosted AI client from the Thunderbird project, still pre-1.0
AI You Control: Choose your models. Own your data. Eliminate vendor lock-in.
At a glance
- What is it?
- Thunderbolt is an MPL-2.0 TypeScript client for frontier, local and on-prem models, aimed at enterprises that want to deploy it themselves. The README is explicit that it is early, that it still depends on an authentication and search backend, and that you must supply your own model providers.
- Who is it for?
- Adopt Thunderbolt if you are an enterprise team that already runs Postgres and Kubernetes or Docker Compose, wants a cross-platform client rather than a CLI, and is prepared to point it at your own Ollama, llama.cpp or OpenAI-compatible endpoint. Do not adopt it if you need a stable API surface, a public hosted inference endpoint, or a fully offline install today, since the README states the app still depends on authentication and search services.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Thunderbolt targets: model choice and data residency in one client
Most desktop AI clients assume you will sign in to one vendor and send your prompts to that vendor's endpoint. Thunderbolt inverts that. The README frames the pitch as choosing your models, owning your data, and eliminating vendor lock-in, and the deployment story is on-premises rather than hosted. The stated audience is narrow and explicit: the project is targeting enterprise customers that want to deploy it on-prem, and it recommends self-hosting as a trial path. That is a different buyer from the individual developer who wants a chat window on their laptop. The relevant question for that buyer is whether the client can talk to a model that never leaves the corporate network. The README says Thunderbolt is compatible with frontier, local and on-prem models, and it names Ollama and llama.cpp as the recommended route to free local inference, with API keys for any OpenAI-compatible provider as the alternative. There is no public inference endpoint, so the model layer is entirely yours to supply. For a regulated team, that is the whole point. For anyone expecting a working assistant straight after install, it is the first obstacle.
What the repository layout tells you about the architecture
Three facts are visible without reading the architecture docs. The primary language is TypeScript, the frontend is Vite-based (the docs list a Vite bundle analyzer under dev tooling), and the desktop shell is Tauri, since the repository documents Tauri signing keys for releases. The dev commands confirm a two-process split: make run starts the backend on port 8000 and the frontend on port 1420. The backend is not optional in the default configuration. make up starts Postgres and PowerSync in Docker, which points to Postgres as the primary store and PowerSync as the sync layer between server and client. That combination explains why the README warns that authentication and search currently require a backend even though fully offline-first is the eventual goal. Search is the one piece you can turn off, from the integrations screen in the app. Authentication is not described as optional. The client also targets web, iOS, Android, Mac, Linux and Windows, which is a wider platform matrix than most self-hosted tools attempt, and it is the reason the Tauri and PowerSync choices matter: the same sync and auth path has to serve a browser tab and a native shell. The README does not describe the agent execution model beyond the ai-agents topic tag, so how tool calls are sandboxed cannot be confirmed from the supplied material.
Getting a local instance running: the four make targets
The README gives a four-step path and nothing more. make doctor verifies your tools and prints exact install commands for anything missing, which is a better first step than a prose prerequisites list because it fails loudly instead of halfway through a build. make setup installs frontend and backend dependencies and wires up agent symlinks. make up starts Postgres and PowerSync in Docker. make run starts the backend on :8000 and the frontend on :1420. After that you still need an account: the README says you can deploy your own backend with Docker and sign up in order to test it locally, with deploy/README.md covering Docker Compose and Kubernetes for self-hosting. Model configuration happens in the app's settings, where you add an OpenAI-compatible provider or point at a local Ollama or llama.cpp instance. The one config decision the README calls out by name is search, which can be disabled on the integrations screen. Beyond that, the supplied material does not list environment variables, config file keys or a sample compose file, so anyone planning a deployment should read deploy/README.md rather than infer settings from the README. The homepage at thunderbolt.io is listed but its contents are not part of this material.
The caveats the maintainers put in the README are the important part
The project states plainly that it is early and under active development, that it is currently undergoing a security audit, and that it is preparing for enterprise production readiness. Those three clauses should govern any adoption decision. A security audit in progress means the threat model is not yet settled, and for a client that holds API keys for model providers and syncs conversation data through Postgres and PowerSync, the key-handling path is exactly what an audit would examine. The second caveat is architectural: offline-first is a plan, not a property. Today the app depends on authentication and search, and only search can be disabled. A team with an air-gapped network cannot run the default configuration, because there is no documented offline auth path in this material. The third is that you supply inference. There is no public endpoint, so a pilot requires either local hardware sized for the models you intend to run, or API keys and the data-egress review that comes with them. None of these are hidden. They are in an important callout near the top of the README, which is a more honest placement than a footnote.
Where a plain OpenAI-compatible chat UI is the better fit
The obvious alternative is not another self-hosted platform but the simplest thing that works: a chat client pointed directly at an OpenAI-compatible endpoint, whether that endpoint is a vendor API or a local Ollama server. Ollama already exposes an OpenAI-compatible API, and llama.cpp ships a server mode, so a thin client can reach local models without Postgres, PowerSync, an auth service or a Tauri build pipeline. The difference in approach is where state lives. Thunderbolt puts conversation state behind a synced backend so the same account works across web, iOS, Android and desktop, and pays for that with a database, a sync service and an authentication dependency. A direct client keeps everything on the device and pays for it with no cross-device continuity and no central place to enforce policy. For a single engineer running a local model, the direct client wins on setup time by a wide margin. For an organisation that needs to provision access, revoke it, and keep a consistent experience across operating systems, the backend is the feature rather than the tax. The choice is really about whether you need multi-device identity, and the README's own framing (enterprise, on-prem) says Thunderbolt is betting you do.
Maintenance cost, release cadence and what MPL-2.0 means here
The release list shows v0.1.130 on 2026-09-10 alongside nightly builds from the two preceding days, so the project ships continuously and the version number is still in the 0.1 range. Nightly tags mean the changelog between a nightly and a stable release is small but the surface area is moving, and anyone self-hosting should expect to track releases rather than pin once and forget. The stack you are maintaining is not trivial: Postgres, PowerSync, a TypeScript backend, a Vite frontend and Tauri shells for multiple platforms, plus whatever model runtime you choose. That is a real operational load, and the README's enterprise framing suggests the project expects you to have the staff for it. On licensing, Thunderbolt is under the Mozilla Public License 2.0, a file-level copyleft licence. Modifications to MPL-covered files must be made available under the same licence when you distribute them, while larger works that combine MPL files with separately licensed code can be distributed under other terms. Internal on-prem deployment without distribution generally does not trigger those obligations, but the boundary depends on your facts. This is a description of the licence text, not legal advice, and any organisation embedding Thunderbolt in a product it ships should have counsel read the LICENSE file.
Who should wait, and what to check before you commit
The clearest signal against adopting now is the combination of an in-progress security audit and a 0.1 version number. A team that needs a signed-off client for regulated data should wait for the audit to close and for the offline-first work to land, because the current authentication dependency is the constraint that matters most in a restricted network. A team that just wants a local chat window should skip it entirely and run Ollama with a minimal client. The middle case, an engineering organisation with existing Kubernetes capacity that wants one client across platforms and is comfortable running pre-1.0 software against its own models, is the case the README is written for. If that is you, the verification order is concrete: run make doctor then make setup on a clean machine to see what the toolchain actually demands, stand up the backend from deploy/README.md, sign up against your own instance, disable search on the integrations screen, and confirm the client still functions. If it does not function without search, that tells you how far the offline-first goal still has to travel.
Editorial conclusion
Adopt Thunderbolt if you are an enterprise team that already runs Postgres and Kubernetes or Docker Compose, wants a cross-platform client rather than a CLI, and is prepared to point it at your own Ollama, llama.cpp or OpenAI-compatible endpoint. Do not adopt it if you need a stable API surface, a public hosted inference endpoint, or a fully offline install today, since the README states the app still depends on authentication and search services. Before committing, run make doctor and make setup on a clean machine, then deploy the backend from deploy/README.md and confirm that disabling search on the integrations screen leaves the client usable in your network.
Community notes