Comment auto-héberger Meilisearch en 2026 : clés master, index et dumps

L’auto-hébergement de Meilisearch devient vraiment intéressant lors du premier redeploy, et non lors du premier docker run. Si MEILI_ENV reste sur development ou si le volume de données est perdu lors d’un redeploy, Docker peut tout de même signaler un processus parfaitement sain. Le déploiement ci-dessous s’appuie sur des comportements observables : créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus.

Le rôle de Meilisearch est explicite : fournir une recherche full-text tolérante aux fautes de frappe via une API HTTP rapide. Cette description indique ce qui doit rester public, ce qui doit rester privé et ce qu’une sauvegarde doit pouvoir reconstruire.

Cartographier Meilisearch avant de toucher à Docker

Séparez quatre aspects de Meilisearch : l’ingress, le listener sur le port 7700, l’état durable et les services de support ou la capacité locale. Le besoin d’exécution local est un espace disque dimensionné pour les index, avec une marge suffisante pour les reconstructions et les dumps. Gardez son cycle de vie explicite afin que le déplacement de Meilisearch entre plusieurs hôtes ne modifie pas son comportement en silence.

Exécutez la transaction de référence — créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus — avant de considérer cette séparation comme terminée. Mesurez la mémoire utilisée lors de l’indexation par lots, l’espace disque temporaire pendant la construction des index, le nombre de documents et le trafic de recherche concurrent, puis conservez le résultat avec le dossier de déploiement. Vous disposez ainsi à la fois d’un critère d’acceptation et d’une première base de capacité.

Rendre le démarrage de Meilisearch reproductible

Utilisez une commande qui expose chaque choix important. Cette configuration de référence lie Meilisearch à la loopback de l’hôte, ajoute les montages de données connus et fournit le premier paramètre requis. Confirmez le besoin local avant l’exposition : un espace disque dimensionné pour les index, avec une marge suffisante pour les reconstructions et les 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

Remplacez les tags flottants par une version testée ou un digest. Après le démarrage, inspectez docker logs --tail 200 meilisearch et confirmez que le processus écoute sur le port 7700. Exécutez ensuite l’action d’acceptation Meilisearch ; une réponse de la page racine ne peut pas prouver que le scénario complet fonctionne : créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus.

Donner à Meilisearch une adresse canonique

Considérez l’URL externe de Meilisearch comme une configuration qui doit survivre aux redeploys. Commencez par servir l’API HTTP via une seule origine HTTPS authentifiée, puis acheminez le hostname vers le port 7700 en conservant l’hôte et le schéma d’origine.

La checklist d’accessibilité du déploiement peut confirmer que les requêtes entrent bien dans le conteneur. Après cette étape, le problème connu — MEILI_ENV reste sur development ou le volume de données est perdu lors d’un redeploy — doit être recherché dans Meilisearch, dans son état ou dans sa charge de travail, et non dans l’automatisation des certificats.

Restaurer Meilisearch sur un hôte vierge

L’ensemble nécessaire à une récupération durable se compose de dumps ou snapshots planifiés, ainsi que du répertoire de données persistant. Montez /meili_data avant le bootstrap, écrivez des données d’exemple inoffensives, puis remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Un volume protège les données contre le remplacement du conteneur, mais pas contre la perte de l’hôte, une suppression accidentelle ou une corruption au niveau de l’application.

Effectuez des sauvegardes qui tiennent compte de la source de données : utilisez des dumps logiques pour les bases de données live lorsque cela est nécessaire et ne copiez des fichiers qu’à partir d’un état cohérent. Conservez une copie chiffrée hors de l’hôte Meilisearch. Le critère d’acceptation d’une restauration doit être précis : un dump doit être importé sur un serveur vierge avec les mêmes paramètres, le même nombre de documents et un ranking représentatif. Le guide des sauvegardes testées par une restauration explique pourquoi le simple succès d’un job ne suffit pas.

Protéger la partie précieuse de Meilisearch

Ne reprenez pas les hypothèses de sécurité d’un tutoriel local. Le risque propre à Meilisearch est de démarrer en production sans master key. En production, la master key doit donc être réservée à l’administration, tandis que les clients de recherche dans le navigateur doivent utiliser des clés de recherche aux permissions limitées.

Traitez MEILI_MASTER_KEY en fonction de son rôle dans Meilisearch : gardez les valeurs sensibles hors de Git, documentez les effets d’une rotation et ne remplacez jamais un exemple public en production. Limitez les accès au système de fichiers et au réseau, protégez les endpoints de configuration et définissez des limites d’upload, de requêtes ou d’exécution autour de la mémoire utilisée lors de l’indexation par lots, de l’espace disque temporaire pendant la construction des index, du nombre de documents et du trafic de recherche concurrent.

