Eclaire: A Self-Hosted AI Assistant That Reads Your Own Files
Local-first, open-source AI assistant for your data. Unify tasks, notes, docs, photos, and bookmarks. Private, self-hosted, and extensible via APIs.
At a glance
- What is it?
- Eclaire is an MIT-licensed, TypeScript-based personal AI that unifies tasks, notes, documents, photos and bookmarks behind local models. It is pre-release software with an explicit warning against direct internet exposure, so the decision is less about features and more about whether you can operate it safely.
- Who is it for?
- Adopt Eclaire if you already run local inference and want a single searchable index over your own notes, bookmarks and documents, and you accept pre-release churn plus the README's instruction not to expose it to the public internet. Do not adopt it if you need a stable API contract, multi-tenant access control, or a hosted service you never administer.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 125 days ago.
- 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 Gap Eclaire Fills Between Model Runners and Personal Data
Running a local model is a solved problem. Ollama, LM Studio and llama.cpp all serve an OpenAI-compatible endpoint, and the README lists those among Eclaire's supported backends. What none of them give you is an index of your own material with the model wired into it. Eclaire's stated purpose is to assemble existing building blocks into a complete product rather than another library, and the README is explicit that few projects deliver something a user can actually get things done with.
The target user is narrow and identifiable. You keep notes, bookmarks, PDFs, scanned images and task lists, you would rather not hand that corpus to a hosted assistant, and you are willing to run a container and a model server yourself. The sample use cases make the shape concrete: dictate a note from an Apple Watch, save a bookmark for later and have Eclaire generate a readable version plus a PDF, OCR text out of a photo, or ask the assistant to summarize across everything. Each of those is a data-ingestion problem with an AI step attached, not a chat problem.
How the Pieces Fit: Assets, Workers and an OpenAI-Compatible Surface
According to the README, Eclaire treats every item you put in it as an asset, and the asset types are tasks, notes, documents, photos and bookmarks. Organization metadata (tags, pin, flag, due dates) applies across all of them, which is what makes cross-type queries possible at all. All assets, whether uploaded or generated, live in Postgres or in file and object storage.
Processing is asynchronous. The v0.6.0 notes describe a database queue mode that uses Postgres or SQLite for job processing with no external dependencies, with Redis as the alternative. Workers pick up jobs, and the outputs are derived artifacts: a bookmark becomes a PDF, a readable HTML version and an LLM-friendly text version; a photo or document image goes through OCR; a document becomes an LLM-friendly Markdown version. Special handling exists for GitHub and Reddit APIs and metadata, which suggests the generic fetch path is not always good enough for those two sources.
The assistant layer sits on top with tool calling. The README lists tools for searching data, opening content, resolving tasks, adding comments and creating notes, and answers cite their sources. Streaming and thinking tokens are supported. The external surface is a REST API described as OpenAI-compatible, authenticated with session tokens or API keys. Channels currently include a web UI, an installable PWA, and Telegram, with the README saying more channels are coming.
Installation: One Command, Then a Container and a Model Backend
The v0.6.0 release introduced a one-command setup.sh flow and a streamlined compose.yaml, and unified deployment so that frontend, backend and workers can run in a single container. The README points to the installation section for the details rather than reproducing the full sequence, so treat the following as the shape of the process rather than a transcript: clone the repository, run setup.sh, then bring the stack up with Docker Compose against the provided compose.yaml.
Two configuration axes matter more than anything else. The first is storage: SQLite is supported alongside Postgres, and the README frames SQLite as the option for simpler workloads. The second is the job queue, which can be the database itself (Postgres or SQLite) or Redis. Choosing SQLite plus database queue mode gives you a deployment with no external service dependencies, which is the configuration that matches the local-first pitch most closely. The trade-off is not spelled out in the README, and you should assume a single-writer database behaves differently under concurrent ingestion than Postgres does.
Model selection is not a config key you can guess. The README dedicates a section to it and lists llama.cpp, vLLM, mlx-lm and mlx-vlm, LM Studio and Ollama as backends reachable through the standard OpenAI-compatible API, with text and vision models from Qwen, Gemma, DeepSeek, Mistral and Kimi among the supported families. v0.6.0 added vision models including Qwen3-VL, a llama.cpp router, and improved MLX support. Hardware acceleration is claimed for Apple MLX and NVIDIA CUDA. Because OCR and image understanding are part of the feature set, a text-only model will leave part of the pipeline unusable, so pick a vision-capable model if you care about photos and scans.
The Security Posture Is the First Real Constraint
The README carries a warning in capitals: do not expose Eclaire directly to the public internet, because it is not hardened for direct exposure. It recommends Tailscale or another private network, Cloudflare Tunnels, or a reverse proxy with authentication in front of it. That is an unusually blunt statement for a project README, and it should be read as a statement about the current state of the code rather than a suggestion about deployment taste.
This has practical consequences. The OpenAI-compatible API with API keys is convenient for automation, but the same API is what makes public exposure dangerous, and the project does not claim to solve that. If your intended workflow requires reaching Eclaire from an untrusted network without a VPN or an authenticating proxy, this is the wrong tool right now. The PWA and the Telegram integration both point outward, so think about what those channels imply for your threat model before enabling them.
The second constraint is maturity. The README labels Eclaire pre-release and under active development, warns of frequent updates, breaking changes and evolving APIs and configuration, and asks deployers to back up data regularly and read release notes before upgrading. The release history is consistent with that: v0.6.1 in January 2026, v0.6.2 in February, v0.6.3 in March, and a push to main in May. Three releases in roughly three months is a normal cadence for a project at this stage, and it also means your configuration can move under you.
Where Eclaire Is the Wrong Choice
Eclaire assumes one operator and one data owner. There is no mention of teams, roles, sharing or per-user isolation in the material, and the security warning reinforces that the access model is perimeter-based: you are inside the network or you are not. If you need a shared knowledge base with differentiated permissions, Eclaire does not describe one.
It also assumes you want the whole stack. The unified container made deployment simpler, but Eclaire is still a web application, a worker system, a database and a model server. If your actual need is retrieval over a folder of Markdown files from a script, you are paying for a UI, a queue and an asset model you will not use. The database queue mode removes Redis from the dependency list, not the application itself.
Finally, the pre-release status is a real constraint, not a formality. Breaking changes are announced as expected, and the API is described as evolving. Anything you build against the REST API should be treated as version-coupled until the project declares stability. The README does not state when that will happen.
Compared With a Retrieval Framework Like LlamaIndex
The closest conceptual alternative is a retrieval framework such as LlamaIndex, and the difference is where the work sits. LlamaIndex gives you loaders, indexes and query engines as a library: you write the ingestion code, you choose the vector store, you build the interface, and you own the deployment. Eclaire inverts that. It ships the asset model, the worker queue, the OCR and document conversion steps, the web UI, the PWA and the Telegram channel, and exposes an API on top.
If you already have a pipeline and want to control every stage, a framework is the better fit, because Eclaire's opinionated asset types (tasks, notes, documents, photos, bookmarks) and its storage decisions (Postgres or SQLite, plus file or object storage) are not things you can easily swap out. If you have no pipeline and want a working product this week, the framework route means writing the parts Eclaire already wrote.
The honest reading is that these are complements more than substitutes. Eclaire's value is the integration work, and its cost is that you inherit someone else's data model and release cadence. A team with an existing retrieval stack gains little from adopting it; an individual with a folder of PDFs and a bookmark habit gains a lot.
Maintenance Cost, Licence and What to Check Before You Commit
The licence is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. This is not legal advice, and the practical implication is narrow: the MIT grant covers the code in the repository, not the models you point it at. Model weights carry their own licences from Qwen, Gemma, DeepSeek, Mistral and the rest, and those terms are yours to check separately. Running inference locally does not change which licence applies to the weights.
Ongoing cost is operational. You maintain a container, a database, a backup routine, and a model server, and you read release notes before upgrading because breaking changes are expected. The README's own advice to back up regularly is the maintenance plan. Two configuration decisions determine how much of that cost you carry: SQLite with database queue mode minimizes moving parts, while Postgres plus Redis gives you the concurrency behaviour a single-file database will not.
What to verify first, concretely: confirm your model backend answers on an OpenAI-compatible endpoint and supports vision if you plan to use OCR or photo analysis; confirm that a backup of your chosen store actually restores, since the README treats backups as the safety net for breaking changes; and confirm your access path is Tailscale, a Cloudflare Tunnel or an authenticating reverse proxy before you point a browser at it. The project's own documentation at eclaire.co/docs is the place to check the current setup.sh and compose.yaml, because those changed in v0.6.0 and this review cannot confirm their present contents beyond what the README states.
Editorial conclusion
Adopt Eclaire if you already run local inference and want a single searchable index over your own notes, bookmarks and documents, and you accept pre-release churn plus the README's instruction not to expose it to the public internet. Do not adopt it if you need a stable API contract, multi-tenant access control, or a hosted service you never administer. Before committing, verify three things in your own environment: that your model backend is reachable over an OpenAI-compatible endpoint, that the database and queue mode you pick (SQLite or Postgres) survives a restore from backup, and that your access path is a VPN or authenticated reverse proxy rather than a public port.
Community notes