Índice del diarioDockup / nota de campo
Note / self-host-meilisearch

Cómo alojar Meilisearch por tu cuenta en 2026: master keys, indexes y dumps

Aloja Meilisearch por tu cuenta con los puertos correctos, almacenamiento persistente, HTTPS, secretos, backups y comprobaciones de actualización. Aprende a solucionar el problema cuando MEILI_ENV permanece en development.

Alojar Meilisearch por tu cuenta resulta interesante en el primer redeploy, no en el primer docker run. Si MEILI_ENV permanece en development o el volumen de datos se pierde durante un redeploy, Docker puede seguir informando de que el proceso está perfectamente healthy. El despliegue siguiente se organiza en torno a un comportamiento observable: crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados.

La función de Meilisearch es clara: búsqueda full-text tolerante a typos con una API HTTP rápida. Esta descripción indica qué debe permanecer público, qué debería mantenerse privado y qué debe poder reconstruir un backup.

Analiza Meilisearch antes de tocar Docker

Separa cuatro aspectos de Meilisearch: ingress, el listener en 7700, el estado persistente y los servicios auxiliares o la capacidad local. El requisito del runtime local es disponer de disco suficiente para los indexes, además de margen para rebuilds y dumps. Mantén su ciclo de vida explícito para que mover Meilisearch entre hosts no cambie el comportamiento silenciosamente.

Ejecuta la transacción validada —crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados— antes de dar por completada esa separación. Mide la memoria durante el batch indexing, el espacio temporal en disco durante los index builds, el número de documentos y el tráfico de búsqueda concurrente, y conserva el resultado junto con el registro del despliegue. Esto proporciona tanto un criterio de aceptación como la primera referencia de capacidad.

Haz reproducible el arranque de Meilisearch

Usa un comando que exponga todas las decisiones importantes. Esta configuración base vincula Meilisearch al loopback del host, añade los mounts de datos conocidos y proporciona el primer setting necesario. Confirma el requisito local antes de exponerlo: disco suficiente para los indexes, además de margen para rebuilds y 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

Sustituye los tags flotantes por una versión probada o un digest. Después del arranque, inspecciona docker logs --tail 200 meilisearch y confirma que el proceso escucha en 7700. A continuación, ejecuta la acción de aceptación de Meilisearch; una respuesta de la root page no puede demostrar que el escenario completo funciona: crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados.

Asigna una dirección canónica a Meilisearch

Trata la URL externa de Meilisearch como una configuración que debe sobrevivir a los redeploys. Primero sirve la API HTTP a través de un único origin HTTPS autenticado; después dirige el hostname al puerto 7700 conservando intactos el host y el scheme originales.

El checklist de reachability del despliegue puede demostrar que las requests llegan al container. A partir de ese momento, el fallo conocido —MEILI_ENV permanece en development o el volumen de datos se pierde durante un redeploy— debe investigarse en Meilisearch, en su estado o en su workload, no en la automatización de certificados.

Restaura Meilisearch en un host vacío

El conjunto de recuperación persistente está formado por dumps o snapshots programados y el directorio de datos persistente. Monta /meili_data antes del bootstrap, escribe datos de ejemplo inofensivos y sustituye el container para demostrar que esa ruta es realmente persistente. Un volume protege los datos frente a la sustitución del container, pero no frente a la pérdida del host, el borrado accidental o la corrupción a nivel de aplicación.

Haz backups que entiendan el origen de los datos: usa logical dumps para live databases cuando sea necesario y copia archivos únicamente desde un estado consistente. Conserva una copia cifrada fuera del host de Meilisearch. El criterio de aceptación de un restore debe ser específico: un dump se importa en un servidor limpio con los mismos settings, el mismo número de documentos y un ranking representativo. La guía de backups con restore probado explica por qué el éxito del job por sí solo no es suficiente.

Protege la parte valiosa de Meilisearch

No heredes las suposiciones de seguridad de un tutorial local. La preocupación específica de Meilisearch es iniciar production sin una master key. Por tanto, production debe reservar la master key para la administración y proporcionar a los clientes de búsqueda desde el navegador search keys restringidas.

