Héberger Metabase soi-même avec Postgres

La plupart des outils de BI facturent par siège, ce qui transforme « laissez toute l’équipe voir le tableau de bord » en ligne budgétaire qui grossit chaque fois que quelqu’un de nouveau a besoin d’accès. Metabase est un outil d’analyse libre-service à code source ouvert qui fait le travail de base, connecter une base de données, construire des graphiques et des tableaux de bord, laisser des gens non techniques poser des questions sans écrire de SQL, sans facture par siège une fois que ça tourne sur votre propre serveur. Ce guide le met en place avec sa propre base de données Postgres pour stocker les tableaux de bord et les questions, derrière Caddy pour le HTTPS, puis montre le raccourci en un clic.

À la fin, vous aurez Metabase qui tourne sur votre propre domaine, connecté à son propre entrepôt de métadonnées, prêt à pointer vers n’importe quelle base de données ou entrepôt que vous voulez réellement analyser.

Ce qu’il vous faut

• Un serveur. Metabase lui-même est une application JVM aux besoins modestes pour une petite équipe ; un Hetzner CX23 (2 vCPU, 4 Go de RAM, 40 Go NVMe) à 5,99 € par mois avant taxes fait tourner Metabase et son propre Postgres confortablement. Un usage de tableaux de bord plus lourd ou de grands jeux de résultats veulent plus de mémoire ; un CX33 (4 vCPU, 8 Go, 8,99 € par mois) est l’étape suivante.
• Un domaine ou sous-domaine avec un enregistrement DNS A pointé vers le serveur (ce guide utilise bi.example.com).
• Un accès SSH et environ 15 minutes.
• Optionnellement, la base de données ou l’entrepôt que vous voulez réellement que Metabase interroge. Ce guide met en place seulement la base de données applicative de Metabase ; connecter votre vraie source de données se fait depuis l’application après la première connexion.

Étape 1 : provisionner le serveur et pointer le DNS

bi.example.com.  A  203.0.113.40

ssh root@203.0.113.40
apt update && apt upgrade -y

Étape 2 : installer Docker

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

docker --version
docker compose version

Étape 3 : écrire le fichier d’environnement

mkdir -p /opt/metabase && cd /opt/metabase

DB_NAME=metabase
DB_USER=metabase
DB_PASSWORD=change-this-to-a-random-string

Ce mot de passe est pour la propre base de données Postgres de Metabase, celle qui contient les tableaux de bord, les questions sauvegardées et les comptes utilisateurs, pas la source de données que vous allez éventuellement connecter.

Étape 4 : écrire le fichier Docker Compose

Ce guide utilise la version stable actuelle, Metabase v0.64.3.4, fixée explicitement plutôt que latest pour qu’une publication en amont sans rapport ne puisse pas changer votre pile sous vos pieds :

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data
      - caddy-config:/config

  metabase:
    image: metabase/metabase:v0.64.3.4
    restart: unless-stopped
    environment:
      MB_DB_TYPE: postgres
      MB_DB_HOST: db
      MB_DB_PORT: "5432"
      MB_DB_DBNAME: ${DB_NAME}
      MB_DB_USER: ${DB_USER}
      MB_DB_PASS: ${DB_PASSWORD}
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/api/health || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 10

  db:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${DB_NAME}
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - metabase-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${DB_USER} -d ${DB_NAME}"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  metabase-db-data:
  caddy-data:
  caddy-config:

MB_DB_TYPE, MB_DB_HOST, MB_DB_PORT, MB_DB_DBNAME, MB_DB_USER et MB_DB_PASS sont les variables d’environnement exactes que la documentation de Metabase spécifie pour le pointer vers une base de données Postgres externe plutôt que la base H2 intégrée vers laquelle il se replie sans elles, qui n’est pas prévue pour autre chose qu’un essai rapide. Validez le fichier :

docker compose config

Étape 5 : écrire le Caddyfile

bi.example.com {
    reverse_proxy metabase:3000
}

Étape 6 : démarrer la pile

docker compose up -d
docker compose ps

Vous devriez voir caddy, metabase et db tous running, avec metabase rapportant healthy une fois son propre démarrage terminé, ce qui prend une minute ou deux au premier démarrage puisqu’il initialise son schéma de métadonnées dans Postgres. Suivez les journaux si ça prend plus longtemps :

docker compose logs -f metabase

Visitez https://bi.example.com ; vous devriez arriver sur l’assistant de configuration initiale de Metabase avec un certificat HTTPS valide.

Étape 7 : terminer la configuration et connecter une vraie source de données

L’assistant de configuration crée directement votre compte admin, pas de mot de passe par défaut à changer ensuite comme certaines applications auto-hébergées. Une fois connecté, ajoutez la base de données que vous voulez réellement analyser depuis Settings → Admin settings → Databases → Add a database. C’est une connexion séparée du conteneur Postgres de l’étape 4, qui ne stocke que les propres questions et tableaux de bord de Metabase, pas vos données.

Étape 8 : sauvegarder la base de métadonnées

Les tableaux de bord, questions sauvegardées et comptes utilisateurs vivent dans le conteneur Postgres de l’étape 4, pas dans les sources de données que vous connectez. Sauvegardez-le sur un horaire :

docker compose exec -T db pg_dump -U ${DB_USER} ${DB_NAME} | gzip > /opt/metabase/backups/metabase-$(date +%F).sql.gz

