Sådan self-hoster du Meilisearch i 2026: master keys, indexes og dumps

Det bliver interessant at self-hoste Meilisearch ved den første redeploy – ikke ved den første docker run. Hvis MEILI_ENV bliver ved med at være development, eller data-volumet går tabt under en redeploy, kan Docker stadig rapportere en proces, der ser helt sund ud. Deploymentet nedenfor er bygget op omkring observerbar adfærd: Opret et index, importer dokumenter, konfigurer filterable attributes, og verificer, at en typo-tolerant query og et filter returnerer de forventede records.

Meilisearchs formål er klart: typo-tolerant full-text search med en hurtig HTTP API. Den beskrivelse fortæller os, hvad der skal være offentligt, hvad der bør forblive privat, og hvad en backup skal kunne genskabe.

Kortlæg Meilisearch, før du rører ved Docker

Adskil fire forhold i Meilisearch: ingress, listeneren på 7700, persistent state samt understøttende services eller lokal kapacitet. Det lokale runtime-krav er diskplads dimensioneret til indexes plus plads til rebuilds og dumps. Hold livscyklussen eksplicit, så en flytning af Meilisearch mellem hosts ikke ændrer adfærden ubemærket.

Kør den kendte, velfungerende transaktion – opret et index, importer dokumenter, konfigurer filterable attributes, og verificer, at en typo-tolerant query og et filter returnerer de forventede records – før du betragter adskillelsen som fuldført. Mål memoryforbruget ved batch indexing, midlertidig diskplads under index builds, antallet af dokumenter og concurrent search traffic, og gem resultatet sammen med deployment-recordet. Det giver både et acceptkriterium og det første kapacitetsbaseline.

Gør Meilisearchs opstart reproducerbar

Brug en kommando, der eksponerer alle vigtige valg. Denne baseline binder Meilisearch til hostens loopback-interface, tilføjer de kendte data mounts og angiver den første påkrævede indstilling. Bekræft det lokale krav, før du eksponerer servicen: diskplads dimensioneret til indexes plus plads til rebuilds og 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

Erstat floating tags med en testet version eller digest. Undersøg docker logs --tail 200 meilisearch efter opstart, og bekræft, at processen lytter på 7700. Kør derefter Meilisearchs accepttest; et svar fra root-siden kan ikke bevise, at hele scenariet fungerer: Opret et index, importer dokumenter, konfigurer filterable attributes, og verificer, at en typo-tolerant query og et filter returnerer de forventede records.

Giv Meilisearch én canonical address

Betragt den eksterne Meilisearch-URL som konfiguration, der skal overleve redeploys. Servér først HTTP API'et gennem én authenticated HTTPS origin, og rout derefter hostnavnet til port 7700, mens den oprindelige host og scheme bevares.

Deployment-checklisten for reachability kan verificere, at requests når ind i containeren. Derefter bør den kendte fejl – MEILI_ENV bliver ved med at være development, eller data-volumet går tabt under en redeploy – undersøges i Meilisearch, dens state eller dens workload i stedet for i certificate automation.

Gendan Meilisearch på en tom host

Det permanente recovery-sæt består af planlagte dumps eller snapshots samt den persistente datamappe. Mount /meili_data før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Et volume beskytter data mod udskiftning af containeren, men ikke mod tab af hosten, utilsigtet sletning eller corruption på applikationsniveau.

Tag backups, der forstår datakilden: Brug logical dumps til live-databaser, når det er nødvendigt, og kopiér kun filer fra en konsistent state. Opbevar én krypteret kopi væk fra Meilisearch-hosten. Acceptkriteriet for en restore er specifikt – et dump skal kunne importeres på en ren server med de samme settings, det samme antal dokumenter og en repræsentativ ranking. Guiden til restore-testede backups forklarer, hvorfor en succesfuld jobstatus alene ikke er tilstrækkelig.

Beskyt den værdifulde del af Meilisearch

Overfør ikke sikkerhedsantagelser fra en lokal tutorial. Meilisearchs specifikke problem er at starte production uden en master key. Production bør derfor reservere master key til administration og give browserbaserede search clients restricted search keys.

Behandl MEILI_MASTER_KEY i overensstemmelse med dens rolle i Meilisearch: Hold sensitive værdier ude af Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i production. Begræns filesystem- og netværksadgang, beskyt setup-endpoints, og definér grænser for upload, requests eller execution omkring memoryforbrug ved batch indexing, midlertidig diskplads under index builds, antallet af dokumenter og concurrent search traffic.

