Catalogue de blueprints

Ce catalogue rassemble des blueprints complets — environnements, briques managées, services, domaines, liaisons — qui déploient des produits open source réels, à partir de leurs dépôts ou de leurs images publiques, à des versions épinglées. Aucun dépôt à remplacer : changez les domaines et saisissez vos secrets, puis importez le fichier (voir Blueprints).

Ces exemples sont validés par un test automatique (schéma, add-ons existants, liaisons cohérentes, aucune référence fictive ni :latest), mais pas déployés à chaque version : le comportement exact d’un produit au premier démarrage peut demander un ajustement, signalé dans chaque page.

Les catégories

Catégorie	Produits déployés
Commerce & paiement	PrestaShop (boutique)
SaaS & back-office	Cal.com (rendez-vous), Twenty (CRM)
Données & reporting	Metabase (tableaux de bord), Redpanda Connect + NATS + MongoDB (événements)
Documents & contenus	Paperless-ngx (GED), Ghost (site éditorial)
Temps réel & IoT	EMQX + Telegraf + Grafana (flotte de capteurs)
Support & automatisation	Chatwoot (service client), n8n (workflows)

Conventions communes

Un fichier = un projet. Le project.slug désigne la cible : s’il existe déjà, le fichier le complète.
Aucun secret dans le fichier. Les clés sensibles sont déclarées fromSecret: true ; leurs valeurs se saisissent à l’import, dans des champs masqués après l’aperçu (ou dans values par l’API).
Une cible de lien porte exposure. Un service visé par links déclare exposure: { port: … } (le port de l’application) ; sans cela le lien est laissé de côté à l’import.
Les add-ons s’identifient par templateKey : postgresql, redis, mysql, mongodb, meilisearch, minio, rabbitmq, nats. Le catalogue de la plateforme peut s’enrichir ; une clé inconnue fait échouer l’import franchement.
Un service vient d’un dépôt Git ou d’une image (gitRepo ou imageRef), jamais des deux. Un service Git nomme son gitProvider.
Un cron exige cronSchedule.
Les liaisons : bindings injecte la chaîne de connexion d’un add-on dans un service (la variable par défaut, ou envVarKey pour la choisir) ; links relie deux services et fournit {PRÉFIXE}_URL, {PRÉFIXE}_HOST, {PRÉFIXE}_PORT au consommateur.
Les stacks : un produit livré avec son docker-compose se déploie en stack (compose en ligne ou fichier d’un dépôt). Une configuration à monter se déclare dans files.
L’adresse publique n’existe qu’après la création. Quand un produit a besoin de sa propre URL, corrigez la variable correspondante dans l’onglet Variables, puis redéployez.
Les ressources (resources) sont facultatives : sans elles, les défauts de la plateforme s’appliquent. Dimensionnez la production, laissez les défauts en recette.