2026'da Meilisearch Nasıl Self-Host Edilir: Master Key, Index'ler ve Dump'lar

Meilisearch'i self-host etmenin asıl önemli olduğu an ilk docker run değil, ilk redeploy işlemidir. MEILI_ENV development olarak kalırsa veya redeploy sırasında data volume kaybedilirse Docker yine de tamamen sağlıklı bir process raporlayabilir. Aşağıdaki deployment, gözlemlenebilir davranışlar etrafında düzenlenmiştir: bir index oluşturun, document'ları import edin, filterable attribute'ları yapılandırın ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayın.

Meilisearch'in amacı nettir: hızlı bir HTTP API ile typo-tolerant full-text search. Bu tanım, nelerin public kalması, nelerin private tutulması ve bir backup'ın neleri yeniden oluşturması gerektiğini gösterir.

Docker'a dokunmadan önce Meilisearch'i haritalayın

Meilisearch için dört konuyu birbirinden ayırın: ingress, 7700 portundaki listener, kalıcı state ve supporting service'ler ya da local capacity. Local runtime gereksinimi, index'ler için yeterli disk alanı ve rebuild ile dump işlemleri için ayrılmış ek kapasitedir. Meilisearch'i host'lar arasında taşırken davranışın sessizce değişmemesi için lifecycle'ını açıkça yönetin.

Bu ayrımın tamamlandığını söylemeden önce bilinen başarılı transaction'ı — bir index oluşturun, document'ları import edin, filterable attribute'ları yapılandırın ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayın — çalıştırın. Batch indexing memory kullanımını, index build sırasında geçici disk ihtiyacını, document sayısını ve eşzamanlı search trafiğini ölçün; sonucu deployment kaydıyla birlikte saklayın. Bu sonuç hem bir acceptance criterion hem de ilk capacity baseline'ını sağlar.

Meilisearch startup sürecini tekrarlanabilir hâle getirin

Her önemli seçeneği görünür kılan bir command kullanın. Bu baseline, Meilisearch'i host loopback'e bağlar, bilinen data mount'larını ekler ve ilk gerekli ayarı sağlar. Dış erişime açmadan önce local gereksinimi doğrulayın: index'ler için yeterli disk alanı ve rebuild ile dump işlemleri için ayrılmış ek kapasite.

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

Floating tag'leri test edilmiş bir version veya digest ile değiştirin. Startup sonrasında docker logs --tail 200 meilisearch çıktısını inceleyin ve process'in 7700 portunu dinlediğini doğrulayın. Ardından Meilisearch acceptance action'ını çalıştırın; root-page response, tüm senaryonun başarılı olduğunu kanıtlayamaz: bir index oluşturun, document'ları import edin, filterable attribute'ları yapılandırın ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayın.

Meilisearch için tek bir canonical address kullanın

External Meilisearch URL'sini redeploy'ler boyunca değişmeyen bir configuration olarak ele alın. Önce HTTP API'yi tek bir authenticated HTTPS origin üzerinden sunun; ardından hostname'i, original host ve scheme bilgilerini koruyarak 7700 portuna yönlendirin.

Deployment reachability checklist, request'lerin container'a ulaştığını kanıtlayabilir. Bu noktadan sonra bilinen failure — MEILI_ENV development olarak kalır veya redeploy sırasında data volume kaybedilir — certificate automation'da değil, Meilisearch'te, state'inde ya da workload'unda araştırılmalıdır.

Boş bir host üzerinde Meilisearch'i geri yükleyin

Kalıcı recovery set'i, scheduled dump'lar veya snapshot'lar ile persistent data directory'den oluşur. Bootstrap işleminden önce /meili_data mount'unu ekleyin, zararsız sample data yazın ve bu path'in gerçekten persistent olduğunu kanıtlamak için container'ı değiştirin. Bir volume, container replacement işlemine karşı data'yı korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption'a karşı koruma sağlamaz.

Data source'u anlayan backup'lar alın: gerektiğinde canlı database'ler için logical dump'lar kullanın ve dosyaları yalnızca consistent bir state'ten kopyalayın. En az bir encrypted copy'yi Meilisearch host'undan ayrı bir yerde tutun. Restore için acceptance criterion nettir — bir dump, aynı setting'ler, document sayısı ve representative ranking ile clean bir server'a import edilmelidir. Restore-tested backup guide, yalnızca job success bilgisinin neden yeterli olmadığını açıklar.

Meilisearch'in değerli kısmını koruyun

Bir local tutorial'daki security varsayımlarını olduğu gibi almayın. Meilisearch'e özgü temel risk, production'ı master key olmadan başlatmaktır. Bu nedenle production ortamında master key'i administration için ayırın ve browser search client'larına restricted search key'ler verin.

MEILI_MASTER_KEY'i Meilisearch'teki rolüne göre yönetin: hassas değerleri Git'ten uzak tutun, rotation etkilerini belgeleyin ve production'da public bir örneği asla kullanmayın. Filesystem ve network access'i scope'layın, setup endpoint'lerini koruyun ve batch indexing memory, index build sırasında geçici disk, document sayısı ve eşzamanlı search trafiği etrafında upload, request veya execution limit'leri tanımlayın.

