Comment auto-héberger NocoDB en 2026 : connexions aux bases de données, authentification et persistance

Il existe deux façons de « faire fonctionner NocoDB » : un conteneur existe, ou le service remplit réellement sa fonction. Seule la seconde compte. Pour le vérifier, connectez une base de données source temporaire, créez une grille et une vue filtrée, modifiez une ligne, ajoutez une pièce jointe et appelez l'API REST.

NocoDB sert précisément à cela : fournir une interface de type tableur au-dessus d'une véritable base de données. Le déploiement doit préserver les composants nécessaires à ce fonctionnement ; un port, un volume et un certificat sont des prérequis, pas le résultat.

Délimiter l'environnement d'exécution de NocoDB

L'état du processus et celui du produit sont deux choses distinctes pour NocoDB. Le port 8080 peut répondre alors que la transaction côté utilisateur échoue toujours. En production, le contrat réseau de NocoDB repose sur PostgreSQL ou MySQL pour les métadonnées, plutôt que sur un fichier local temporaire. Conservez les endpoints privés sur un DNS interne, n'autorisez que les appels sortants nécessaires et attribuez à NocoDB des identifiants de service aux permissions limitées.

Utilisez ce test de readiness après toute modification importante de la configuration : connectez une base de données source temporaire, créez une grille et une vue filtrée, modifiez une ligne, ajoutez une pièce jointe et appelez l'API REST. Évitez d'inclure des contrôles externes coûteux dans les probes de liveness afin qu'une panne de fournisseur ne provoque pas une boucle de redémarrage. Le suivi de la capacité doit couvrir le nombre de lignes, le trafic des pièces jointes, la latence de la base de données de métadonnées et le nombre d'utilisateurs simultanés des grilles, des indicateurs plus représentatifs de la charge réelle de NocoDB que les requêtes de pages.

Lancer NocoDB avec des valeurs par défaut observables

Démarrez NocoDB de manière à garder la route privée jusqu'à la fin du bootstrap.

docker run -d \
  --name nocodb \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v nocodb-data:/usr/app/data \
  -e NC_AUTH_JWT_SECRET=replace-with-a-long-random-value \
  nocodb/nocodb:latest

Si le processus redémarre en boucle, comparez l'utilisateur attendu par l'image avec le propriétaire de chaque chemin monté. S'il reste actif, testez localement le port 8080, puis passez directement au workflow : connectez une base de données source temporaire, créez une grille et une vue filtrée, modifiez une ligne, ajoutez une pièce jointe et appelez l'API REST. Ne figez la version de l'image qu'après la réussite de ce contrôle de bout en bout, puis consignez la configuration exacte à côté du service.

Domaines, en-têtes de proxy et port 8080

Choisissez le hostname NocoDB définitif avant que les utilisateurs n'enregistrent des callbacks ou des paramètres client, puis définissez NC_PUBLIC_URL sur l'adresse HTTPS canonique. La route de la plateforme doit terminer TLS une seule fois et cibler le port privé 8080.

Exécutez la transaction d'acceptation depuis l'extérieur. Si le client n'atteint jamais NocoDB, utilisez la checklist de validation SSL pour vérifier le DNS et le certificat. Si la requête atteint NocoDB, mais que la base de données de métadonnées est inaccessible ou que les URLs publiques pointent vers un hôte interne, cessez de modifier les redirections du proxy et inspectez plutôt la limite propre à l'application.

Concevoir la restauration de NocoDB avant le lancement

Définissez les objectifs de point et de délai de récupération de NocoDB en tenant compte de la base de données de métadonnées, des pièces jointes et des éventuelles bases de données source externes. Montez /usr/app/data avant le bootstrap, écrivez des données d'exemple sans risque, puis remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Un volume nommé garantit la persistance lors d'un redeploy ; il ne protège ni contre une compromission ni contre la perte du serveur.

Préparez un environnement de restauration propre, utilisez la même version d'application figée et vérifiez que les bases, les vues, les rôles, les pièces jointes et les mappings des sources sont restaurés sans modifier les lignes de la base de données connectée. Consignez les commandes, les corrections de propriétaires et le temps écoulé. Le guide des sauvegardes constitue une bonne référence : une sauvegarde n'est considérée comme fiable qu'après sa restauration, pas après son upload.

Décisions de sécurité propres à NocoDB

Fermez la fenêtre de bootstrap dès que le premier administrateur de confiance existe. Le piège concret de NocoDB consiste à réutiliser un secret JWT faible ou à exposer les identifiants des bases à chaque éditeur ; la limite la plus sûre consiste à utiliser un secret JWT stable, à limiter les personnes autorisées à créer des connexions vers des sources de données externes et à contrôler l'exposition des vues partagées.

Générez NC_AUTH_JWT_SECRET avec une valeur aléatoire longue ; sa rotation invalide généralement les sessions ou les tokens, prévoyez donc son impact sur les utilisateurs au lieu de la traiter comme une migration de chiffrement. Le réseau privé doit transporter les identifiants des dépendances, et les rôles au sein de NocoDB doivent accorder uniquement les permissions nécessaires. Excluez des logs courants les corps de requête sensibles et les réponses des fournisseurs.

