Så självhostar du Metabase 2026: applikationsdatabas, TLS och säkerhetskopior

Om du redan har försökt självhosta Metabase känner du troligen igen det frustrerande läget: gränssnittet visas, men applikationsdatabasen saknas trots att databaserna som dashboarderna hämtar data från finns kvar. Att skapa om containern löser sällan en konflikt mellan URL:er, state och beroenden.

Den här genomgången använder ett konkret kriterium för en komplett installation: anslut en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen. Varje konfigurationsval bedöms utifrån detta kriterium, inte utifrån en grön containerstatus.

Autentiseringsuppgifter, roller och exponerade ytor

Skapa en threat model för den åtgärd Metabase utför, inte bara för inloggningsformuläret. Det mest riskfyllda misstaget här är att använda den inbäddade H2-applikationsdatabasen som enda produktionskopia. Sätt denna gräns: ge Metabase skrivskyddade databasroller där det är möjligt och separera behörigheter för collections från databasens autentiseringsuppgifter.

Generera MB_ENCRYPTION_SECRET_KEY en gång, håll den utanför Git och bevara den tillsammans med recovery-manifestet, eftersom en ändring kan göra krypterad eller signerad applikationsdata ogiltig. Lös inte ett behörighetsfel genom att köra containern som root eller montera värdsystemet brett. Resursbegränsningar hör också till säkerhetsdesignen, eftersom JVM-heap, samtidiga frågor, result caching och belastningen på varje datakälla för analys kan utlösas av användare.

Separera Metabase från dess beroenden

Den minsta ansvarsfulla Metabase-topologin innehåller en privat listener på port 3000, en ingress-route och en dokumenterad state-gräns. Metabases nätverkskontrakt är en dedikerad Postgres-applikationsdatabas som är separat från analyskällorna. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Metabase en avgränsad service credential.

Validera topologin genom att låta en ren klient ansluta en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen. Övervaka JVM-heap, samtidiga frågor, result caching och belastningen på varje datakälla för analys medan detta körs. Resultatet visar om nästa förbättring hör hemma i minne, lagring, nätverk eller en separat worker, i stället för att uppmuntra till godtycklig containerskalning.

En Docker-bas för Metabase

Följande kommando gör containergränsen tydlig utan att låtsas tillhandahålla alla externa tjänster.

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

Innan du öppnar ingressen ska du inspektera den slutliga miljön, monterade volymer och listenern. Lägg till de granskade anslutningsinställningarna för en dedikerad Postgres-applikationsdatabas som är separat från analyskällorna och använd privata namn för privata tjänster. En lyckad start är klar först när du kan ansluta en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen – inte när docker ps skriver ut Up.

Verifiera Metabase-installationen från början till slut

En produktionsspärr för Metabase ska kunna köras av någon som inte byggde installationen. Ge personen den fixerade versionen, ett icke-känsligt testkonto och följande uppgift: anslut en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen. Om instruktionerna kräver odokumenterad shell-åtkomst är tjänsten ännu inte driftklar.

Upprepa kontrollen efter att endast ha bytt ut containern. Återställ sedan Metabases applikationsdatabas – inte bara efterfrågade datakällor – till en tom infrastruktur och verifiera att användare, collections, frågor, dashboardfilter och prenumerationer kommer tillbaka och körs mot den återställda anslutningsmetadata. Mät JVM-heap, samtidiga frågor, result caching och belastningen på varje datakälla för analys under båda lyckade körningarna. Oväntade skillnader avslöjar ofta en cache, ett index, en worker eller en datamontering som saknas.

Lägg till en failure drill: neka tillfälligt testidentiteten åtkomst till en dedikerad Postgres-applikationsdatabas som är separat från analyskällorna. Metabase ska skriva ut ett användbart fel, bevara befintlig state och återhämta sig när det korrekta tillståndet återställs. Spara tidsstämplar och relevanta loggrader, med hemligheter borttagna. Denna evidens blir referens för nästa image- eller konfigurationsändring.

Håll interna och externa URL:er åtskilda

Webbläsaren, API-klienten och Metabase måste vara överens om en och samma origin. För att säkerställa detta ställer du in MB_SITE_URL till den publika HTTPS-originen. Bevara det ursprungliga värdnamnet och protokollet samtidigt som port 3000 inte är tillgänglig som en konkurrerande publik adress.