Yalnızca container'ı değil, workload'u izleyin

Capacity test'leri / adresine tekrarlanan bir request göndermekle yetinmemeli; batch indexing memory, index build sırasında geçici disk, document sayısı ve eşzamanlı search trafiğini de çalıştırmalıdır. “Bir index oluşturun, document'ları import edin, filterable attribute'ları yapılandırın ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayın” senaryosunu gerçekçi concurrency ile çalıştırın; latency, error rate ve storage growth değerlerini kaydedin.

Upgrade planlaması şu riski hesaba katmalıdır: version değiştirmeden önce Meilisearch dump compatibility ve index rebuild gereksinimleri kontrol edilmelidir. Yeni release'i representative input ile test edin, ardından acceptance transaction'ı tekrarlayın ve sonucunu karşılaştırın. MEILI_ENV development olarak kalırsa veya redeploy sırasında data volume kaybedilirse failing transaction'ı kaydedin ve ingress'in sorumlu olduğunu varsaymak yerine dahil olan ilk boundary'yi inceleyin.

Meilisearch smoke test'ini bir release check'e dönüştürün

Meilisearch için launch öncesinde bilinen başarılı bir transaction tanımlayın: bir index oluşturun, document'ları import edin, filterable attribute'ları yapılandırın ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayın. Prerequisite'leri, beklenen response'u ve cleanup adımlarını secret değerler olmadan version control'e ekleyin. Bu reference'ı oluşturmak için kullanılan image'ı pin'leyin.

Bir replacement'ı ve bağımsız bir restore'u doğrulamak için transaction'ı kullanın. Restore edilen service yalnızca bir dump, aynı setting'ler, document sayısı ve representative ranking ile clean bir server'a import edildiğinde kabul edilebilir. Aynı zamanda batch indexing memory, index build sırasında geçici disk, document sayısı ve eşzamanlı search trafiğini gözlemleyin; en yavaş veya en kısıtlı bölümü service-level alert'e dönüştürün.

Gate ayrıca bir negative case de içermelidir: bu boundary ile ilişkili resource veya format limitine yakın, zararsız bir input gönderin: MEILI_ENV development olarak kalır veya redeploy sırasında data volume kaybedilir. Meilisearch'in data'yı korurken actionable bir error ürettiğini doğrulayın, geçerli durumu geri yükleyin ve bilinen başarılı transaction'ı tekrarlayın. Her iki sonucu saklamak, yüzeysel bir health endpoint'inin production'daki tek kanıt hâline gelmesini önler.

Dockup routing'i yönetirken Meilisearch'i açıkça yapılandırılmış tutun

Dockup'ın one-click Meilisearch deployment'ı replacement işlemini güvenli hâle getirmelidir: route 7700'ü hedeflemeye devam eder, secret'lar image'a gömülmez ve persistent path'ler yeni container'da yeniden kullanılabilir. Aynı deployment, Dockup compute veya bağlı bir machine üzerinde çalışabilir.

Uygulamaya özgü çalışmaları, local gereksinimi doğrulayarak tamamlayın — index'ler için yeterli disk alanı ve rebuild ile dump işlemleri için ayrılmış ek kapasite — canonical public address'i uygulayın ve şu acceptance check'i çalıştırın: bir index oluşturun, document'ları import edin, filterable attribute'ları yapılandırın ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayın. Gerçek kullanıcılar gelmeden önce restore sonucunu runbook'a ekleyin.

Sık sorulan sorular

Production deployment için Meilisearch neye ihtiyaç duyar?

Meilisearch container'ını 7700 portu üzerinden tek bir HTTPS origin'e yönlendirin. Local runtime gereksinimi, index'ler için yeterli disk alanı ve rebuild ile dump işlemleri için ayrılmış ek kapasitedir. Bir index oluşturup document'ları import edene, filterable attribute'ları yapılandırana ve typo-tolerant bir query ile filter'ın beklenen kayıtları döndürdüğünü kanıtlayana kadar Meilisearch'i hazır kabul etmeyin.

Meilisearch'teki hangi data backup'a dâhil edilmelidir?

/meili_data path'ini persistent hâle getirin ve scheduled dump'ları veya snapshot'ları, persistent data directory ile birlikte aynı recovery manifest'e ekleyin. Clean bir Meilisearch restore'u yalnızca bir dump, aynı setting'ler, document sayısı ve representative ranking ile clean bir server'a import edildiğinde başarılı sayılır.

Reverse proxy arkasında Meilisearch için HTTPS gerekir mi?

Public Meilisearch origin'i için HTTPS kullanın ve 7700 portunu internal route üzerinde tutun. Meilisearch setting'ini doğru uygulayın: HTTP API'yi tek bir authenticated HTTPS origin üzerinden sunun. Meilisearch için HTTPS, credentials veya user content'in transit sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Bir Meilisearch upgrade'i nasıl test edilmelidir?

Mevcut Meilisearch state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Özellikle dikkatli olun; Meilisearch dump compatibility ve index rebuild gereksinimleri version değiştirilmeden önce kontrol edilmelidir. Data migration ve rollback boundary'si anlaşılana kadar önceki Meilisearch image'ını saklayın.