Trata MEILI_MASTER_KEY según su función en Meilisearch: mantén los valores sensibles fuera de Git, documenta los efectos de la rotación y no sustituyas un ejemplo público en production. Limita el acceso al filesystem y a la red, protege los endpoints de setup y define límites de upload, requests o execution alrededor de la memoria durante el batch indexing, el espacio temporal en disco durante los index builds, el número de documentos y el tráfico de búsqueda concurrente.

Observa el workload, no solo el container

Las pruebas de capacidad deben ejercitar la memoria durante el batch indexing, el espacio temporal en disco durante los index builds, el número de documentos y el tráfico de búsqueda concurrente, no repetir una request a /. Ejecuta el escenario «crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados» con una concurrencia realista y registra la latencia, la tasa de errores y el crecimiento del storage.

La planificación de upgrades debe tener en cuenta este riesgo: la compatibilidad de los dumps de Meilisearch y los requisitos de rebuild de los indexes deben comprobarse antes de cambiar de versión. Prueba la nueva release con datos de entrada representativos, repite después la transacción de aceptación y compara el resultado. Si MEILI_ENV permanece en development o el volumen de datos se pierde durante un redeploy, captura la transacción fallida e inspecciona el primer boundary implicado en lugar de asumir que el problema está en el ingress.

Convierte el smoke test de Meilisearch en un check de release

Para Meilisearch, define una transacción validada antes del lanzamiento: crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados. Guarda sus prerrequisitos, la respuesta esperada y los pasos de cleanup en el control de versiones, sin valores secretos. Fija la image utilizada para establecer esa referencia.

Usa la transacción para validar una sustitución y un restore independiente. El servicio restaurado solo es aceptable cuando un dump se importa en un servidor limpio con los mismos settings, el mismo número de documentos y un ranking representativo. Al mismo tiempo, observa la memoria durante el batch indexing, el espacio temporal en disco durante los index builds, el número de documentos y el tráfico de búsqueda concurrente, y convierte la parte más lenta o limitada en una alerta de nivel de servicio.

El gate también necesita un caso negativo: envía datos inofensivos cerca del límite de recursos o de formato asociado a este boundary: MEILI_ENV permanece en development o el volumen de datos se pierde durante un redeploy. Confirma que Meilisearch produce un error accionable mientras conserva los datos, restaura la condición válida y repite la transacción validada. Conservar ambos resultados evita que un health endpoint superficial se convierta en la única evidencia en production.

Mantén Meilisearch explícito mientras Dockup gestiona el routing

El despliegue de Meilisearch con un clic de Dockup debería hacer que la sustitución sea segura: la route sigue apuntando al 7700, los secretos no se incorporan a la image y las rutas persistentes reaparecen en el nuevo container. El mismo despliegue puede ejecutarse en compute de Dockup o en una máquina conectada.

Completa el trabajo específico de la aplicación confirmando el requisito local —disco suficiente para los indexes, además de margen para rebuilds y dumps—, aplicando la dirección pública canónica y ejecutando este check de aceptación: crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados. Añade el resultado del restore al runbook antes de que lleguen los usuarios reales.

Preguntas frecuentes

¿Qué necesita Meilisearch para un despliegue en production?

Dirige el container de Meilisearch en el puerto 7700 a través de un único origin HTTPS. El requisito del runtime local es disponer de disco suficiente para los indexes, además de margen para rebuilds y dumps. No consideres que Meilisearch está listo hasta poder crear un index, importar documentos, configurar atributos filterable y demostrar que una query tolerante a typos y un filter devuelven los registros esperados.

¿Qué datos de Meilisearch deben incluirse en un backup?

Haz persistente /meili_data e incluye los dumps o snapshots programados y el directorio de datos persistente en el mismo recovery manifest. Un restore limpio de Meilisearch solo es válido cuando un dump se importa en un servidor limpio con los mismos settings, el mismo número de documentos y un ranking representativo.

¿Meilisearch necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origin público de Meilisearch y mantén el puerto 7700 en la route interna. Aplica correctamente el setting de Meilisearch: sirve la API HTTP a través de un único origin HTTPS autenticado. En Meilisearch, HTTPS protege las credenciales o el contenido de usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origin.

¿Cómo debe probarse un upgrade de Meilisearch?

Restaura el estado actual de Meilisearch en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque la compatibilidad de los dumps de Meilisearch y los requisitos de rebuild de los indexes deben comprobarse antes de cambiar de versión. Conserva la image anterior de Meilisearch hasta comprender sus límites de migración de datos y rollback.