Guiden för felsökning när webbplatsen ligger nere hjälper dig skilja en otillgänglig route från en applikation som svarar. Den skillnaden är viktig här: applikationsdatabasen saknas trots att databaserna som dashboarderna hämtar data från finns kvar. Endast det första problemet löses genom ändringar i ingressen; det andra kräver granskning av Metabase-loggar, state eller arbetsbelastning.

Drifta Metabase utifrån dess verkliga flaskhals

För Metabase ska du övervaka en transaktion i stället för en process: anslut en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen. Kombinera latency och felfrekvens med JVM-heap, samtidiga frågor, result caching och belastningen på varje datakälla för analys, så att en alert identifierar vilken komponent som är begränsande.

Uppgraderingsrepetitionen måste omfatta att Metabases applikationsdatabas och pluginversioner måste migreras tillsammans. Efterfrågade affärsdatabaser ersätter inte denna state. Återställ, migrera och kör transaktionen innan du byter i produktion. Om applikationsdatabasen saknas trots att databaserna som dashboarderna hämtar data från finns kvar ska du inte radera data för att få en grön start. Jämför version, variabler, monteringar och nåbarhet till beroenden i den ordningen.

Volymer är bara det första återställningslagret

Skydda Metabases state innan du optimerar containern. Det som krävs är Metabases applikationsdatabas, inte bara efterfrågade datakällor. Montera /metabase-data före bootstrap, skriv ofarliga testdata och byt ut containern för att verifiera att sökvägen faktiskt är persistent. Om flera lagringsplatser måste vara synkroniserade ska du dokumentera i vilken ordning skrivningar pausas och säkerhetskopior tas.

Förvara kopior utanför deployments server och kryptera material som innehåller autentiseringsuppgifter eller privat innehåll. Återställningen är lyckad när användare, collections, frågor, dashboardfilter och prenumerationer kommer tillbaka och körs mot den återställda anslutningsmetadata. Skillnaden mellan en persistent montering och en fristående kopia beskrivs i persistent lagring och snapshots.

Distribuera Metabase på Dockup utan att förlora gränserna

En Dockup-template bör definiera imagen, port 3000, monteringar, health timing, domän, TLS och leverans av hemligheter. Dockup bör hålla privata delar av en dedikerad Postgres-applikationsdatabas separerade från analyskällorna på det interna nätverket och inte exponera någon extra publik port. Samma deployment kan köras på Dockup-servrar eller på kundansluten kapacitet.

När routen är aktiv ställer du in den publika inställningen och försöker ansluta en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen. Säkerhetskopiera Metabases applikationsdatabas, inte bara efterfrågade datakällor, och ta med återställningsövningen i driftplanen. Detta är Metabase-ansvar som fortfarande är synligt efter att infrastrukturen har provisionerats.

Vanliga frågor

Vad behöver Metabase för en produktionsinstallation?

Routa Metabase-containern på port 3000 via en enda HTTPS-origin. Det tillhörande nätverkskravet är en dedikerad Postgres-applikationsdatabas som är separat från analyskällorna. Förklara inte Metabase som klar förrän du kan ansluta en skrivskyddad testdatabas, spara en fråga, skapa en dashboard och leverera en prenumeration via den konfigurerade e-postkanalen.

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

Gör /metabase-data persistent och inkludera Metabases applikationsdatabas, inte bara efterfrågade datakällor, i samma recovery-manifest. En ren Metabase-återställning är godkänd först när användare, collections, frågor, dashboardfilter och prenumerationer kommer tillbaka och körs mot den återställda anslutningsmetadata.

Kräver Metabase HTTPS bakom en reverse proxy?

Använd HTTPS för Metabases publika origin och håll port 3000 på den interna routen. Tillämpa Metabase-inställningen korrekt: ställ in MB_SITE_URL till den publika HTTPS-originen. För Metabase skyddar HTTPS autentiseringsuppgifter och användarinnehåll under överföring och ser till att origin-känsligt klientbeteende förblir konsekvent.

Hur ska en Metabase-uppgradering testas?

Återställ aktuell Metabase-state till en isolerad deployment, använd kandidatversionen och upprepa dess acceptanstest. Var särskilt uppmärksam på att Metabases applikationsdatabas och pluginversioner måste migreras tillsammans. Efterfrågade affärsdatabaser ersätter inte denna state. Behåll den tidigare Metabase-imagen tills gränsen för datamigrering och rollback är förstådd.