How to Self-Host Meilisearch in 2026: Master Keys, Indexes and Dumps

Self-hosting Meilisearch becomes interesting at the first redeploy, not the first docker run. If MEILI_ENV stays development or the data volume is lost during a redeploy, Docker can still report a perfectly healthy process. The deployment below is organized around observable behavior: create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records.

The intended job of Meilisearch is explicit: typo-tolerant full-text search with a fast HTTP API. That description tells us what must stay public, what should remain private and what a backup has to reconstruct.

Map Meilisearch before touching Docker

Separate four concerns for Meilisearch: ingress, the listener on 7700, durable state and supporting services or local capacity. The local runtime requirement is disk sized for indexes plus headroom for rebuilds and dumps. Keep its lifecycle explicit so moving Meilisearch between hosts does not silently change behavior.

Run the known-good transaction — create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records — before calling that separation complete. Measure batch indexing memory, temporary disk during index builds, document count and concurrent search traffic and keep the result with the deployment record. It provides both an acceptance criterion and the first capacity baseline.

Make Meilisearch startup reproducible

Use a command that exposes every important choice. This baseline binds Meilisearch to host loopback, adds the known data mounts and supplies the first required setting. Confirm the local requirement before exposure: disk sized for indexes plus headroom for rebuilds and dumps.

docker run -d \
  --name meilisearch \
  --restart unless-stopped \
  -p 127.0.0.1:7700:7700 \
  -v meilisearch-data:/meili_data \
  -e MEILI_MASTER_KEY=replace-with-a-long-random-value \
  getmeili/meilisearch:latest

Replace floating tags with a tested version or digest. After startup, inspect docker logs --tail 200 meilisearch and confirm the process listens on 7700. Then execute the Meilisearch acceptance action; a root-page response cannot prove the full scenario succeeds: create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records.

Give Meilisearch one canonical address

Treat the external Meilisearch URL as configuration that survives redeploys. First serve the HTTP API through one authenticated HTTPS origin; then route the hostname to port 7700 with the original host and scheme intact.

The deployment reachability checklist can prove that requests enter the container. After that point, the known failure — MEILI_ENV stays development or the data volume is lost during a redeploy — should be investigated in Meilisearch, its state or its workload rather than in certificate automation.

Restore Meilisearch on an empty host

The durable recovery set is scheduled dumps or snapshots plus the persistent data directory. Mount /meili_data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. A volume protects data from container replacement, but not from host loss, accidental deletion or application-level corruption.

Take backups that understand the data source: use logical dumps for live databases when required and copy files only from a consistent state. Keep one encrypted copy away from the Meilisearch host. The acceptance criterion for a restore is specific — a dump imports into a clean server with the same settings, document count and representative ranking. The restore-tested backup guide explains why job success alone is insufficient.

Protect the valuable part of Meilisearch

Do not inherit security assumptions from a local tutorial. Meilisearch's specific concern is starting production without a master key. Production should therefore reserve the master key for administration and give browser search clients restricted search keys.

Treat MEILI_MASTER_KEY according to its Meilisearch role: keep sensitive values out of Git, document rotation effects and never substitute a public example in production. Scope filesystem and network access, protect setup endpoints and define upload, request or execution limits around batch indexing memory, temporary disk during index builds, document count and concurrent search traffic.

Watch the workload, not only the container

Capacity tests should exercise batch indexing memory, temporary disk during index builds, document count and concurrent search traffic, not a repeated request to /. Run the scenario “create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records” at realistic concurrency and record latency, error rate and storage growth.

Upgrade planning must account for this risk: Meilisearch dump compatibility and index rebuild requirements must be checked before changing versions. Test the new release with representative input, then repeat the acceptance transaction and compare its result. If MEILI_ENV stays development or the data volume is lost during a redeploy, capture the failing transaction and inspect the first boundary involved instead of assuming ingress is responsible.

Turn the Meilisearch smoke test into a release check

For Meilisearch, define a known-good transaction before launch: create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records. Put its prerequisites, expected response and cleanup steps in version control without secret values. Pin the image used to establish that reference.

Use the transaction to validate a replacement and an independent restore. The restored service is acceptable only when a dump imports into a clean server with the same settings, document count and representative ranking. At the same time, observe batch indexing memory, temporary disk during index builds, document count and concurrent search traffic and turn the slowest or most constrained part into a service-level alert.

The gate also needs a negative case: submit harmless input near the resource or format limit associated with this boundary: MEILI_ENV stays development or the data volume is lost during a redeploy. Confirm that Meilisearch produces an actionable error while preserving data, restore the valid condition and repeat the known-good transaction. Keeping both results prevents a superficial health endpoint from becoming the only production evidence.

Keep Meilisearch explicit while Dockup handles routing

Dockup's one-click Meilisearch deployment should make replacement safe: the route continues to target 7700, secrets are not baked into the image and persistent paths return on the new container. The same deployment can run on Dockup compute or an attached machine.

Complete the app-specific work by confirming the local requirement — disk sized for indexes plus headroom for rebuilds and dumps, applying the canonical public address and running this acceptance check: create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records. Add the restore result to the runbook before real users arrive.

Frequently asked questions

What does Meilisearch need for a production deployment?

Route the Meilisearch container on port 7700 through one HTTPS origin. The local runtime requirement is disk sized for indexes plus headroom for rebuilds and dumps. Do not call Meilisearch ready until you can create an index, import documents, configure filterable attributes and prove a typo-tolerant query and filter return the expected records.

Which Meilisearch data belongs in a backup?

Persist /meili_data and include scheduled dumps or snapshots plus the persistent data directory in the same recovery manifest. A clean Meilisearch restore passes only when a dump imports into a clean server with the same settings, document count and representative ranking.

Does Meilisearch require HTTPS behind a reverse proxy?

Use HTTPS for the public Meilisearch origin and keep port 7700 on the internal route. Apply the Meilisearch setting correctly: serve the HTTP API through one authenticated HTTPS origin. For Meilisearch, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Meilisearch upgrade be tested?

Restore current Meilisearch state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Meilisearch dump compatibility and index rebuild requirements must be checked before changing versions. Keep the previous Meilisearch image until its data-migration and rollback boundary are understood.