Toshi

Last reviewed Sep 13, 2026 · 845 words

Toshi's own README calls it not production-ready, and the commit history has been quiet for years. That is the whole review for most readers: if you want a self-hosted full-text search box today, run Meilisearch or Typesense and move on. Toshi is still interesting for one specific person, the Rust developer who wants an Elasticsearch-shaped HTTP layer over Tantivy without writing it themselves, and this guide is mostly for them.

What Toshi actually is

Toshi is a thin server around Tantivy, the Rust search library that also sits underneath Quickwit. Tantivy does the hard parts: inverted indexes, BM25 scoring, segment merging, fast phrase and range queries. Toshi adds a JSON REST API that deliberately looks like Elasticsearch: you create an index by POSTing a schema, add documents by POSTing JSON, and query with a body that has query, limit and familiar clause names like term, fuzzy, range and bool. It stores indexes on local disk, runs as one binary, and idles comfortably inside the 256 MB the catalogue lists. MIT licensed, 4,256 stars, first released in 2018.

The API resemblance is cosmetic, not compatible. An Elasticsearch client library will not talk to it, Kibana will not talk to it, and there is no aggregation framework, no ingest pipelines, no ILM, no security layer. What you get is a search index with an HTTP door.

The feature gap is the real story

Set Toshi next to the two projects that won this category and the gap is wide. Meilisearch and Typesense both ship typo tolerance tuned for humans, faceting, filtering, multi-field ranking rules, synonyms, a web dashboard and official client libraries for every mainstream language. Toshi has none of the dashboard, none of the ranking-rule DSL, and its typo tolerance is whatever Tantivy's fuzzy term query gives you, which is Levenshtein distance on a single term rather than the query-wide forgiveness a search-as-you-type box needs.

Clustering was a stated goal and the repo contains the scaffolding for it, but I would treat Toshi as single-node. For a single node, Tantivy on modest hardware is fast: indexing millions of small documents in minutes and answering term queries in single-digit milliseconds is the normal experience with the underlying library, and Toshi does not add much overhead on top. Speed was never the problem.

Running it, if you insist

There is no official Docker Hub image I would point you at, so the honest path is building from source with a current Rust toolchain:

git clone https://github.com/toshi-search/Toshi.git
cd Toshi
cargo build --release
./target/release/toshi --config config/config.toml

The config file sets the listening host and port (8080 by default), the data path for index storage, and writer memory. Point a reverse proxy at it and, because there is no authentication at all, keep it off the public internet. Put it on a private network or behind an auth-aware proxy such as Caddy with basic auth, and treat every endpoint as writable by anyone who can reach it.

Expect friction from the age of the code. Rust crates move fast, Tantivy has had several breaking releases since Toshi's last active period, and building an old Cargo.lock against today's toolchain can mean chasing deprecations. Budget an afternoon, not ten minutes. The catalogue's Medium difficulty is generous for anyone who does not already write Rust.

Who should run Toshi anyway

Three legitimate cases. First, you maintain a Rust application, already depend on Tantivy in-process, and want to split search into its own service without adopting a whole new ecosystem; Toshi is a reference implementation you can fork, and the code is readable. Second, you are learning how search servers work and want something small enough to read end to end; Toshi's codebase is far more approachable than Elasticsearch's. Third, you need a scratch index for a script or an internal tool, do not care about polish, and prefer a 20 MB binary over a JVM.

If none of those describe you, the bigger projects are the safer pick by a wide margin. Quickwit, also on Tantivy, covers the log-search use case with a maintained team behind it. Meilisearch covers site search. Typesense covers both with a slightly more opinionated schema. The Elasticsearch vs Meilisearch comparison explains when you genuinely need the heavyweight, which is less often than people assume.

What I'd do

For a site or app search box, Meilisearch in Docker, 15 minutes of setup, done. For searching logs, Quickwit. For a Rust shop that wants Tantivy as a service, fork Toshi, update the Tantivy dependency, and own it as internal code rather than expecting upstream releases. I would not deploy Toshi as-is for anything a second person depends on, and I would not wait for it to mature; the search category has moved on, and the projects that moved it are the ones to run.