Le self-host de NocoDB tient en une commande et supprime la facturation. Mais depuis janvier 2026 la licence a changé, et ça mérite d'être dit avant de le déployer chez un client.
Airtable ne vous facture pas un outil, il vous facture des utilisateurs
C'est le point que tout le monde découvre au troisième trimestre, quand la note tombe.
Airtable facture à l'éditeur. Pas au workspace, pas à la base, pas à l'usage. Toute personne capable de modifier une ligne dans une table est un poste facturé pour le mois entier.
Les tarifs affichés en juillet 2026 :
- Free : 1 000 enregistrements par base, 1Go de pièces jointes, poignée d'éditeurs
- Team : 20$ par poste et par mois en annuel, 24$ en mensuel, 50 000 enregistrements par base
- Business : 45$ par poste en annuel, 54$ en mensuel, 125 000 enregistrements par base
- Enterprise Scale : sur devis
Faites le calcul pour une équipe de six personnes qui éditent, en mensuel, sur le plan Team. 144$ par mois.
1 728$ par an pour un tableur amélioré.
Et le plafond d'enregistrements est le vrai piège. Vous ne changez pas de plan parce que vous voulez une fonctionnalité, vous changez de plan parce que votre base a grossi. Passer de Team à Business, c'est plus que doubler le prix au poste, pour la même équipe qui fait exactement le même travail.
C'est ma vieille obsession, appliquée à autre chose que les tokens : le prix affiché n'est pas la métrique. Ce qui compte c'est ce que coûte la tâche complète, une fois que vous avez ajouté les postes, les dépassements, et le connecteur Make ou Zapier que vous avez dû brancher parce que l'intégration native n'existait pas.
NocoDB, ce n'est pas vraiment un clone d'Airtable
C'est la nuance que je trouve mal expliquée partout.
NocoDB fait 2 choses différentes.
La première, c'est le clone : vous créez des bases, des tables, des vues grille, kanban, galerie, formulaire, calendrier, carte.
La deuxième, c'est plus intéressant pour nous : vous branchez NocoDB sur une base PostgreSQL ou MySQL qui existe déjà, et vous obtenez une interface no-code au-dessus de vos vraies données.
Concrètement, vous pointez sur un replica de prod et vous avez un outil interne utilisable par le métier en dix minutes. Sans écrire un back-office. Sans maintenir un back-office.
Le projet affiche plus de 63 000 étoiles GitHub et plus de 20 millions de téléchargements. Ce n'est pas un side project du week-end.
Et l'API REST est générée automatiquement, avec spécification Swagger. Donc votre table devient un endpoint sans que vous ayez à coder quoi que ce soit.
Le self-host tient littéralement en une commande
C'est là que je trouve la doc récente vraiment bien faite. Ils ont arrêté de vous noyer sous quinze méthodes d'installation.
Pour tester en local :
curl -fsSL https://install.nocodb.com/noco.sh | bash -s -- --quick
Ça écrit une stack Docker Compose dans un dossier nocodb/ et ça la démarre.
4 conteneurs :
- nocodb : l'application web et l'API
- worker : les jobs de fond (imports, exports, automatisations)
- db : PostgreSQL, qui stocke les métadonnées et vos données
- redis : cache et file de jobs
Vous ouvrez localhost:8080, vous créez un compte, le premier utilisateur devient super admin. Les données sont dans des volumes Docker nommés, donc elles survivent à un arrêt de la stack.
Pour un vrai serveur, c'est la même commande sans le flag quick. Le script vous pose trois ou quatre questions (domaine, Postgres bundled ou existant, Redis bundled ou existant, email Let's Encrypt) et il monte Traefik avec le certificat SSL automatique.
Et pour ceux qui font de l'infra as code, il y a un mode non interactif :
curl -fsSL https://install.nocodb.com/noco.sh | bash -s -- \
--domain=nocodb.example.com \
--acme-email=ops@example.com \
--pg=bundled --redis=bundled
Si vous n'aimez pas piper un script distant dans bash (et vous avez raison de ne pas aimer ça), vous pouvez le télécharger, le lire, puis l'exécuter. Le source est dans le repo GitHub du projet.
Côté machine, la doc annonce 2 vCPU et 2 Go de RAM au minimum, 4 vCPU et 8 Go recommandés en production, avec 50 Go de disque et plus.
Autrement dit un VPS à 20 ou 30 € par mois chez n'importe quel hébergeur européen.
Ce que l'édition Community vous donne vraiment gratuitement
J'ai épluché le tableau comparatif, parce que c'est là que se joue la vraie décision.
En self-host, gratuitement, vous avez :
- Enregistrements, stockage et postes illimités
- Les 5 rôles (Owner, Creator, Editor, Commenter, Viewer)
- Les 6 types de vues, kanban et carte compris
- L'historique de révision des enregistrements, illimité
- Les commentaires sur les enregistrements
- Les webhooks conditionnels avec payload JSON personnalisé
- L'API REST complète, avec un nombre d'appels illimité
- Les connexions à des bases PostgreSQL et MySQL externes, en illimité
Ce dernier point mérite qu'on s'arrête dessus. Sur le cloud NocoDB, le plan Plus à 12 $ par poste ne permet pas de connexion à une base externe, il faut monter en Business. En self-host, c'est inclus dans la version gratuite, sans limite.
Donc le cas d'usage le plus intéressant du produit, la couche visuelle au-dessus de votre Postgres existant, est précisément celui qui ne coûte rien si vous l'hébergez vous-même.
Et ce que la Community ne vous donne pas
Parce que sinon je vous vends du rêve, et ce n'est pas le job.
Absent de l'édition Community self-hostée :
- Le 2FA
- Le SSO et le panneau d'administration
- Les logs d'audit
- Les workflows, les scripts et les dashboards
- Les permissions par table et par champ, la sécurité au niveau de la ligne
- Les équipes et la hiérarchie d'équipes
- Les extensions, les documents, les fonctionnalités d'IA
- Les synchronisations avec GitHub, Jira, HubSpot, Zendesk et compagnie
- Les snapshots de base
Le 2FA absent sur une instance exposée en HTTPS, c'est le point qui me gêne le plus.
Vous compensez avec un reverse proxy et une authentification en amont, mais c'est du travail supplémentaire que vous n'aviez pas prévu.
Et il y a une asymétrie tarifaire que je n'ai vue mentionnée nulle part. Les plans payants self-hostés sont facturés par éditeur : 24$ en Business, 45$ en Scale, en annuel.
Alors que sur le cloud, les plans Plus et Business plafonnent à 9 postes facturés, avec les suivants gratuits.
Résultat, pour une équipe de 20 éditeurs qui veulent le SSO et les permissions fines, le cloud Business revient à 216$ par mois et le self-host Business à 480$ par mois. Vous payez plus cher pour héberger vous-même 😂.
Ce sont les chiffres affichés au 24 juillet 2026, à vérifier avant de signer, mais l'inversion est là.
Donc soit vous restez en Community et vous acceptez les manques, soit vous prenez le cloud. La zone intermédiaire est mal tarifée.
La licence a changé, et il faut le dire à votre client
C'est le morceau que la plupart des comparatifs continuent d'ignorer.
Depuis la version 0.301.0, sortie en janvier 2026, NocoDB n'est plus publié sous AGPLv3. Le projet est passé sous Sustainable Use License, un modèle dit fair-code, qui n'est pas approuvé par l'OSI.
Le terme exact est source available, pas open source.
Ce que la licence autorise : héberger NocoDB et l'utiliser pour vos besoins internes, y compris construire des applications pour votre propre organisation.
Ce qu'elle n'autorise plus : proposer NocoDB comme service hébergé ou managé à des tiers sans licence commerciale.
Le mainteneur a expliqué sa décision dans la discussion GitHub #12891. Selon lui, des acteurs revendaient le travail de l'équipe sans respecter l'AGPLv3, des forks privés existaient sans que le code soit publié, et poursuivre coûtait trop cher pour une petite équipe. Il cite n8n comme précédent. Il affirme aussi que le passage en fair-code leur a permis de libérer plusieurs fonctionnalités enterprise dans la version 0.301.
Un contributeur a soulevé la question du CLA et de l'origine du code : si du code AGPL ou GPL tiers avait été intégré par un contributeur, le relicenciement poserait problème. La réponse de l'équipe est que le CLA leur donne les droits de sous-licencier et que la responsabilité incombe au contributeur. Je relaie l'échange, je ne tranche pas le point juridique, ce n'est pas mon métier.
Ce qui est vérifiable, en revanche : plusieurs sites de comparaison encore en ligne en juillet 2026 présentent NocoDB comme AGPL-3.0. C'est faux depuis six mois. Si vous vous êtes appuyé sur un de ces comparatifs pour valider un choix technique, reprenez le dossier.
Pour vous les créateurs de SaaS ou petite équipe, l'impact concret est en général nul. Vous déployez pour un client, c'est un usage interne, vous êtes dans les clous.
L'impact devient réel si vous vouliez packager NocoDB dans une offre. Un outil métier vendu en marque blanche à plusieurs clients, une plateforme hébergée pour vos utilisateurs : là vous êtes hors licence, et il faut passer par une licence commerciale.
C'est exactement le genre de contrainte qu'on découvre trois mois trop tard.
Ce que je ferais avant de mettre ça en prod
La doc contient une checklist de durcissement, et pour une fois elle est sérieuse. Les points que je retiens :
- Firewall sur 22, 80 et 443 uniquement
- Permissions 600 sur docker.env et sur le fichier de connexion à la base
- Rotation des logs Docker, sinon json-file grossit sans limite
- Une unit systemd, pour que le déploiement soit un service géré et pas un docker compose lancé à la main
- Le endpoint /api/v1/health branché sur votre supervision
- Des tags d'image épinglés, jamais latest en production
- Un pg_dump quotidien plus une archive des pièces jointes
Ce dernier point, je le souligne. Le nombre d'équipes qui perdent des données parce qu'elles ont supposé qu'un volume Docker était une sauvegarde reste hallucinant. Le volume nommé survit à un arrêt de conteneur. Il ne survit pas à une erreur humaine, ni à la mort du serveur.
Un détail à connaître aussi : si vous activez une licence payante, l'instance appelle app.nocodb.com toutes les 6 heures pour la validation. Si vous filtrez votre trafic sortant, il faut autoriser cet appel. Une installation totalement déconnectée existe, mais c'est réservé au plan Enterprise.
Alors, ça remplace Airtable ?
Pour la majorité des usages que je vois passer chez des saas builders et des petites structures, oui.
Le CRM léger, le suivi de prospection, le pilotage éditorial, la base clients partagée avec deux ou trois collaborateurs, le formulaire public qui alimente une table : tout ça tourne sur une instance Community à 25 € de VPS par mois, sans limite de lignes et sans limite de postes. L'import depuis Airtable est intégré au produit.
Ce que vous perdez : la maturité des synchronisations bidirectionnelles d'Airtable, l'écosystème de templates, et le fait de ne pas avoir à vous soucier des sauvegardes. Ce dernier point n'est pas un détail, c'est un poste de travail récurrent que vous vous ajoutez.
Ce que vous gagnez : vos données restent chez vous, la facture ne bouge pas quand l'équipe grandit, et vous pouvez brancher l'outil directement sur la base de données qui fait déjà tourner votre métier.
Ce que je n'ai pas encore fait, et que je ne vais pas vous raconter comme si je l'avais fait : le faire tourner six mois en production sur un projet client avec des vrais volumes et des vrais utilisateurs. Les chiffres et les fonctionnalités de cet article viennent de la documentation officielle et des pages tarifaires, pas de mon expérience terrain.
Donc je testerai avant. Parce que ce qui casse en self-host, ce n'est jamais ce qui est écrit dans la doc.