Surveiller la charge de travail, pas seulement le conteneur

Les tests de capacité doivent couvrir la mémoire utilisée lors de l’indexation par lots, l’espace disque temporaire pendant la construction des index, le nombre de documents et le trafic de recherche concurrent, et non une requête répétée vers /. Exécutez le scénario « créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus » avec une concurrence réaliste, puis relevez la latence, le taux d’erreur et la croissance du stockage.

La planification des mises à niveau doit tenir compte de ce risque : la compatibilité des dumps Meilisearch et les exigences de reconstruction des index doivent être vérifiées avant de changer de version. Testez la nouvelle release avec des données représentatives, puis répétez la transaction d’acceptation et comparez son résultat. Si MEILI_ENV reste sur development ou si le volume de données est perdu lors d’un redeploy, capturez la transaction en échec et inspectez la première frontière impliquée au lieu de supposer que l’ingress est responsable.

Transformer le smoke test Meilisearch en contrôle de release

Pour Meilisearch, définissez une transaction de référence avant le lancement : créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus. Placez ses prérequis, sa réponse attendue et ses étapes de nettoyage dans le contrôle de version, sans valeurs secrètes. Épinglez l’image utilisée pour établir cette référence.

Utilisez cette transaction pour valider un remplacement et une restauration indépendante. Le service restauré n’est acceptable que lorsqu’un dump est importé sur un serveur vierge avec les mêmes paramètres, le même nombre de documents et un ranking représentatif. Dans le même temps, observez la mémoire utilisée lors de l’indexation par lots, l’espace disque temporaire pendant la construction des index, le nombre de documents et le trafic de recherche concurrent, puis transformez la partie la plus lente ou la plus contrainte en alerte de niveau de service.

La validation doit également inclure un cas négatif : envoyez des données inoffensives proches de la limite de ressources ou de format associée à cette frontière : MEILI_ENV reste sur development ou le volume de données est perdu lors d’un redeploy. Vérifiez que Meilisearch produit une erreur exploitable tout en préservant les données, rétablissez la condition valide et répétez la transaction de référence. Conserver les deux résultats empêche un endpoint de health check superficiel de devenir la seule preuve disponible en production.

Garder Meilisearch explicite pendant que Dockup gère le routage

Le déploiement Meilisearch en un clic de Dockup doit rendre le remplacement sûr : la route continue de cibler le port 7700, les secrets ne sont pas intégrés à l’image et les chemins persistants sont restaurés sur le nouveau conteneur. Le même déploiement peut s’exécuter sur le compute Dockup ou sur une machine attachée.

Terminez le travail spécifique à l’application en confirmant le besoin local — un espace disque dimensionné pour les index, avec une marge suffisante pour les reconstructions et les dumps —, en appliquant l’adresse publique canonique et en exécutant ce contrôle d’acceptation : créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus. Ajoutez le résultat de la restauration au runbook avant l’arrivée des vrais utilisateurs.

Questions fréquemment posées

De quoi Meilisearch a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Meilisearch sur le port 7700 via une seule origine HTTPS. Le besoin d’exécution local est un espace disque dimensionné pour les index, avec une marge suffisante pour les reconstructions et les dumps. Ne considérez pas Meilisearch comme prêt tant que vous ne pouvez pas créer un index, importer des documents, configurer les attributs filtrables et vérifier qu’une requête tolérante aux fautes de frappe ainsi qu’un filtre renvoient les enregistrements attendus.

Quelles données Meilisearch doivent figurer dans une sauvegarde ?

Rendez /meili_data persistant et incluez les dumps ou snapshots planifiés ainsi que le répertoire de données persistant dans le même manifest de récupération. Une restauration Meilisearch sur un serveur vierge n’est validée que lorsqu’un dump est importé sur un serveur vierge avec les mêmes paramètres, le même nombre de documents et un ranking représentatif.

Meilisearch nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine Meilisearch publique et gardez le port 7700 sur la route interne. Appliquez correctement le paramètre Meilisearch : servez l’API HTTP via une seule origine HTTPS authentifiée. Pour Meilisearch, HTTPS protège les identifiants ou le contenu utilisateur en transit et garantit la cohérence du comportement des clients dépendant de l’origine.

Comment tester une mise à niveau de Meilisearch ?

Restaurez l’état actuel de Meilisearch dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car la compatibilité des dumps Meilisearch et les exigences de reconstruction des index doivent être vérifiées avant de changer de version. Conservez l’image Meilisearch précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.