D'où nous venons
On n'en est pas à notre coup d'essai. Avant Rebase, nous avons créé FireCMS — un CMS open-source pour Firebase déployé sur plus de 10 000 projets dans le monde, adopté par des équipes chez Microsoft et IKEA. Pendant des années, nous avons appris ce que les développeurs attendent vraiment d'un panneau d'administration, ce qui bloque les éditeurs de contenu, et où chaque CMS finit par montrer ses limites.
FireCMS nous a énormément appris. Que les développeurs veulent de la flexibilité, pas du lock-in. Que les utilisateurs finaux veulent du beau et du simple, pas un mur de formulaires. Que les meilleurs outils se font oublier et laissent les gens se concentrer sur ce qui compte vraiment.
Mais FireCMS était indissociable de Firebase. Et en voyant l'industrie migrer vers Postgres, vers les standards ouverts, vers la souveraineté des données — nous avons compris qu'il était temps de voir plus grand. De bâtir un socle capable de porter n'importe quel projet numérique, pas seulement ceux liés à un seul fournisseur cloud.
Un problème que l'on connaît tous
Chaque nouveau projet commence pareil. Il faut une base de données. Un panneau d'administration. De l'authentification, une couche API, du stockage, des permissions. Tout ça, vous l'avez déjà construit — peut-être des dizaines de fois. Et pourtant, à chaque fois, c'est retour à la case départ… ou enfermement dans une plateforme qui contrôle vos données et dicte votre roadmap.
Les plateformes cloud ont simplifié le démarrage. Firebase, Supabase, les CMS managés — ils permettent de sauter la tuyauterie et de passer directement au produit. Payer quelqu'un pour exploiter son infrastructure n'a jamais été le problème ; peu d'équipes ont envie de veiller sur un cluster Postgres. Le problème, c'est ce qui vient avec : un schéma lisible uniquement depuis leur console, une tarification imprévisible, et une sortie qui équivaut à une réécriture. La commodité devrait être une facture qu'on peut arrêter de payer, pas une décision irréversible.
En face, les solutions auto-hébergées existent, mais elles semblent souvent d'une autre époque. Complexes à installer, pénibles à personnaliser, pensées pour un monde d'avant l'IA, d'avant le TypeScript partout, d'avant que les développeurs exigent des outils qui marchent tout simplement.
Nos convictions
L'autorisation appartient à la base de données
C'est la conviction sur laquelle nous avons parié toute l'architecture, et celle qui déclenchera le plus de débats. Des règles d'accès qui vivent dans le code applicatif sont des règles qu'un endpoint oublié, une tâche de fond, un script de migration ou une console SQL directe contournent sans effort : elles protègent la porte, pas la pièce. Dans Rebase, l'autorisation est la row-level security de Postgres : écrite en TypeScript, compilée en véritables policies, appliquée par la base elle-même à chaque instruction et pour chaque appelant. Une table sans policy n'est tout simplement pas servie. Nous échouons en mode fermé même quand c'est gênant, même quand votre toute première requête revient vide et qu'il faut aller écrire une règle avant de continuer. Tous les autres modèles que nous avons livrés ont fini par fuir. Celui-ci ne le peut pas.
Votre base de données est votre source de vérité
Nous ne créons pas de base fantôme. Nous ne masquons pas votre schéma derrière une couche propriétaire, et nous ne vous demanderons pas de modéliser vos données deux fois. Rebase se branche sur votre Postgres, lit vos tables et construit sur ce qui existe déjà : ce que vous voyez dans psql est ce que l'API sert. Et si vous supprimez Rebase demain, vos données sont exactement là où vous les avez laissées, dans une forme encore utilisable. Un backend que vous ne pouvez pas quitter n'est pas une infrastructure, c'est une prise d'otage.
Les agents sont des utilisateurs de votre backend, pas une option greffée dessus
Une part importante et croissante du code écrit contre votre backend l'est désormais par un agent — et les agents ne lisent pas les tableaux de bord. Ils lisent des schémas, des types et des messages d'erreur. Rebase fournit donc un serveur MCP, des définitions de collections lisibles par machine, un SDK typé généré et des clés d'API à portée restreinte ; et nous traitons un message d'erreur confus comme un bug, que le lecteur soit une personne ou un modèle. Les outils conçus uniquement pour un humain qui clique dans une console sont déjà davantage contournés qu'utilisés.
L'open source est une fondation, pas une fonctionnalité
Rebase est sous licence MIT — chaque package, chaque ligne. Pas d'open-core avec la moitié utile derrière une clé de licence. Pas de source-available assorti d'une clause sur qui a le droit de nous concurrencer. Nous avons vu trop de projets d'infrastructure utiliser « open source » comme un entonnoir, puis changer de licence une fois que la communauté avait fait sa part — et nous savons exactement l'effet que cela produit vu de l'extérieur. La licence est la promesse, et MIT est la seule version de cette promesse que nous ne pourrions pas retirer discrètement plus tard. Et cela vaut jusqu'en bas de la pile : Postgres, Node, Hono, Drizzle — chaque couche sous Rebase est elle aussi open source, et aucune n'a besoin de notre infrastructure pour tourner. C'est ce qui fait de « déployable partout » un fait d'architecture, et non une ligne sur une page de tarifs.
L'Europe devrait posséder son infrastructure
Nous construisons depuis Madrid, et nous considérons que la situation actuelle — où la plupart des entreprises européennes font tourner leurs données sur une infrastructure détenue ailleurs et régie par le droit d'autrui — est une erreur stratégique qui mérite d'être corrigée. La souveraineté des données et le RGPD ne sont pas une case à cocher sur notre feuille de route : ce sont la raison pour laquelle plusieurs décisions de conception ont ici pris le chemin le plus difficile. Vous pouvez exécuter Rebase n'importe où dans le monde, et nous en serions ravis. Mais sur ce point, nous ne sommes pas neutres.
À qui s'adresse Rebase
À tous ceux qui en ont assez de choisir entre simplicité d'utilisation et maîtrise de leurs outils :
- Le développeur qui veut la vélocité de Firebase sans le lock-in de Firebase
- La startup qui doit aller vite aujourd'hui et scaler demain — sans tout reconstruire
- L'agence fatiguée de recréer le même panneau d'admin pour chaque projet client
- L'équipe entreprise qui doit conserver ses données sur sa propre infrastructure, avec une traçabilité complète
Rebase est hautement modulaire — utilisez le panneau d'admin, la couche API, le SDK, ou l'ensemble. Prenez uniquement les composants dont vous avez besoin, laissez le reste. C'est vous qui décidez jusqu'où vous adoptez la stack — et où elle tourne : votre machine, vos propres serveurs, ou hébergée par nous. C'est le même code sous licence MIT dans les trois cas, donc basculer de l'un à l'autre est un redéploiement, pas une migration.
Pensé pour trois publics
La plupart des outils sont conçus pour une seule audience. Nous construisons pour trois — parce que nous sommes convaincus que le meilleur backend est celui où chacun peut travailler efficacement :
Utilisateurs finaux
Des interfaces soignées et intuitives que les non-techniciens prennent réellement plaisir à utiliser.
Développeurs
Natif TypeScript, extensible en React, avec des APIs et des SDKs qui semblent faits sur mesure pour vous.
Agents IA
Serveur MCP, APIs structurées et schémas lisibles par les machines — pour que les agents puissent eux aussi construire avec Rebase.
Comment nous finançons tout cela
Un manifeste qui ne dit jamais d'où vient l'argent vous demande de croire le reste sur parole. Alors, clairement : aujourd'hui, c'est FireCMS qui paie Rebase. Le CMS que nous avons construit avant celui-ci est encore utilisé dans plus de 10 000 projets, et ses revenus financent le travail que vous voyez ici — ce qui veut dire que Rebase n'a jamais eu à gagner sa vie en retenant une fonctionnalité. Rien de ce que vous installez n'est une version d'essai, et rien de ce que vous déployez ne cesse de fonctionner à l'échéance d'un contrat.
Les fonctionnalités que l'on garde d'habitude en réserve sont justement celles que nous publions : SSO, MFA, clés d'API à portée limitée, historique des données, sécurité au niveau des lignes. Il n'y a pas de meilleur Rebase derrière une clé de licence, et il n'y en aura pas : dès qu'une fonctionnalité existe, elle existe dans le dépôt MIT. Quand il nous faudra plus de revenus, nous comptons les gagner en exploitant plus d'infrastructure, pas en reprenant quelque chose.
C'est à cela que sert Rebase Cloud. Il tourne déjà aujourd'hui, avec de vrais clients, encore en bêta privée, et ce n'est pas un autre produit doté d'une liste de fonctionnalités plus longue : c'est le même runtime publié, sur des machines que nous exploitons. Cette contrainte nous plaît : si la seule chose que nous puissions vendre est l'exploitation, alors la version que vous faites tourner vous-même doit rester assez bonne pour être réellement utilisée ainsi, sinon nous n'avons plus rien à facturer.
Notre engagement
Nous ne construisons pas Rebase pour le revendre ni pour vous enfermer. Nous le construisons parce que nous avons consacré notre carrière aux outils pour développeurs, et nous savons ce qui manque : un backend ouvert, élégant et natif Postgres qui respecte vos données, votre temps et votre intelligence.
Nous livrons vite, et nous livrons en public — le changelog et le suivi des issues en sont la trace. Rebase est jeune. Assez jeune pour que les convictions ci-dessus soient encore tout le produit, et assez jeune pour qu'un argument de votre part puisse encore en faire changer une. C'est le meilleur moment pour arriver.
Si ces mots trouvent un écho en vous — si vous avez ressenti la même frustration, si vous portez les mêmes convictions — venez construire avec nous.
L'équipe Rebase
Madrid · Outils open source pour développeurs depuis 2020