2026'da Metabase Self-Hosting: Uygulama Veritabanı, TLS ve Yedekler

Daha önce Metabase'i self-host etmeyi denediyseniz, muhtemelen şu can sıkıcı durumla karşılaşmışsınızdır: UI açılır, ancak dashboard'ların kaynak veritabanları durduğu hâlde uygulama veritabanı kayıptır. Container'ı yeniden oluşturmak, URL'ler, state ve bağımlılıklar arasındaki uyuşmazlığı nadiren çözer.

Bu walkthrough, tek bir somut tamamlanma kriteri kullanır: salt okunur bir örnek veritabanına bağlanmak, bir soru kaydetmek, bir dashboard oluşturmak ve yapılandırılmış mail kanalı üzerinden bir subscription göndermek. Her yapılandırma tercihi, yeşil bir container rozeti yerine bu kritere göre değerlendirilir.

Kimlik bilgileri, roller ve dışa açık yüzeyler

Yalnızca login formunu değil, Metabase'in gerçekleştirdiği işlemi de tehdit modeli kapsamında değerlendirin. Buradaki yüksek riskli hata, embedded H2 uygulama veritabanını production'daki tek kopya olarak kullanmaktır. Şu sınırı uygulayın: mümkün olan yerlerde Metabase'e salt okunur veritabanı rolleri verin ve collection izinlerini veritabanı kimlik bilgilerinden ayırın.

MB_ENCRYPTION_SECRET_KEY değerini bir kez üretin, Git dışında tutun ve recovery manifest ile birlikte saklayın; çünkü bu değerin değiştirilmesi şifrelenmiş veya imzalanmış uygulama state'ini geçersiz kılabilir. Bir permission error'ı container'ı root olarak çalıştırarak veya host'u geniş kapsamlı biçimde mount ederek çözmeye çalışmayın. JVM heap, eşzamanlı sorgular, result caching ve her analytics data source'a aktarılan yük kullanıcılar tarafından tetiklenebildiğinden, resource limit'leri de güvenlik tasarımının bir parçasıdır.

Metabase'i bağımlılıklarından ayırın

Sorumlu bir Metabase topolojisinin en küçük hâli, 3000 üzerinde tek bir private listener, bir ingress route ve belgelenmiş bir state sınırından oluşur. Metabase için network contract, analytics source'larından ayrı özel bir Postgres uygulama veritabanıdır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Metabase'e scope'u sınırlandırılmış bir service credential verin.

Topolojiyi doğrulamak için temiz bir client ile salt okunur bir örnek veritabanına bağlanmayı, bir soru kaydetmeyi, bir dashboard oluşturmayı ve yapılandırılmış mail kanalı üzerinden bir subscription göndermeyi deneyin. Çalışma sırasında JVM heap'i, eşzamanlı sorguları, result caching'i ve her analytics data source'a aktarılan yükü izleyin. Sonuç, bir sonraki iyileştirmenin memory, storage, networking veya ayrı bir worker tarafında mı yapılması gerektiğini gösterir; rastgele container boyutlandırmasını teşvik etmez.

Metabase için bir Docker temel yapılandırması

Aşağıdaki komut, her harici servisi provision ediyormuş gibi davranmadan container sınırını görünür kılar.

docker run -d \
  --name metabase \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v metabase-data:/metabase-data \
  -e MB_ENCRYPTION_SECRET_KEY=replace-with-a-long-random-value \
  -e MB_DB_TYPE=h2 \
  -e MB_DB_FILE=/metabase-data/metabase.db \
  metabase/metabase:latest

Ingress'i açmadan önce çözümlenen environment'ı, mount'ları ve listener'ı inceleyin. Analytics source'larından ayrı özel bir Postgres uygulama veritabanı için gözden geçirilmiş connection ayarlarını ekleyin; private servisler için private adlar kullanın. Başarılı bir launch, docker ps çıktısında Up görünmesiyle değil, salt okunur bir örnek veritabanına bağlanabildiğiniz, bir soru kaydedebildiğiniz, bir dashboard oluşturabildiğiniz ve yapılandırılmış mail kanalı üzerinden bir subscription gönderebildiğiniz noktada tamamlanır.

Metabase deployment'ını uçtan uca kanıtlayın

Metabase için production gate, deployment'ı oluşturmamış biri tarafından da çalıştırılabilir olmalıdır. Bu kişiye pinned version'ı, hassas olmayan bir test hesabını ve şu görevi verin: salt okunur bir örnek veritabanına bağlanmak, bir soru kaydetmek, bir dashboard oluşturmak ve yapılandırılmış mail kanalı üzerinden bir subscription göndermek. Talimatlar belgelenmemiş shell erişimi gerektiriyorsa servis henüz operasyonel olarak hazır değildir.

Yalnızca container'ı değiştirerek gate'i tekrarlayın. Ardından yalnızca sorgulanan data source'ları boş infrastructure'a geri yüklemek yerine Metabase uygulama veritabanını restore edin ve kullanıcıların, collection'ların, soruların, dashboard filtrelerinin ve subscription'ların yeniden göründüğünü ve restore edilen connection metadata üzerinden çalıştığını kanıtlayın. Her iki başarılı çalıştırma sırasında JVM heap'i, eşzamanlı sorguları, result caching'i ve her analytics data source'a aktarılan yükü ölçün; beklenmeyen farklar çoğu zaman eksik bir cache, index, worker veya data mount olduğunu gösterir.

Bir failure drill ekleyin: test identity'nin analytics source'larından ayrı özel bir Postgres uygulama veritabanına erişimini geçici olarak engelleyin. Metabase anlamlı bir error üretmeli, mevcut state'i korumalı ve geçerli koşul geri geldiğinde toparlanmalıdır. Secret'ları redakte ederek timestamp'leri ve ilgili log satırlarını kaydedin. Bu kanıt, bir sonraki image veya configuration değişikliği için referans olur.

