Meilisearch: a Rust search engine API you can run yourself

What Meilisearch is for, and who ends up running it

Meilisearch is an HTTP server that stores documents and answers search queries. The README describes it as a search engine that fits into apps, websites and workflows, and lists the features that ship out of the box: hybrid search combining semantic and full-text matching, search-as-you-type, typo tolerance, filtering and faceted search, sorting, synonyms, geosearch and language support. The repository is a Rust workspace with a meilisearch crate for the server, a milli crate for the search core, and supporting crates for auth, the index scheduler, dumps and the HTTP routes.

The audience is narrower than the feature list suggests. If you are building a product search box, a documentation search, or an internal tool where users type partial words and expect something back immediately, this is the shape of tool you want. The README points at demos for movies, Flickr images, ecommerce, home booking, a CRM and a playground, which tells you the intended surface: user-facing search over a document corpus, not backend analytics.

What it is not: a database. It stores documents and indexes them, but the README does not present it as a system of record with transactions, joins or relational constraints. Teams that adopt it usually keep their primary data elsewhere and treat Meilisearch as a derived index that can be rebuilt from a dump.

How the server is put together: HTTP in, index scheduler out

The workspace layout is the clearest description of the architecture. The meilisearch crate builds the HTTP server. The routes crate holds the HTTP layer, and routes-macros generates route wiring. Requests are validated against meilisearch-types and authorized through meilisearch-auth, which is where the master API key and the fine-grained key permissions described in the README live. Multi-tenancy is handled through tenant tokens, also documented as a security feature.

Writes do not hit the index directly. The index-scheduler crate sits between the HTTP layer and milli, which is the search engine core. That separation is why the API can accept a task, return a task identifier, and let the caller poll for completion. The README does not spell out this flow; the crate names in Cargo.toml do. Filtering and query parsing are split into filter-parser and permissive-json-pointer, and document ingestion uses flatten-serde-json and json-depth-checker, which hints at how nested JSON documents are normalized and how deeply nested input is constrained.

Dumps are their own crate. That matters operationally: a dump is a portable representation of your data, and the README links to a demos repository rather than describing restore procedures. If your migration plan depends on dumps, read the documentation site, not the README.

Installing Meilisearch with Docker and indexing your first documents

The Dockerfile is the most concrete install path in the repository. It compiles with rust:1.89-alpine3.22, copies the meilisearch and meilitool binaries into an alpine:3.22 runtime image, symlinks /meilisearch for compatibility with pre v0.27.0 containers, sets the working directory to /meili_data, exposes 7700/tcp and starts the server through tini. Two environment variables are set in the image: MEILI_HTTP_ADDR to 0.0.0.0:7700 and MEILI_SERVER_PROVIDER to docker. The runtime image also installs libgcc, tini and curl, and the entrypoint runs tini before the server binary.

Those are the facts the Dockerfile fixes for you: the listening address, the port, and the directory that holds the data. Anything beyond that, including which image tag to pull, is not printed in the repository files, so confirm it against the project's published images before deploying.

The API itself is plain HTTP on that port. The README documents the server as exposing a RESTful API, and the documentation states that write operations are asynchronous, returning a task rather than the indexed document. That is the first behaviour to internalize: a successful write request does not mean the document is searchable yet, so your code needs to poll the task before querying.

Where Meilisearch stops being the right choice

The README's feature list is long, and it is worth reading the omissions. There is no mention of joins, transactions, or a query language beyond filtering and sorting. If your search requirements are really reporting requirements, with GROUP BY, multi-table aggregation, or ad hoc analytical queries over the same dataset, a search engine is the wrong layer and you will end up duplicating data into a warehouse anyway.

Asynchronous indexing is the second constraint. Because writes return tasks, your application needs to handle the gap between accepting a write and that write being queryable. Code that indexes a record and immediately searches for it will fail intermittently. The repository does not document a synchronous write path, and the index-scheduler design suggests there is not one.

Resource behaviour is the third. The workspace sets mimalloc as the global allocator and compiles the release profile with codegen-units = 1, and the Cargo.toml comments describe enabling debug assertions on the heed storage layer specifically to detect disk corruption. Those are engineering choices for a server that owns its data directory, not for an embedded library sharing memory with your application. If you wanted an in-process index, this is not it.

Finally, hybrid search depends on embeddings. The README lists vector search under experimental documentation and the workspace vendors async-openai in external-crates. The documentation, not the README, is where you should check the current state of that feature before designing around it.

Meilisearch compared with Elasticsearch and Typesense

The comparison people actually search for is Meilisearch versus Elasticsearch. The difference in approach is architectural. Elasticsearch is built around a distributed cluster with shards and replicas, and its query DSL covers aggregations, scripted scoring and a much wider surface of analytical operations. Meilisearch is a single HTTP server with an index scheduler and a task queue. The README does not claim cluster management; it claims search-as-you-type results in under 50 milliseconds, typo tolerance, facets and sorting.

That means the trade is operational simplicity against query expressiveness. You can run Meilisearch as one container with one volume, which is why the Dockerfile fits on a screen. You cannot express the same aggregation queries. If your team already runs Elasticsearch for logs, adding Meilisearch for product search means two systems, but the second one has a much smaller failure surface.

Typesense is the closer comparison in shape: also a single search server with an HTTP API and typo tolerance. The repository does not describe Typesense, so the honest statement is that the meaningful difference for your decision is not the feature checklist but the operational model each project documents. Read both sets of docs for backup, restore and upgrade before choosing; Meilisearch's own README is silent on rollback, and dumps are the mechanism the repository exposes through the dump crate.

Licence, releases and what an upgrade costs

The repository root contains LICENSE, LICENSE-MIT and LICENSE-EE. Cargo.toml declares license = "MIT" for the workspace package, and the README's badge row links to a LICENSE file. The presence of a separate LICENSE-EE file means the licensing picture is not a single identifier, and the repository files do not explain which parts fall under which terms. That is a question for your own legal review of those three files, not for a summary.

Upgrade cost is visible in the release cadence. The recent releases listed are v1.53.1, v1.53.0 and v1.52.3, and the workspace version in Cargo.toml is 1.53.2. Patch and minor releases arrive close together, so pinning a version and reading the release notes before moving is the practical posture. The repository provides a meilitool binary alongside the server, copied into the image at /bin/meilitool, which is the maintenance tool the project ships for operating on an existing data directory.

There is a download-latest.sh script at the repository root for non-container installs, and a config.toml file for server configuration. The README does not document rollback, so verify your restore path with dumps before upgrading a production index.

Editorial conclusion

Adopt Meilisearch when you want a self-hosted, single-binary search API with typo tolerance and hybrid search, and you can accept a document store that is not a general purpose database. Do not adopt it if you need SQL-style joins, deep aggregation, or a managed cluster you never touch. Before committing, verify the licence terms in LICENSE, LICENSE-MIT and LICENSE-EE for your use case, and confirm the current version number in Cargo.toml against the release you plan to deploy.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes