Comment auto-héberger Metabase en 2026 : base de données applicative, TLS et sauvegardes

Si vous avez déjà essayé d’auto-héberger Metabase, cet état frustrant vous est probablement familier : l’interface apparaît, mais la base de données applicative est absente alors que les bases de données sources des dashboards sont toujours présentes. Recréer le conteneur résout rarement un désaccord entre les URL, l’état de l’application et ses dépendances.

Cette procédure s’appuie sur un critère d’achèvement concret : connecter une base de données d’exemple en lecture seule, enregistrer une question, créer un dashboard et envoyer un abonnement via le canal d’e-mail configuré. Chaque choix de configuration est évalué par rapport à ce critère, et non à un badge vert indiquant que le conteneur fonctionne.

Identifiants, rôles et surfaces exposées

Modélisez les menaces en fonction des actions effectuées par Metabase, et pas uniquement de son formulaire de connexion. Ici, l’erreur à haut risque consiste à utiliser la base de données applicative H2 intégrée comme seule copie de production. Mettez en place cette séparation : attribuez à Metabase des rôles de base de données en lecture seule lorsque c’est possible et séparez les permissions des collections des identifiants de base de données.

Générez MB_ENCRYPTION_SECRET_KEY une seule fois, conservez-la en dehors de Git et préservez-la avec le manifest de récupération, car sa modification peut invalider l’état applicatif chiffré ou signé. Ne résolvez pas une erreur de permission en exécutant le conteneur en tant que root ou en montant largement le système hôte. Les limites de ressources font également partie de la conception de sécurité lorsque le heap JVM, les requêtes concurrentes, la mise en cache des résultats et la charge transférée à chaque source de données analytiques peuvent être déclenchés par les utilisateurs.

Séparer Metabase de ses dépendances

La topologie Metabase minimale et responsable contient un listener privé sur le port 3000, une route d’ingress et une limite d’état documentée. Le contrat réseau de Metabase repose sur une base de données applicative Postgres dédiée, distincte des sources de données analytiques. Conservez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Metabase un identifiant de service avec une portée limitée.

Validez la topologie en demandant à un client vierge de connecter une base de données d’exemple en lecture seule, d’enregistrer une question, de créer un dashboard et d’envoyer un abonnement via le canal d’e-mail configuré. Surveillez le heap JVM, les requêtes concurrentes, la mise en cache des résultats et la charge transférée à chaque source de données analytiques pendant l’exécution. Le résultat indique si la prochaine amélioration doit concerner la mémoire, le stockage, le réseau ou un worker séparé, au lieu d’encourager un dimensionnement arbitraire du conteneur.

Une configuration Docker de base pour Metabase

La commande suivante rend la limite du conteneur visible sans prétendre provisionner tous les services externes.

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

Avant d’ouvrir l’ingress, inspectez l’environnement résolu, les mounts et le listener. Ajoutez les paramètres de connexion validés pour une base de données applicative Postgres dédiée, distincte des sources de données analytiques ; utilisez des noms privés pour les services privés. Un lancement réussi se termine lorsque vous pouvez connecter une base de données d’exemple en lecture seule, enregistrer une question, créer un dashboard et envoyer un abonnement via le canal d’e-mail configuré, et non lorsque docker ps affiche Up.

Valider le déploiement Metabase de bout en bout

Une étape de validation de production pour Metabase doit pouvoir être exécutée par une personne qui n’a pas créé le déploiement. Donnez-lui la version épinglée, un compte de test non sensible et cette tâche : connecter une base de données d’exemple en lecture seule, enregistrer une question, créer un dashboard et envoyer un abonnement via le canal d’e-mail configuré. Si les instructions nécessitent un accès shell non documenté, le service n’est pas encore prêt pour l’exploitation.

Répétez cette validation après avoir remplacé uniquement le conteneur. Restaurez ensuite la base de données applicative Metabase, et pas seulement les sources de données interrogées, dans une infrastructure vierge, puis vérifiez que les utilisateurs, les collections, les questions, les filtres des dashboards et les abonnements réapparaissent et s’exécutent avec les métadonnées de connexion restaurées. Mesurez le heap JVM, les requêtes concurrentes, la mise en cache des résultats et la charge transférée à chaque source de données analytiques pendant les deux exécutions réussies ; des différences inattendues révèlent souvent l’absence d’un cache, d’un index, d’un worker ou d’un montage de données.

Ajoutez un test de panne : refusez temporairement à l’identité de test l’accès à une base de données applicative Postgres dédiée, distincte des sources de données analytiques. Metabase doit produire une erreur utile, préserver l’état existant et récupérer lorsque la condition valide est rétablie. Enregistrez les horodatages et les lignes de logs pertinentes, après avoir masqué les secrets. Ces éléments deviennent la référence pour la prochaine modification d’image ou de configuration.

Garder les URL internes et externes cohérentes

