Greffon : une plateforme de déploiement open source et auto-hébergée

Déployer une application aujourd’hui, c’est le plus souvent choisir entre deux pôles. D’un côté, les plateformes managées — Heroku, Railway, Render — qui ont démocratisé le déploiement au prix d’une facturation à l’usage, de conditions imposées et d’aucun droit de regard sur l’endroit où vivent vos données. De l’autre, Kubernetes : le standard de l’industrie, à juste titre, et un engagement opérationnel de plusieurs années pour des équipes qui devraient livrer des fonctionnalités plutôt que d’entretenir un cluster.

Greffon occupe le milieu rationnel. C’est une plateforme open source pour déployer des applications conteneurisées — les greffons — sur des nœuds d’infrastructure qui vous appartiennent — les greffers, le porte-greffe. Un plan de contrôle, autant de workers que nécessaire, aucun fournisseur dans la boucle.

Pensez-y comme à un Heroku auto-hébergé : publiez un modèle Docker Compose, configurez une instance, et laissez la plateforme gérer l’orchestration, le TLS et le cycle de vie sur vos propres machines.

Ce que Greffon résout

Le piège du PaaS managé. La facture grandit avec votre succès, et la souveraineté n’est pas au menu. Acceptable pour un prototype ; intenable pour une organisation soumise à des contraintes de résidence des données, de conformité ou de budget.

La montagne Kubernetes. « Installez Kubernetes » n’est pas une réponse pour la plupart des équipes. C’est une surface d’API à apprendre, du réseau à déboguer, des mises à jour à gérer, et une équipe dédiée à recruter.

L’écart entre les deux, c’est là que vivent la plupart des organisations : des équipes qui veulent un déploiement presse-bouton sans dépendance hébergée, et une infrastructure qui existe déjà — sur site, ou chez des fournisseurs européens comme Scaleway, OVH ou Clever Cloud — qui ne demande qu’à servir.

Greffon est construit pour cet écart : le déploiement pour ceux qui possèdent leur infrastructure et comptent bien la garder.

Architecture : ennuyeuse à dessein

Votre navigateur
    │
Frontend du manager (React)
    │
Backend du manager (Django) ── autorité de certification intégrée
    │            mTLS
Nœuds greffers (FastAPI) ── Docker Engine · TLS par instance (Nginx)
    │
Vos applications (Docker Compose)

Le backend du manager est le plan de contrôle. Il tient le catalogue des applications déployables, authentifie les utilisateurs, orchestre le cycle de vie des instances et émet les certificats via une autorité de certification intégrée — aucun gestionnaire de secrets externe à amorcer d’abord.

Le frontend du manager est le tableau de bord : parcourir le catalogue, configurer une instance, la démarrer, l’arrêter, lire son état.

Le greffer est un agent léger sur chacun de vos nœuds. Il s’enregistre auprès du manager par une poignée de main sécurisée et installe des certificats mTLS pour tous les échanges suivants. Quand on lui demande de démarrer une instance, il récupère le modèle Docker Compose, y rend la configuration (Jinja2), crée volumes et réseaux, monte la pile, la place derrière un proxy TLS par instance (Nginx), et remonte l’état de santé de façon asynchrone. Un greffer héberge plusieurs instances côte à côte.

L’architecture est volontairement ennuyeuse. Chaque composant fait une chose ; chacun s’améliore ou se remplace seul. Les greffers sont du bétail, pas des animaux de compagnie : si un nœud meurt, l’instance redémarre ailleurs, parce que le manager détient la configuration et que le worker n’est qu’un environnement d’exécution. Et le report d’état asynchrone raconte l’histoire vraie d’une flotte partiellement en panne, plutôt que la fausse assurance d’une API synchrone.

Un déploiement, en pratique

1. Constituer un catalogue. Les modèles Docker Compose vivent dans un dépôt Git, chacun avec un schéma déclaratif de ce que l’utilisateur peut configurer — nom de domaine, identifiants, dimensionnement.
2. Enregistrer un greffer. Provisionnez n’importe quelle machine Linux — bare metal, VM, instance cloud — et installez l’agent. Il s’enregistre auprès du manager.
3. Déployer. L’utilisateur choisit une application du catalogue, remplit la configuration, clique. Certificat émis, commande envoyée, modèle récupéré et rendu, conteneurs démarrés, HTTPS actif.
4. Exploiter. Démarrer, arrêter, consulter — depuis le tableau de bord, le greffer poussant les changements d’état au fil de l’eau.

Pas de charts Helm, pas d’admission controllers, pas de DSL d’ingress. Docker Compose et un schéma de configuration.

Open source, précisément

Deux composants sont publics aujourd’hui :

• greffer — l’agent worker (Python, FastAPI), sous licence AGPL-3.0 : le copyleft réseau qui garde ouverts les dérivés hébergés tout en laissant l’auto-hébergement sans restriction.
• greffon-catalog — des modèles d’applications d’exemple (TypeScript), sous licence Apache-2.0, pour que les modèles de catalogue se réutilisent partout sans friction.

Cette répartition des licences est voulue : copyleft fort là où vit la valeur de la plateforme, permissif là où l’adoption doit être sans effort.

À qui cela sert

Les hébergeurs. Vous vendez aujourd’hui du VPS ou du Kubernetes managé. Greffon suggère un troisième produit : un plan de contrôle en marque blanche et des images greffer préconfigurées, pour que vos clients déploient sans quitter votre écosystème — un revenu de PaaS sans construire un PaaS.

Les organisations sous contraintes. Résidence des données, auditabilité, conformité. Greffon tourne sur votre matériel, sous votre contrôle, et l’émission de certificats est transparente et déterministe — assurée par votre propre autorité, pas par un service tiers.

Les petites équipes. Déployer comme sur une plateforme managée, posséder comme en auto-hébergé — sans recruter d’abord une équipe plateforme.

Feuille de route

• M1 — fiabilité du cœur : plan de contrôle Django, autorité de certification intégrée, API d’orchestration stable. C’est là que se situe la bêta.
• M2 — durcissement production : la migration récente du greffer vers FastAPI débloque l’asynchrone et le support WebSocket ; viennent ensuite l’intégration step-ca et Let’s Encrypt pour l’autorité, le tunnel inverse pour les greffers derrière un NAT, et l’observabilité structurée (métriques, journaux).
• M3 — passage à l’échelle : PostgreSQL pour le plan de contrôle, schémas OpenAPI générés, tests de capacité, ordonnancement multi-worker.

Chaque jalon ferme des manques opérationnels réels avant d’ouvrir le suivant.

Où en est le projet

Greffon est en bêta, en ligne sur greffon.io. Le worker et le catalogue sont ouverts dès aujourd’hui ; la plateforme mûrit au grand jour à mesure que la bêta se consolide. Si vous déployez des applications, exploitez de l’infrastructure ou construisez des produits d’hébergement, le projet mérite votre attention dès maintenant — et pour parler intégration, distribution ou contribution, écrivez à contact@greffon.io.

Greffon est construit chez Samouraï Coop, où le studio d’ingénierie livre les plateformes et l’équipe film documente le travail. L’auto-hébergement n’est pas ici une nostalgie : c’est la position que les organisations devraient posséder leur chaîne de déploiement comme elles possèdent leur code.