Overvåg workloaden – ikke kun containeren

Kapacitetstests bør udøve memoryforbrug ved batch indexing, midlertidig diskplads under index builds, antallet af dokumenter og concurrent search traffic – ikke sende en gentagen request til /. Kør scenariet “opret et index, importer dokumenter, konfigurer filterable attributes, og verificer, at en typo-tolerant query og et filter returnerer de forventede records” med realistisk concurrency, og registrér latency, error rate og vækst i storage.

Upgrade-planlægningen skal tage højde for denne risiko: Meilisearch dump compatibility og krav til index rebuild skal kontrolleres, før versioner ændres. Test den nye release med repræsentativt input, gentag derefter accepttransaktionen, og sammenlign resultatet. Hvis MEILI_ENV bliver ved med at være development, eller data-volumet går tabt under en redeploy, skal den fejlslagne transaktion registreres, og den første involverede grænse undersøges i stedet for at antage, at ingress er ansvarlig.

Gør Meilisearchs smoke test til et release-tjek

For Meilisearch skal du definere en kendt, velfungerende transaktion før lancering: Opret et index, importer dokumenter, konfigurer filterable attributes, og verificer, at en typo-tolerant query og et filter returnerer de forventede records. Læg dens forudsætninger, forventede response og cleanup-trin i version control uden secret values. Pin det image, der bruges til at etablere denne reference.

Brug transaktionen til at validere en udskiftning og en uafhængig restore. Den gendannede service er kun acceptabel, når et dump kan importeres på en ren server med de samme settings, det samme antal dokumenter og en repræsentativ ranking. Observer samtidig memoryforbrug ved batch indexing, midlertidig diskplads under index builds, antallet af dokumenter og concurrent search traffic, og gør den langsomste eller mest begrænsede del til en service-level alert.

Gaten skal også indeholde et negativt testtilfælde: Send harmløst input tæt på den ressource- eller formatgrænse, der er forbundet med denne grænse: MEILI_ENV bliver ved med at være development, eller data-volumet går tabt under en redeploy. Bekræft, at Meilisearch genererer en handlingsanvisende fejl, samtidig med at data bevares, genskab den gyldige tilstand, og gentag den kendte, velfungerende transaktion. Når begge resultater bevares, forhindrer det, at et overfladisk health-endpoint bliver det eneste produktionsbevis.

Hold Meilisearch eksplicit, mens Dockup håndterer routing

Dockups one-click Meilisearch-deployment bør gøre udskiftning sikker: Routen skal fortsat pege på 7700, secrets må ikke være baked ind i imaget, og persistente paths skal være tilgængelige i den nye container. Det samme deployment kan køre på Dockup compute eller en tilknyttet maskine.

Afslut det applikationsspecifikke arbejde ved at bekræfte det lokale krav – diskplads dimensioneret til indexes plus plads til rebuilds og dumps – anvende den canonical public address og køre denne accepttest: Opret et index, importer dokumenter, konfigurer filterable attributes, og verificer, at en typo-tolerant query og et filter returnerer de forventede records. Tilføj restore-resultatet til runbooken, før de rigtige brugere ankommer.

Ofte stillede spørgsmål

Hvad kræver Meilisearch til et produktionsdeployment?

Rout Meilisearch-containeren på port 7700 gennem én HTTPS-origin. Det lokale runtime-krav er diskplads dimensioneret til indexes plus plads til rebuilds og dumps. Kald ikke Meilisearch klar, før du kan oprette et index, importere dokumenter, konfigurere filterable attributes og verificere, at en typo-tolerant query og et filter returnerer de forventede records.

Hvilke Meilisearch-data hører hjemme i en backup?

Gør /meili_data persistent, og medtag planlagte dumps eller snapshots samt den persistente datamappe i det samme recovery-manifest. En ren Meilisearch-restore er kun godkendt, når et dump kan importeres på en ren server med de samme settings, det samme antal dokumenter og en repræsentativ ranking.

Kræver Meilisearch HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Meilisearch-origin, og behold port 7700 på den interne route. Anvend Meilisearch-indstillingen korrekt: Servér HTTP API'et gennem én authenticated HTTPS origin. For Meilisearch beskytter HTTPS credentials eller brugerindhold under transmission og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan bør en Meilisearch-upgrade testes?

Gendan den aktuelle Meilisearch-state i et isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi Meilisearch dump compatibility og krav til index rebuild skal kontrolleres, før versioner ændres. Behold det tidligere Meilisearch-image, indtil dets grænser for datamigrering og rollback er forstået.