Stork

Last reviewed Sep 13, 2026 · 764 words

Stork still works, still builds a search index in a second and still serves instant results from a static host, but the author announced the end of active development and the repository is archived, so it should not be the search you choose for a new site in 2026. That is the fact to lead with. For an existing site that already uses it, there is no emergency: it is a Rust CLI plus a WebAssembly blob and a few kilobytes of JavaScript, it has no server to patch, and browsers will keep running that WASM for years. For a new site, the same no-backend idea now has better-maintained implementations, which I get to below.

How the trick works

Stork (Apache-2.0, Rust, 2,761 stars, first released 2019) has two halves. A command-line indexer reads your content, described in a small TOML file, and writes a single binary index file, conventionally index.st. A JavaScript loader fetches that file and the WASM search engine in the browser and answers queries locally with typo tolerance, stemming and highlighted excerpts. Nothing runs on the server except a file host, which is why it shows up next to Algolia in the catalogue's Algolia alternatives list: the pitch was Algolia-like instant search at zero hosting cost and zero data leaving your site.

The config is short:

[input]
base_directory = "public"
files = [
  {path = "docs/install.html", url = "/docs/install/", title = "Installation"},
  {path = "docs/config.html", url = "/docs/config/", title = "Configuration"},
]

[output]
filename = "index.st"

Then stork build --input stork.toml produces the index, and the page needs a text input, an output container and a stork.register("docs", "/index.st") call after loading the script. Adding it to a Hugo, Jekyll or Eleventy build is one extra step in the deploy pipeline, and the 64 MB RAM figure in the catalogue is really "the RAM your CI runner already has".

The limit is the index download, not the search

Every visitor downloads the whole index before their first keystroke. For a documentation site of 100 to 300 pages that is a few hundred kilobytes and imperceptible. For 2,000 pages it is several megabytes on every page load, which is the point where a client-side index stops being polite. The catalogue's "best for smaller sites" note is exactly this. The other operational wrinkle is that the index is rebuilt by hand or by your CI, so search can go stale if you forget the step; the fix is putting stork build in the same job that runs your static generator.

Self-host the JS and WASM files too. The project's documentation showed loading them from its own CDN, and a static site should not depend on a third-party domain for its search to function, least of all one whose maintainer has moved on. Copy stork.js and stork.wasm from a release into your own assets directory and reference those.

What to run instead on a new site

For the same no-backend model, Pagefind is the current default choice: it indexes the built HTML output rather than needing a hand-written file list, splits the index into chunks so a visitor downloads only what a query touches, and scales to far larger sites than Stork comfortably could. It is not in our catalogue yet, but it is what I would reach for first. tinysearch is a Rust-and-WASM cousin with a tiny footprint and a narrower feature set. If the site has thousands of pages or needs facets, filters and typo tolerance across large fields, move to a real search server: Meilisearch or Typesense both index a static site's content in minutes and run happily on 512 MB. The search category has the full list, and the Elasticsearch vs Meilisearch comparison covers when the heavier engine is warranted.

What I'd do

If Stork is already wired into a site and the index is under a megabyte, leave it alone, vendor the JS and WASM files so nothing external can break it, and keep the build step in CI. Do not start a new project on it. For a new documentation or blog site I would adopt Pagefind at build time and never think about search infrastructure again; for anything with a large or fast-changing corpus I would run Meilisearch behind Caddy and index from the same pipeline that deploys the site. Stork proved the model was viable; its successors are the ones to bet on.