Sådan self-hoster du Metabase i 2026: Applikationsdatabase, TLS og backups

Hvis du allerede har prøvet at self-hoste Metabase, kender du sikkert den frustrerende situation: Brugerfladen vises, men applikationsdatabasen mangler, selvom databaserne med dashboardernes datakilder stadig findes. Det løser sjældent problemet at oprette containeren igen, hvis der er uoverensstemmelse mellem URLs, state og dependencies.

Denne gennemgang bruger ét konkret kriterium for, hvornår opsætningen er færdig — forbind en read-only sample-database, gem et spørgsmål, opbyg et dashboard, og lever en subscription via den konfigurerede mailkanal. Hvert konfigurationsvalg vurderes ud fra dette kriterium og ikke ud fra et grønt containerbadge.

Credentials, roller og eksponerede overflader

Lav en threat model for den handling, Metabase udfører, ikke kun for loginformularen. Den største risiko her er at bruge den indlejrede H2-applikationsdatabase som den eneste produktionskopi. Implementér denne grænse: Giv så vidt muligt Metabase read-only database-roller, og adskil collection permissions fra databasecredentials.

Generér MB_ENCRYPTION_SECRET_KEY én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan gøre krypteret eller signeret application state ugyldig. Løs ikke en permission-fejl ved at køre containeren som root eller mounte hosten bredt. Resource limits er også en del af sikkerhedsdesignet, når JVM heap, concurrent queries, result caching og den belastning, der overføres til hver analytics-datakilde, kan udløses af brugere.

Adskil Metabase fra dens dependencies

Den mindste ansvarlige Metabase-topologi indeholder én privat listener på 3000, en ingress-route og en dokumenteret state boundary. Metabases netværkskontrakt er en dedikeret Postgres-applikationsdatabase, der er adskilt fra analytics-kilder. Bevar private endpoints på intern DNS, tillad kun nødvendige outbound calls, og giv Metabase en servicecredential med begrænset scope.

Valider topologien ved at lade en ren klient forbinde en read-only sample-database, gemme et spørgsmål, opbygge et dashboard og levere en subscription via den konfigurerede mailkanal. Overvåg JVM heap, concurrent queries, result caching og den belastning, der overføres til hver analytics-datakilde, mens det kører. Resultatet viser, om den næste forbedring hører hjemme i memory, storage, networking eller en separat worker, i stedet for at tilskynde til vilkårlig containersizing.

Et Docker-grundlag til Metabase

Følgende kommando synliggør containergrænsen uden at foregive, at alle eksterne services bliver provisioneret.

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

Før du åbner for ingress, skal du inspicere det resolved environment, mounts og listeneren. Tilføj de gennemgåede connection settings for en dedikeret Postgres-applikationsdatabase, der er adskilt fra analytics-kilder; brug private navne til private services. En vellykket opstart er først afsluttet, når du kan forbinde en read-only sample-database, gemme et spørgsmål, opbygge et dashboard og levere en subscription via den konfigurerede mailkanal — ikke når docker ps viser Up.

Bevis Metabase-deploymentet fra ende til anden

En production gate for Metabase skal kunne udføres af en person, der ikke har bygget deploymentet. Giv personen den pinnede version, en ikke-følsom testkonto og denne opgave: Forbind en read-only sample-database, gem et spørgsmål, opbyg et dashboard, og lever en subscription via den konfigurerede mailkanal. Hvis instruktionerne kræver udokumenteret shell-adgang, er servicen endnu ikke driftsklar.

Gentag testen efter kun at have udskiftet containeren. Gendan derefter Metabase-applikationsdatabasen — ikke kun de forespurgte datakilder — i blank infrastruktur, og bevis, at brugere, collections, spørgsmål, dashboardfiltre og subscriptions dukker op igen og kører mod de gendannede connection metadata. Mål JVM heap, concurrent queries, result caching og den belastning, der overføres til hver analytics-datakilde, under begge vellykkede kørsler; uventede forskelle afslører ofte en manglende cache, et manglende index, en worker eller et data mount.

Tilføj en failure drill: Nægt midlertidigt testidentiteten adgang til en dedikeret Postgres-applikationsdatabase, der er adskilt fra analytics-kilder. Metabase skal udsende en nyttig fejl, bevare den eksisterende state og komme sig, når den gyldige betingelse vender tilbage. Gem tidsstemplerne og de relevante loglinjer med secrets redacted. Denne dokumentation bliver referencepunktet for det næste image- eller konfigurationsskift.

Hold interne og eksterne URLs adskilt