Le navigateur, le client API et Metabase doivent utiliser une même origine. Pour y parvenir, définissez MB_SITE_URL sur l’origine HTTPS publique. Conservez l’hôte et le protocole d’origine tout en empêchant le port 3000 de devenir une adresse publique concurrente.

Le guide de dépannage d’un site inaccessible aide à distinguer une route inaccessible d’une application qui répond. Cette distinction est importante ici : la base de données applicative est absente alors que les bases de données sources des dashboards sont toujours présentes. Seule la première situation se résout par des modifications de l’ingress ; la seconde nécessite d’examiner les logs, l’état ou la charge de travail de Metabase.

Exploiter Metabase en fonction de son véritable goulot d’étranglement

Pour Metabase, surveillez une transaction plutôt qu’un processus : connecter une base de données d’exemple en lecture seule, enregistrer une question, créer un dashboard et envoyer un abonnement via le canal d’e-mail configuré. Associez sa latence et son taux d’erreur au heap JVM, aux requêtes concurrentes, à la mise en cache des résultats et à la charge transférée à chaque source de données analytiques afin qu’une alerte identifie le composant limité.

La répétition générale de la mise à niveau doit prendre en compte le fait que la base de données applicative Metabase et les versions des plugins doivent migrer ensemble ; les bases de données métier interrogées ne remplacent pas cet état. Restaurez, migrez et exécutez la transaction avant le remplacement en production. Si la base de données applicative est absente alors que les bases de données sources des dashboards sont toujours présentes, n’effacez pas les données pour obtenir un démarrage au vert ; comparez dans cet ordre la version, les variables, les mounts et l’accessibilité des dépendances.

Les volumes ne constituent que la première couche de récupération

Protégez l’état de Metabase avant d’optimiser son conteneur. L’ensemble requis est la base de données applicative Metabase, et pas uniquement les sources de données interrogées. Montez /metabase-data avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Si plusieurs stockages doivent rester cohérents, documentez l’ordre dans lequel les écritures sont suspendues et les sauvegardes effectuées.

Conservez des copies en dehors du serveur de déploiement et chiffrez les éléments contenant des identifiants ou du contenu privé. La récupération est réussie lorsque les utilisateurs, les collections, les questions, les filtres des dashboards et les abonnements réapparaissent et s’exécutent avec les métadonnées de connexion restaurées. La distinction entre un mount persistant et une copie indépendante est expliquée dans stockage persistant et snapshots.

Déployer Metabase sur Dockup sans perdre ces limites

Un template Dockup doit définir l’image, le port 3000, les mounts, les délais de health check, le domaine, le TLS et la distribution des secrets. Dockup doit conserver les éléments privés d’une base de données applicative Postgres dédiée séparés des sources de données analytiques sur le réseau interne et n’exposer aucun port public supplémentaire. Le même déploiement peut cibler des serveurs Dockup ou une capacité rattachée par le client.

Une fois la route active, appliquez le paramètre public et essayez de connecter une base de données d’exemple en lecture seule, d’enregistrer une question, de créer un dashboard et d’envoyer un abonnement via le canal d’e-mail configuré. Sauvegardez la base de données applicative Metabase, et pas uniquement les sources de données interrogées, puis intégrez l’exercice de restauration au plan d’exploitation ; ces responsabilités liées à Metabase restent visibles après le provisionnement de l’infrastructure.

Foire aux questions

De quoi Metabase a-t-il besoin pour un déploiement en production ?

Routez le conteneur Metabase sur le port 3000 via une origine HTTPS unique. La dépendance réseau correspondante est une base de données applicative Postgres dédiée, distincte des sources de données analytiques. Ne considérez pas Metabase comme prêt tant que vous ne pouvez pas connecter une base de données d’exemple en lecture seule, enregistrer une question, créer un dashboard et envoyer un abonnement via le canal d’e-mail configuré.

Quelles données Metabase doivent être sauvegardées ?

Rendez /metabase-data persistant et incluez la base de données applicative Metabase, et pas uniquement les sources de données interrogées, dans le même manifest de récupération. Une restauration Metabase propre n’est réussie que lorsque les utilisateurs, les collections, les questions, les filtres des dashboards et les abonnements réapparaissent et s’exécutent avec les métadonnées de connexion restaurées.

Metabase nécessite-t-il le HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Metabase et conservez le port 3000 sur la route interne. Appliquez correctement le paramètre Metabase : définissez MB_SITE_URL sur l’origine HTTPS publique. Pour Metabase, HTTPS protège les identifiants ou le contenu utilisateur en transit et garantit un comportement cohérent des clients sensibles à l’origine.

Comment tester une mise à niveau de Metabase ?

Restaurez l’état actuel de Metabase dans un déploiement isolé, appliquez la version candidate et répétez sa transaction de validation. Soyez particulièrement attentif au fait que la base de données applicative Metabase et les versions des plugins doivent migrer ensemble ; les bases de données métier interrogées ne remplacent pas cet état. Conservez l’ancienne image Metabase jusqu’à ce que les limites de migration des données et de rollback soient comprises.