You deploy Meilisearch in ten minutes via Docker Compose. Search feels instant; the team is sold. Three weeks later, an accidental docker compose down -v or a full disk wipes the index — and nobody has a recent dump because "it's just a cache, right?"
No. Meilisearch is rebuildable — but only if you automated the rebuild. Otherwise you rediscover how long a full reindex takes in production, while users browse without relevant results.
Sound architecture: derived index, source elsewhere
| Layer | Role | Source of truth? |
|---|---|---|
| PostgreSQL / CMS | Product, article data | Yes |
| Meilisearch | Search index | No — derived |
| Application | Search API queries | No |
Treat Meilisearch as a disposable index with a documented rebuild pipeline — not a secondary database you "back up when you remember".
The golden rule: any data present only in Meilisearch is data you accept losing or rebuilding. Search metadata, configured synonyms, and ranking rules must be versioned (config files, infrastructure as code) as much as dumps.
Docker deploy with persistence
services:
meilisearch:
image: getmeili/meilisearch:v1.11
volumes:
- ./meili_data:/meili_data
environment:
MEILI_MASTER_KEY: "${MEILI_MASTER_KEY}"
MEILI_ENV: production
ports:
- "7700:7700"
Critical points:
- Named or bind volume — never ephemeral storage in production.
- Master key in secrets (environment variable, vault), not in the Git repo.
- Reverse proxy (nginx, Caddy) with TLS in front of port 7700.
- Firewall — do not expose 7700 publicly without authentication.
On a modest VPS, place meili_data on a volume separate from the OS to simplify snapshots and targeted restores.
Consistent backup and reindexing
Depending on your Meilisearch version, two mechanisms coexist:
Dumps export a portable index — useful for migration or cold backup. Schedule them via cron with rotation to object storage (restic, rclone to Scaleway, Wasabi, or Backblaze).
Snapshots (depending on edition) capture internal state faster — check your version documentation before relying on them alone.
Pragmatic strategy for an SME:
- Tested monthly
reindex-full.shfrom the database. - Nightly dump to an S3-compatible bucket with thirty-day retention.
- Disk alerts on the
meili_datavolume before the critical threshold.
Test restore, not just dump creation. A file on S3 never restored is only a promise.
Continuous vs batch indexing
Two models coexist depending on your business:
- Webhooks or events: index on each product mutation via a queue (Redis, RabbitMQ) to limit synchronous load.
- Nightly batch: full reindex if your model allows — simpler to reconcile and audit.
Ramp batch import size gradually; watch RAM and search latency during mass imports. Meilisearch handles atomic per-document updates, but a mass import consumes CPU and can degrade user experience.
The peak: a fast index without automated rebuild is debt
Final consistency is measured by comparing indexed document count to the source — not by checking that the container responds on port 7700.
Decide and move forward without blind spots
Before production go-live, block half a day for three concrete deliverables. Document the reindex pipeline (script, estimated duration, on-call contacts). Persist meili_data on SSD with disk monitoring and alert at 80%. Automate dumps to external object storage, then run a quarterly calendar restore test.
Pick a host where you can snapshot the volume or export easily — browse the directory to compare VPS and cloud with fast block storage. If Meilisearch shares the same server as the application, plan a maintenance window for full reindexes and communicate it to support.
Frequently asked questions
Does Meilisearch replace Elasticsearch for every project?
No. Meilisearch excels at typo-tolerant search on modest to medium catalogues. Complex aggregations, log analytics, or multi-terabyte scale remain Elasticsearch or OpenSearch territory.
How do I back up Meilisearch properly?
Use dump or snapshot on a persistent volume, or rebuild from the source of truth. Test restore, not just backup file creation.
Can I host Meilisearch on the same VPS as the app?
Yes for modest catalogues with 1–2 GB dedicated RAM and SSD. Watch indexing peaks and isolate the data directory.
What after a crash with no backup?
Run a full reindex from the database or CMS — hence the value of a documented, pre-tested script.
Meilisearch is fast to install and slow to regret — if rebuild is as fast as search.