Så självhostar du Meilisearch 2026: huvudnycklar, index och dumpar

Det är vid den första omdistributionen som det blir intressant att självhosta Meilisearch – inte vid den första docker run. Om MEILI_ENV förblir development eller datavolymen försvinner under en omdistribution kan Docker fortfarande rapportera en helt frisk process. Distributionen nedan är uppbyggd kring observerbart beteende: skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna.

Meilisearch har ett tydligt användningsområde: typtolerant fulltextsökning med ett snabbt HTTP API. Den beskrivningen visar vad som måste vara publikt, vad som bör förbli privat och vad en säkerhetskopia måste kunna återskapa.

Kartlägg Meilisearch innan du rör Docker

Dela upp fyra områden för Meilisearch: ingress, lyssnaren på 7700, beständigt tillstånd samt stödtjänster eller lokal kapacitet. Det lokala körtidskravet är diskutrymme dimensionerat för index, med marginal för ombyggnader och dumpar. Håll livscykeln tydlig, så att en flytt av Meilisearch mellan värdar inte i tysthet ändrar beteendet.

Kör den beprövade transaktionen – skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna – innan du betraktar uppdelningen som färdig. Mät minnesanvändning vid batchindexering, temporärt diskutrymme under indexbyggen, antalet dokument och samtidig söktrafik, och spara resultatet tillsammans med distributionsinformationen. Det ger både ett acceptanskriterium och den första kapacitetsbaslinjen.

Gör Meilisearchs uppstart reproducerbar

Använd ett kommando som exponerar alla viktiga val. Den här baslinjen binder Meilisearch till värdens loopback-adress, lägger till de kända datamonteringar och anger den första obligatoriska inställningen. Bekräfta det lokala kravet innan exponering: diskutrymme dimensionerat för index, med marginal för ombyggnader och dumpar.

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

Ersätt flytande taggar med en testad version eller digest. Kontrollera efter uppstart docker logs --tail 200 meilisearch och bekräfta att processen lyssnar på 7700. Kör sedan Meilisearchs acceptanstest; ett svar från rotsidan kan inte bevisa att hela scenariot fungerar: skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna.

Ge Meilisearch en kanonisk adress

Behandla den externa Meilisearch-URL:en som konfiguration som ska överleva omdistributioner. Servera först HTTP API:t via en autentiserad HTTPS-origin och dirigera sedan värdnamnet till port 7700, med det ursprungliga värdnamnet och schemat intakta.

Checklistan för åtkomst till distributionen kan bevisa att förfrågningar når containern. Därefter bör det kända felet – MEILI_ENV förblir development eller datavolymen försvinner under en omdistribution – undersökas i Meilisearch, dess tillstånd eller dess arbetsbelastning, inte i certifikatautomatiseringen.

Återställ Meilisearch på en tom värd

Den beständiga återställningsuppsättningen består av schemalagda dumpar eller snapshots samt den beständiga datakatalogen. Montera /meili_data före bootstrap, skriv in ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. En volym skyddar data från att containern ersätts, men inte från att värden går förlorad, oavsiktlig radering eller korruption på applikationsnivå.

Ta säkerhetskopior som förstår datakällan: använd logiska dumpar för aktiva databaser när det behövs och kopiera filer endast från ett konsekvent tillstånd. Förvara en krypterad kopia separat från Meilisearch-värden. Acceptanskriteriet för en återställning ska vara specifikt – en dump ska kunna importeras till en ren server med samma inställningar, dokumentantal och representativa ranking. Guiden för testade återställningar från säkerhetskopior förklarar varför enbart lyckade jobb inte räcker.

Skydda den värdefulla delen av Meilisearch

Ärv inte säkerhetsantaganden från en lokal handledning. Meilisearchs specifika risk är att starta produktion utan en huvudnyckel. I produktion bör huvudnyckeln därför reserveras för administration, medan webbläsarbaserade sökklienter får begränsade söknycklar.

Hantera MEILI_MASTER_KEY utifrån dess roll i Meilisearch: håll känsliga värden borta från Git, dokumentera effekterna av rotation och ersätt aldrig ett offentligt exempel i produktion. Begränsa åtkomst till filsystem och nätverk, skydda installationsslutpunkter och definiera gränser för uppladdningar, förfrågningar eller körning kring minnesanvändning vid batchindexering, temporärt diskutrymme under indexbyggen, antalet dokument och samtidig söktrafik.

