Hister Indexed 117 of Our 129 Files and Never Told Us About the Other 12
Hister is a self-hosted search engine for the pages you visit and the files you keep, and it hit the Hacker News front page with 648 points. We pointed it at 129 of our own markdown files. It imported 117 and said nothing about the rest.
The WJS Desk
Sep 21, 2026 · 6 min read
Adam Tauber's Hister reached the Hacker News front page on 18 September 2026 with 648 points and 173 comments, under a description that is doing a lot of work: "a private search engine for the pages you visit and the files you keep".
We downloaded it and ran it against a corpus we know intimately: 129 markdown files from this repository.
The number that made us look
The GitHub API gave us 4,705 stars when we pulled it on 18 September, and 4,707 about twenty minutes later. The repository was created on 4 January 2026, so that is eight and a half months of accumulation rather than a two-week rocket.
A more interesting number sits in the release assets. The five v0.19.0 binaries, published on 3 September, have been downloaded 1,478 times between them. Release cadence is steady too: nine tagged releases from v0.11.0 on 30 March to v0.19.0 on 3 September.
What it actually is
70,447 lines of Go, plus a Svelte web UI, under AGPL-3.0. The Go module declares 38 direct dependencies and 88 indirect ones, with Bleve doing the full-text indexing and chromedp available for pages that need a real browser. There is an MCP server in server/mcp.go, so an AI assistant can query your index directly.
The quickstart is one command and it worked on the first try with no configuration file:
$ ./hister listen
INFO | Starting webserver Address=127.0.0.1:4433 Version="v0.19.0 (118a73a)"
$ hister import file /tmp/hister-corpus
✓ Imported 117 document(s)
$ hister search "deploying"
Eight seconds after launching, 127.0.0.1:4433 returned a 200. No database to provision, no config to write. For a tool in this category that is genuinely rare.
We pointed it at 129 of our own files
We copied every markdown file in this repository into a flat directory: 129 files, about 62,000 words. Then we imported them and ran the same queries through Hister and through the system grep.
The import took 5.6 seconds and printed ✓ Imported 117 document(s). We did not notice the gap until a search came back short.
| Test | Hister v0.19.0 | /usr/bin/grep -ril |
|---|---|---|
| Files ingested from 129 | 117 | 129, nothing to ingest |
| Files found for "deploying" | 4 | 2 |
| Files found for "pexels" | 2 | 6 |
| Disk cost | 103 MB binary, 2.7 MB index | 150 KB binary, no index |
The "deploying" row is the case for Hister. A literal grep -ril deploying finds 2 files. Hister finds 4, because it stems the query and matches "deploy" and "deployment" too. Those 4 are exactly the 4 non-hidden files that grep -ril deploy turns up. The index is doing real work.
The "pexels" row is the case against. Six of our files contain that word. Hister returned two. We re-ran it with -L 0 to rule out a result limit and got the same two.
The 12 missing files all share one property: their flattened names begin with a dot, because they came from .claude/skills/. Hister's importer has hidden-path rules and they are documented in the configuration guide. What is not documented is that the command prints a green tick and a count with no mention of what it declined to read. The four "pexels" files it missed were all dotfiles.
The hidden cost: Hister's silence about skipped files is the real risk, not the disk space. A personal search index you do not fully trust is worse than no index, because you stop double checking. If your corpus has dotted directories, and most developer corpora do, verify the count yourself with hister list-urls | wc -l against find . -type f | wc -l before you rely on it.
Search latency, once indexed, was 17 milliseconds on the first query and 10 milliseconds on every one after. The index cost 2.7 MB on disk for 644 KB of markdown, roughly four times the source.
The crawler never fetched a page, and we will not pin that on Hister
The other half of the product is indexing the web pages you visit. We could not get it to work. We handed hister index three URLs and all three failed at exactly the 10 second client timeout, while curl, Node's fetch, and Python's urllib fetched the same pages from the same machine in 0.6 to 1.5 seconds. Raising --client-timeout to 60 did not move the 10 second wall.
One detail argues against a simple network block: the debug log shows Hister successfully fetching and caching robots.txt from the same origin before the page request died. Something in our environment is interacting badly with the crawler's HTTP client, and we could not isolate it in the time we had. We are reporting it because it happened, not because we have proved it is a bug in Hister.
What it does not do
- Ship a small binary. 103 MB for the macOS arm64 build, which is what CGO, Bleve, and an embedded Svelte UI cost you.
- Tell you what it skipped. See above.
- Index hidden paths without configuration, which on a developer machine is most of the interesting configuration.
- Do semantic search out of the box. It is optional and requires you to point it at an embeddings endpoint, which means sending document text somewhere.
- Run without a server process. The CLI is a client, so the searches only work while
hister listenis up.
Who made it, and why that changes the risk
Adam Tauber has been on GitHub since August 2008 and his bio reads "Author of Hister, Searx, Colly and a bunch of smaller projects". Searx is the metasearch engine that spawned SearXNG. Colly is the Go scraping framework a large chunk of the ecosystem has used. His wuzz HTTP inspector sits at 10,735 stars.
That matters, because the bus factor here is one. Across 56 contributors, Tauber accounts for 1,628 of 2,087 recorded contributions, or 78%. The next largest is 184. Twenty-seven accounts other than bots have landed more than a single commit, which is a real community, but nobody is close to co-maintaining.
A one-person project from someone who has shipped and maintained two widely used tools for a decade is a different bet from a one-person project by a stranger.
70,447 lines is also too much to vendor and carry yourself if the project stalls. This is an adopt-and-hope dependency, not a copy-the-file dependency.
Verdict
Adopt today if you want full-text search over your own browsing history and local documents, you are comfortable running a background server, and you will spend ten minutes on the hidden-path configuration before trusting the results. The install is genuinely frictionless and the query language (field filters, negation, the new url_re: regex matcher in v0.19.0) goes well past what a grep can express.
Wait if your corpus is small enough that grep answers you instantly, which for 644 KB of markdown it does. Wait also if you need the web crawler as the primary feature, until you have tested it on your own network.
What would change our mind: an importer that prints "117 imported, 12 skipped by hidden-path rules" instead of a bare count. That is a one-line change and it converts the tool from something we verify into something we trust.
Your turn
If you already self-host a personal index, whether that is Hister, Recoll, or a pile of shell aliases, we want the number that decided it for you: how big did your corpus get before plain grep stopped being enough? Ours is still under a megabyte, which is why the honest answer in that table is that grep won three rows out of four.
The reason a private index is suddenly interesting is that the public one got worse. We wrote about that when Google replaced every search result link with an opaque redirect, and Hister reads like a direct answer to it.