Browseren, API-klienten og Metabase skal være enige om én origin. For at sikre det skal du sætte MB_SITE_URL til den offentlige HTTPS-origin. Bevar den oprindelige host og protokol, mens port 3000 forbliver utilgængelig som en konkurrerende offentlig adresse.

Guiden til fejlfinding af et site, der er nede hjælper med at skelne mellem en utilgængelig route og en applikation, der svarer. Denne skelnen er vigtig her: Applikationsdatabasen mangler, selvom databaserne med dashboardernes datakilder stadig findes. Kun førstnævnte løses med ingress-ændringer; sidstnævnte kræver inspektion af Metabase-logs, state eller workload.

Driftssæt Metabase med fokus på den reelle flaskehals

For Metabase skal du overvåge en transaktion i stedet for en proces: Forbind en read-only sample-database, gem et spørgsmål, opbyg et dashboard, og lever en subscription via den konfigurerede mailkanal. Kombinér dens latency og error rate med JVM heap, concurrent queries, result caching og den belastning, der overføres til hver analytics-datakilde, så en alert identificerer den komponent, der er begrænset.

Upgrade-rehearsal’en skal dække, at Metabase-applikationsdatabasen og plugin-versionerne skal migreres sammen; forespurgte forretningsdatabaser er ikke en erstatning for denne state. Gendan, migrér, og kør transaktionen før udskiftning i produktion. Hvis applikationsdatabasen mangler, selvom databaserne med dashboardernes datakilder stadig findes, må du ikke slette data for at få en grøn opstart; sammenlign version, variables, mounts og dependency reachability i den rækkefølge.

Volumes er kun det første recovery-lag

Beskyt Metabases state, før du optimerer containeren. Det nødvendige sæt er Metabase-applikationsdatabasen, ikke kun de forespurgte datakilder. Mount /metabase-data før bootstrap, skriv ufarlige sampledata, og udskift containeren for at bevise, at stien faktisk er persistent. Hvis flere stores skal stemme overens, skal du dokumentere rækkefølgen, som writes sættes på pause i, og backups tages i.

Opbevar kopier uden for deployment-serveren, og krypter materiale, der indeholder credentials eller privat indhold. Recovery lykkes, når brugere, collections, spørgsmål, dashboardfiltre og subscriptions dukker op igen og kører mod de gendannede connection metadata. Forskellen mellem et persistent mount og en uafhængig kopi er beskrevet i persistent storage og snapshots.

Deploy Metabase på Dockup uden at miste dets grænser

En Dockup-template bør indeholde image, port 3000, mounts, health timing, domain, TLS og secret delivery. Dockup bør holde de private dele af en dedikeret Postgres-applikationsdatabase adskilt fra analytics-kilder på internt netværk og ikke eksponere ekstra offentlige porte. Den samme deployment kan målrettes Dockup-servere eller kundetilknyttet kapacitet.

Når routen er live, skal du anvende den offentlige indstilling og forsøge at forbinde en read-only sample-database, gemme et spørgsmål, opbygge et dashboard og levere en subscription via den konfigurerede mailkanal. Tag backup af Metabase-applikationsdatabasen, ikke kun de forespurgte datakilder, og medtag restore-øvelsen i driftsplanen; det er Metabase-ansvar, som fortsat er synligt efter infrastrukturprovisionering.

Ofte stillede spørgsmål

Hvad skal Metabase bruge til en produktionsdeployment?

Route Metabase-containeren via port 3000 gennem én HTTPS-origin. Det understøttende netværkskrav er en dedikeret Postgres-applikationsdatabase, der er adskilt fra analytics-kilder. Kald ikke Metabase klar, før du kan forbinde en read-only sample-database, gemme et spørgsmål, opbygge et dashboard og levere en subscription via den konfigurerede mailkanal.

Hvilke Metabase-data skal med i en backup?

Gør /metabase-data persistent, og medtag Metabase-applikationsdatabasen — ikke kun de forespurgte datakilder — i det samme recovery-manifest. En ren Metabase-restore er kun vellykket, når brugere, collections, spørgsmål, dashboardfiltre og subscriptions dukker op igen og kører mod de gendannede connection metadata.

Kræver Metabase HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Metabase-origin, og behold port 3000 på den interne route. Anvend Metabase-indstillingen korrekt: Sæt MB_SITE_URL til den offentlige HTTPS-origin. For Metabase beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-følsom klientadfærd.

Hvordan skal en Metabase-upgrade testes?

Gendan den aktuelle Metabase-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi Metabase-applikationsdatabasen og plugin-versionerne skal migreres sammen; forespurgte forretningsdatabaser er ikke en erstatning for denne state. Behold det tidligere Metabase-image, indtil data-migrationens og rollbackens grænser er forstået.