Övervaka arbetsbelastningen, inte bara containern

Kapacitetstester bör belasta minnet vid batchindexering, det temporära diskutrymmet under indexbyggen, antalet dokument och den samtidiga söktrafiken – inte bara upprepa en förfrågan till /. Kör scenariot ”skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna” med realistisk samtidighet och registrera svarstid, felfrekvens och lagringstillväxt.

Planeringen av uppgraderingar måste ta hänsyn till denna risk: kompatibilitet för Meilisearch-dumpar och krav på ombyggnad av index måste kontrolleras innan versioner ändras. Testa den nya versionen med representativa indata, kör sedan acceptanstransaktionen igen och jämför resultatet. Om MEILI_ENV förblir development eller datavolymen försvinner under en omdistribution ska du fånga den transaktion som misslyckas och undersöka den första berörda gränsen, i stället för att anta att ingressen är ansvarig.

Gör Meilisearchs smoke test till en releasekontroll

För Meilisearch ska du definiera en beprövad transaktion före lansering: skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna. Lägg dess förutsättningar, förväntade svar och rensningssteg i versionshanteringen utan hemliga värden. Lås den image som användes för att fastställa referensen till en specifik version.

Använd transaktionen för att validera en ersättning och en oberoende återställning. Den återställda tjänsten är godkänd först när en dump kan importeras till en ren server med samma inställningar, dokumentantal och representativa ranking. Observera samtidigt minnesanvändning vid batchindexering, temporärt diskutrymme under indexbyggen, antalet dokument och samtidig söktrafik, och omvandla den långsammaste eller mest begränsade delen till en alert på servicenivå.

Kontrollen behöver också ett negativt fall: skicka in ofarliga data nära den resurs- eller formatgräns som hör till denna gräns: MEILI_ENV förblir development eller datavolymen försvinner under en omdistribution. Bekräfta att Meilisearch genererar ett användbart fel samtidigt som data bevaras, återställ det giltiga tillståndet och kör den beprövade transaktionen igen. Genom att behålla båda resultaten förhindrar du att en ytlig health endpoint blir det enda produktionsbeviset.

Håll Meilisearch tydligt konfigurerat medan Dockup hanterar routing

Dockups distribution av Meilisearch med ett klick bör göra ersättningar säkra: routingen fortsätter att peka på 7700, hemligheter byggs inte in i imagen och beständiga sökvägar återkommer i den nya containern. Samma distribution kan köras på Dockups compute eller på en ansluten maskin.

Slutför det applikationsspecifika arbetet genom att bekräfta det lokala kravet – diskutrymme dimensionerat för index, med marginal för ombyggnader och dumpar – tillämpa den kanoniska publika adressen och köra denna acceptanskontroll: skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna. Lägg till återställningsresultatet i driftinstruktionen innan riktiga användare ansluter.

Vanliga frågor

Vad behöver Meilisearch för en produktionsdistribution?

Dirigera Meilisearch-containern på port 7700 via en HTTPS-origin. Det lokala körtidskravet är diskutrymme dimensionerat för index, med marginal för ombyggnader och dumpar. Markera inte Meilisearch som klar förrän du kan skapa ett index, importera dokument, konfigurera filtrerbara attribut och verifiera att en typtolerant sökning och ett filter returnerar de förväntade posterna.

Vilka Meilisearch-data ska ingå i en säkerhetskopia?

Gör /meili_data beständig och inkludera schemalagda dumpar eller snapshots samt den beständiga datakatalogen i samma återställningsmanifest. En ren Meilisearch-återställning är godkänd först när en dump kan importeras till en ren server med samma inställningar, dokumentantal och representativa ranking.

Kräver Meilisearch HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Meilisearch-originen och behåll port 7700 i den interna routingen. Tillämpa Meilisearch-inställningen korrekt: servera HTTP API:t via en autentiserad HTTPS-origin. För Meilisearch skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och säkerställer ett konsekvent klientbeteende som är känsligt för origin.

Hur bör en Meilisearch-uppgradering testas?

Återställ det aktuella Meilisearch-tillståndet till en isolerad distribution, tillämpa den föreslagna versionen och kör acceptanstransaktionen igen. Var särskilt uppmärksam eftersom kompatibilitet för Meilisearch-dumpar och krav på ombyggnad av index måste kontrolleras innan versioner ändras. Behåll den tidigare Meilisearch-imagen tills gränsen för datamigrering och återställning är klarlagd.