Copiez le fichier hors du serveur via une tâche cron. Le restaurer après une installation fraîche vous redonne vos tableaux de bord et questions ; vos vraies sources de données ne sont affectées dans aucun cas puisqu’elles ne sont pas stockées ici.

Étape 9 : mises à jour

docker compose pull metabase
docker compose up -d metabase

Vérifiez les notes de version de Metabase avant de sauter plusieurs versions majeures ; il exécute ses propres migrations de base de données automatiquement au démarrage, et une sauvegarde de l’étape 8 au préalable est une assurance peu coûteuse contre un pépin.

Le raccourci : faites-le avec Railyard

Tout ce qui précède, les deux conteneurs, le fichier d’environnement, le proxy inverse, est ce que le gabarit de pile Metabase + Postgres de Railyard met en place pour vous. Choisissez-le dans le catalogue de gabarits : https://app.railyard.run/deploy?stack=metabase-postgres. Railyard provisionne Metabase et une instance Postgres dédiée ensemble et relie la connexion automatiquement, donc rien à connecter à la main. La même séparation que l’étape 7 s’applique toujours : cette instance Postgres est l’entrepôt de métadonnées propre à Metabase, et votre vrai entrepôt ou base de données de production se connecte séparément depuis Settings → Databases après la première connexion. À partir de là, les sauvegardes de base de données tournent sur un horaire et se restaurent en un clic.

Dépannage

Le HTTPS ne s’émet jamais. Le DNS ne pointe pas encore vers le serveur. dig +short bi.example.com devrait retourner l’IP du serveur.

Le conteneur Metabase redémarre en boucle juste après le démarrage. Vérifiez d’abord docker compose logs metabase pour une erreur de connexion à la base de données ; la cause la plus courante est MB_DB_PASS qui ne correspond pas à ce qui est réellement dans l’environnement du conteneur db, habituellement parce que .env n’était pas présent ou mal nommé quand la pile a démarré la première fois.

La première connexion prend longtemps, ou expire dans le navigateur. Metabase exécute ses propres migrations de schéma contre Postgres au premier démarrage, ce qui peut prendre une minute ou deux selon la vitesse du serveur. Vérifiez que docker compose logs metabase progresse toujours plutôt que d’assumer que quelque chose est brisé.

Les tableaux de bord sont lents à charger. C’est plus souvent la source de données que Metabase interroge que Metabase lui-même ; de grandes requêtes non indexées contre une base de production seront lentes peu importe qui les demande. Vérifiez la performance des requêtes contre la base connectée réelle, et envisagez une réplique de lecture pour une charge de reporting lourde si la base de production elle-même est sous pression.

Manque de mémoire sur un petit serveur. La JVM sur laquelle Metabase tourne a de vrais besoins de mémoire de base ; un CX23 suffit pour une petite équipe, mais si vous faites aussi tourner d’autres conteneurs sur la même machine, docker compose ps montrant metabase comme exited combiné à dmesg | grep -i "out of memory" le confirme, et la solution est soit plus de mémoire, soit moins de choses partageant ce serveur.

FAQ

Puis-je connecter plus d’une base de données ? Oui, autant que vous voulez, chacune configurée séparément depuis Settings → Databases ; Metabase lui-même n’a besoin que de la seule instance Postgres de ce guide pour son propre stockage peu importe combien de sources vous lui connectez.

Metabase a-t-il besoin d’un accès internet pour fonctionner ? Non, une fois installé il tourne entièrement contre sa propre base Postgres et les sources de données que vous connectez, sans dépendance sortante pour le fonctionnement quotidien.

Quelle est la différence entre la version à code source ouvert et les versions payantes ? L’édition à code source ouvert couvre les tableaux de bord, questions, alertes et le constructeur de requêtes que ce guide met en place ; les paliers payants de Metabase ajoutent des choses comme le SSO, les journaux d’audit et le marque blanche visant de plus grandes organisations, dont ce guide n’a pas besoin.

Des gens non techniques peuvent-ils vraiment utiliser ça sans apprendre le SQL ? C’est la fonctionnalité précise autour de laquelle Metabase est construit : son constructeur de questions permet à quelqu’un de filtrer, grouper et visualiser des données via une interface visuelle, avec le SQL disponible en option pour quiconque le veut plutôt qu’une exigence.

En quoi est-ce moins cher qu’un outil de BI hébergé ? Le coût d’un outil hébergé par siège grandit avec le nombre de personnes dans l’entreprise qui ont besoin d’un tableau de bord ; un CX23 à environ six euros par mois coûte pareil que trois ou trente personnes le consultent.

Puis-je faire tourner Metabase sans Docker ? Oui, il est aussi distribué comme simple fichier JAR que vous lancez directement avec une JVM, ce que certaines équipes préfèrent sur un serveur qui gère déjà des déploiements Java ; l’image Docker est le chemin que ce guide et le gabarit de Railyard utilisent tous les deux, puisqu’elle garde la version de la JVM et les dépendances fixées à côté de l’application elle-même plutôt que de dépendre de ce qui est déjà installé sur l’hôte.

Metabase donne à une équipe des tableaux de bord en libre-service sans transformer « une personne de plus a besoin d’accès » en conversation de facturation. La configuration ici tient en deux conteneurs, un fichier d’environnement et un proxy inverse ; à partir de là, c’est le même constructeur de questions et les mêmes tableaux de bord, tournant sur un serveur à coût mensuel fixe plutôt qu’un coût qui grandit avec l’effectif.