Internal ve external URL'leri doğru yönetin

Browser, API client ve Metabase tek bir origin üzerinde anlaşmalıdır. Bunu sağlamak için MB_SITE_URL değerini public HTTPS origin olarak ayarlayın. Orijinal host ve protocol'ü korurken 3000 portunun rakip bir public adres olarak erişilebilir olmamasını sağlayın.

site-down troubleshooting guide, erişilemeyen bir route ile yanıt veren bir application arasındaki farkı anlamanıza yardımcı olur. Bu ayrım burada önemlidir: dashboard source'ları durduğu hâlde uygulama veritabanı kayıptır. Yalnızca ilk sorun ingress değişiklikleriyle çözülür; ikinci sorun için Metabase log'larını, state'i veya workload'u incelemek gerekir.

Metabase'i gerçek bottleneck'i etrafında işletin

Metabase için process yerine bir transaction'ı izleyin: salt okunur bir örnek veritabanına bağlanın, bir soru kaydedin, bir dashboard oluşturun ve yapılandırılmış mail kanalı üzerinden bir subscription gönderin. Bir alert'in kısıtlanan component'i tanımlayabilmesi için latency ve error rate'i JVM heap, eşzamanlı sorgular, result caching ve her analytics data source'a aktarılan yük ile birlikte değerlendirin.

Upgrade rehearsal, Metabase uygulama veritabanı ile plugin version'larının birlikte migrate edilmesi gerektiğini kapsamalıdır; sorgulanan business database'ler bu state'in yerine geçmez. Production replacement öncesinde restore edin, migrate edin ve transaction'ı çalıştırın. Dashboard source'ları durduğu hâlde uygulama veritabanı kayıpsa, startup'ı green hâle getirmek için verileri silmeyin; version, variable'lar, mount'lar ve dependency reachability değerlerini bu sırayla karşılaştırın.

Volume'lar yalnızca ilk recovery katmanıdır

Container'ınızı optimize etmeden önce Metabase'in state'ini koruyun. Gerekli set, yalnızca sorgulanan data source'lar değil, Metabase uygulama veritabanıdır. Bootstrap'tan önce /metabase-data mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Birden fazla store'un uyumlu olması gerekiyorsa write işlemlerinin durdurulacağı ve yedeklerin alınacağı sırayı belgeleyin.

Kopyaları deployment server'ın dışında tutun ve credential veya private content içeren materyalleri encrypt edin. Recovery, kullanıcıların, collection'ların, soruların, dashboard filtrelerinin ve subscription'ların yeniden göründüğü ve restore edilen connection metadata üzerinden çalıştığı zaman başarılıdır. Kalıcı bir mount ile bağımsız bir kopya arasındaki fark persistent storage and snapshots bölümünde ele alınır.

Sınırları kaybetmeden Metabase'i Dockup üzerinde deploy edin

Bir Dockup template'i image'ı, 3000 portunu, mount'ları, health timing'i, domain'i, TLS'i ve secret delivery'yi encode etmelidir. Dockup, analytics source'larından ayrı özel bir Postgres uygulama veritabanının private kısımlarını internal networking üzerinde ayrı tutmalı ve ek bir public port expose etmemelidir. Aynı deployment, Dockup server'larını veya müşterinin bağladığı kapasiteyi hedefleyebilir.

Route aktif olduktan sonra public ayarı uygulayın ve salt okunur bir örnek veritabanına bağlanmayı, bir soru kaydetmeyi, bir dashboard oluşturmayı ve yapılandırılmış mail kanalı üzerinden bir subscription göndermeyi deneyin. Yalnızca sorgulanan data source'ları değil, Metabase uygulama veritabanını da yedekleyin ve restore exercise'ını operating plan'a ekleyin; bunlar infrastructure provisioning sonrasında da görünür kalan Metabase sorumluluklarıdır.

Sık sorulan sorular

Production deployment için Metabase'in neye ihtiyacı vardır?

Metabase container'ını 3000 portu üzerinden tek bir HTTPS origin'e route edin. Supporting network gereksinimi, analytics source'larından ayrı özel bir Postgres uygulama veritabanıdır. Salt okunur bir örnek veritabanına bağlanamadığınız, bir soru kaydedemediğiniz, bir dashboard oluşturamadığınız ve yapılandırılmış mail kanalı üzerinden bir subscription gönderemediğiniz sürece Metabase'i hazır kabul etmeyin.

Hangi Metabase verileri yedekte yer almalıdır?

/metabase-data path'ini kalıcı hâle getirin ve aynı recovery manifest'ine yalnızca sorgulanan data source'ları değil, Metabase uygulama veritabanını da ekleyin. Temiz bir Metabase restore'u yalnızca kullanıcılar, collection'lar, sorular, dashboard filtreleri ve subscription'lar yeniden göründüğünde ve restore edilen connection metadata üzerinden çalıştığında başarılı sayılır.

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

Public Metabase origin'i için HTTPS kullanın ve 3000 portunu internal route üzerinde tutun. Metabase ayarını doğru şekilde uygulayın: MB_SITE_URL değerini public HTTPS origin olarak ayarlayın. Metabase için HTTPS, credential'ları veya kullanıcı içeriğini transit hâlinde korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Bir Metabase upgrade'i nasıl test edilmelidir?

Mevcut Metabase state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Metabase uygulama veritabanı ile plugin version'larının birlikte migrate edilmesi gerektiğinden bu noktaya özellikle dikkat edin; sorgulanan business database'ler bu state'in yerine geçmez. Data migration ve rollback sınırı anlaşılana kadar önceki Metabase image'ını saklayın.