Contrôles de capacité et de mise à niveau

Un conteneur au vert est nécessaire, mais pas suffisant. L'indicateur de niveau de service est la réussite de la transaction « connecter une base de données source temporaire, créer une grille et une vue filtrée, modifier une ligne, ajouter une pièce jointe et appeler l'API REST », tandis que les principaux signaux de charge probable sont le nombre de lignes, le trafic des pièces jointes, la latence de la base de données de métadonnées et le nombre d'utilisateurs simultanés des grilles.

La gestion des changements est importante, car les migrations de métadonnées peuvent affecter les vues et les automatisations même si la base de données source sous-jacente n'est pas modifiée. Conservez l'ancienne image, testez les migrations sur une copie de l'état et documentez la prise en charge éventuelle du rollback après la modification du schéma. Si la base de données de métadonnées est inaccessible ou que les URLs publiques pointent vers un hôte interne, diagnostiquez d'abord la limite qui diffère de l'environnement fonctionnel.

Procédure d'acceptation de NocoDB en production

Avant l'arrivée des vrais utilisateurs, préparez une fiche de release pour NocoDB. Elle doit indiquer l'image figée, le port 8080, l'origine canonique, les chemins persistants et le propriétaire de PostgreSQL ou MySQL pour les métadonnées en production, plutôt qu'un fichier local temporaire. Ajoutez le résultat attendu de cette transaction : connecter une base de données source temporaire, créer une grille et une vue filtrée, modifier une ligne, ajouter une pièce jointe et appeler l'API REST.

Utilisez cette fiche après un remplacement normal et après une restauration propre. La récupération n'est acceptée que si les bases, les vues, les rôles, les pièces jointes et les mappings des sources sont restaurés sans modifier les lignes de la base de données connectée. Relevez également une courte trace des ressources couvrant le nombre de lignes, le trafic des pièces jointes, la latence de la base de données de métadonnées et le nombre d'utilisateurs simultanés des grilles ; conservez-la avec la release afin de comparer les futurs changements de capacité sur la base de la même charge.

Incluez un échec contrôlé : refusez temporairement à l'identité de test l'accès à PostgreSQL ou MySQL pour les métadonnées en production, plutôt qu'à un fichier local temporaire. Vérifiez que NocoDB signale le problème à la bonne limite, rétablissez la condition valide et relancez la transaction. Cela vérifie la visibilité des erreurs, et pas seulement la réussite, et empêche une interface apparemment saine de dissimuler un worker, un callback ou une connexion à la base de données défaillant.

Comment Dockup réduit le travail nécessaire pour NocoDB

Pour NocoDB, Dockup est particulièrement utile à la frontière entre une image et un service durable. Il maintient la route vers 8080, TLS, les valeurs des secrets et le stockage associés lors des remplacements de conteneurs, que le calcul soit fourni par Dockup ou par votre serveur connecté.

Terminez avec les vérifications propres à l'application : définissez NC_PUBLIC_URL sur l'adresse HTTPS canonique ; connectez et testez PostgreSQL ou MySQL pour les métadonnées en production, plutôt qu'un fichier local temporaire ; puis exécutez cette vérification : connectez une base de données source temporaire, créez une grille et une vue filtrée, modifiez une ligne, ajoutez une pièce jointe et appelez l'API REST. Conservez le résultat comme contrôle de déploiement afin que la prochaine mise à jour de l'image soit évaluée sur son comportement plutôt que sur l'état du conteneur.

Foire aux questions

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

Acheminez le conteneur NocoDB sur le port 8080 via une seule origine HTTPS. La prérequis réseau associé est PostgreSQL ou MySQL pour les métadonnées en production, plutôt qu'un fichier local temporaire. Ne considérez pas NocoDB comme prêt tant que vous ne pouvez pas connecter une base de données source temporaire, créer une grille et une vue filtrée, modifier une ligne, ajouter une pièce jointe et appeler l'API REST.

Quelles données NocoDB doivent figurer dans une sauvegarde ?

Rendez /usr/app/data persistant et incluez la base de données de métadonnées, les pièces jointes et les éventuelles bases de données source externes dans le même manifeste de récupération. Une restauration propre de NocoDB n'est validée que si les bases, les vues, les rôles, les pièces jointes et les mappings des sources sont restaurés sans modifier les lignes de la base de données connectée.

NocoDB a-t-il besoin de HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l'origine publique de NocoDB et conservez le port 8080 sur la route interne. Appliquez correctement le paramètre NocoDB : définissez NC_PUBLIC_URL sur l'adresse HTTPS canonique. Pour NocoDB, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent des clients dépendant de l'origine.

Comment tester une mise à niveau de NocoDB ?

Restaurez l'état actuel de NocoDB dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d'acceptation. Soyez particulièrement attentif, car les migrations de métadonnées peuvent affecter les vues et les automatisations même si la base de données source sous-jacente n'est pas modifiée. Conservez l'ancienne image NocoDB jusqu'à ce que les limites de migration des données et de rollback soient clairement établies.