Meilisearch

Last reviewed Aug 26, 2026 · 953 words

Meilisearch with a 100,000-document index answers a search-as-you-type query in single-digit milliseconds on a 256 MB container, from one Rust binary that starts in about a second. That pitch is accurate. What the pitch skips are the two mistakes I see in almost every first deployment: the master key gets pasted into front-end code, where it is a root credential for the whole instance, and the index grows past what the box can memory-map, at which point query times go from 5 ms to 500 ms with no error. Both are 5-minute fixes if you make them before launch.

Production mode on, key set, port hidden

services:
  meilisearch:
    image: getmeili/meilisearch:latest
    ports:
      - "127.0.0.1:7700:7700"
    environment:
      - MEILI_MASTER_KEY=replace-with-32-random-bytes
      - MEILI_ENV=production
      - MEILI_NO_ANALYTICS=true
    volumes:
      - ./meili_data:/meili_data
    restart: unless-stopped

MEILI_ENV=production does two things: it refuses to start without a master key of at least 16 bytes, and it disables the built-in search preview page at the root URL, which is a development toy you do not want on the internet. Binding to 127.0.0.1 and fronting it with Caddy gives you TLS and a hostname. Replace latest with a pinned tag as soon as it works. Historically the on-disk format changed between versions and an upgrade meant creating a dump (POST /dumps) and importing it into the new binary; recent releases have made that smoother, but read the release notes before every jump rather than assuming.

Three keys, and the browser only ever sees one

On first start with a master key, Meilisearch generates two more: a Default Admin API Key and a Default Search API Key. List them with:

curl -H "Authorization: Bearer $MEILI_MASTER_KEY" http://127.0.0.1:7700/keys

The rules are simple. The master key creates and revokes other keys and nothing else should use it. The admin key indexes documents and changes settings, so it lives in your backend's environment. The search key can only run queries, and it is the only one that ever appears in JavaScript shipped to a browser. If different customers must only see their own documents, sign a tenant token (a short-lived JWT embedding a filter, generated from the search key) per user instead of handing out the raw key. Setting this up takes 10 minutes and saves you from the "our entire index was deletable from view-source" incident.

Index settings decide result quality, not clever queries

Push documents as a JSON array to POST /indexes/products/documents. The response is a task ID, not a result; indexing is asynchronous, and you poll GET /tasks/{uid} until it reads succeeded. Batch documents in the thousands per request rather than one HTTP call each, or you will spend more time on task overhead than on indexing.

Then set the four settings that matter, because the defaults index every field equally:

curl -X PATCH http://127.0.0.1:7700/indexes/products/settings \
  -H "Authorization: Bearer $ADMIN_KEY" -H 'Content-Type: application/json' \
  --data '{
    "searchableAttributes": ["title", "brand", "description"],
    "filterableAttributes": ["category", "price", "in_stock"],
    "sortableAttributes": ["price", "created_at"],
    "displayedAttributes": ["id", "title", "brand", "price", "image"]
  }'

Order in searchableAttributes is a ranking signal: a match in title beats a match in description. Nothing can be filtered or faceted until it is in filterableAttributes, which is the source of most "filter returns 400" tickets. displayedAttributes keeps internal fields out of responses. The default ranking rules (words, typo, proximity, attribute, sort, exactness) are right for 95% of sites; the typo tolerance defaults allow 1 typo in words of 5 characters or more and 2 typos from 9 characters, which is why "meilisaerch" still finds the right thing.

Memory is the ceiling, CPU is rarely the problem

The engine memory-maps its database with LMDB, so queries are fast while the working set fits in RAM and page cache. The on-disk index is typically several times the size of the raw JSON because of the inverted index and prefix structures, so a 500 MB dataset can become a 2 to 3 GB index. Plan RAM around the index size, not the document count. Indexing is the heavy phase: it will happily use every core and several GB, and MEILI_MAX_INDEXING_MEMORY plus MEILI_MAX_INDEXING_THREADS are the knobs that stop it from starving the containers next door. Once indexed, an idle instance sits at a fraction of that.

Where Elasticsearch still wins

Meilisearch does not do aggregations beyond facet counts, has no query DSL, does not cluster across nodes, and is not a log store. Hundreds of thousands to a few million product or article records is its home; hundreds of millions of events is not. Hybrid semantic search is built in through configurable embedders if you want vectors alongside keywords. The full split is in Elasticsearch vs Meilisearch; Typesense is the closest peer with a similar shape, and if you are escaping a per-query bill, the Algolia alternatives page ranks the candidates.

What I'd do

The compose file above with a pinned tag, master key from openssl rand -hex 32, search key in the front end and nothing else, admin key in the indexing job. Attributes configured on day one, documents pushed in batches of 5,000 from a nightly job plus incremental updates. Size the container at 2 to 3 times the index on disk and watch the number after the first full index. For a product catalogue, documentation site, or app search under a few million records, this is the fastest path to search that feels like Algolia on hardware that costs $5 a month.