NodeBB
dans votre projet Git.

À quoi ça sert

Animer un forum avec catégories publiques et privées, discussions, réponses, images et droits d’accès.

Cette recette compose des capacités réutilisables. Votre code et vos personnalisations restent dans votre dépôt ; les paramètres publiés décrivent comment construire et exécuter le projet.

Ce qui a été vérifié

NodeBB 4.16.0 maintenu créé sur une application neuve puis code client compatible mis à jour, avec zéro appel LLM aux deux étapes ; compte, session, catégories, discussion, image et liaison MongoDB conservés, nouvelle réponse créée.

• Version amont constante ; ajout compatible d’un fichier public client
  4.16.0 maintenu → 4.16.0 maintenu — révision client compatible
  Vérifié dans la portée indiquée

• CréationVérifié dans la portée indiquée

  Création sur une application neuve depuis Git avec zéro appel LLM : contrôles natifs, compte, catégories publique et privée, discussion avec emoji et image, réponse et refus d’accès sans session vérifiés.

• Mise à jourVérifié dans la portée indiquée

  Même projet Git et version 4.16.0, fichier public client ajouté sans changer le TOML, zéro appel LLM ; copie froide et génération des assets exécutées, compte, session, contenus, image, réservation et liaison conservés, nouvelle réponse créée.

• Sauvegarde ou exportPartiel

  Export logique MongoDB sous TLS sans les sessions, et archives de 12 puis 21 fichiers sans les sorties de build régénérables ; relecture des contenus avant et après la mise à jour. Copie froide native de quatre fichiers vérifiée, sans restauration ni instantané conjoint.

• RestaurationNon vérifié

  Restauration MongoDB et fichiers non exercée.

• Version amont 4.16.0 constante ; aucune migration de version NodeBB qualifiée.
• MongoDB privé à un seul membre, sans service d’inférence, Redis ni PostgreSQL ; aucun nouveau cluster fournisseur ni haute disponibilité déduit du raccordement.
• Les assets sont régénérés à chaque démarrage dans une zone privée persistante. Ces sorties régénérables sont exclues des exports de fichiers ; les sessions sont exclues de l’export logique MongoDB.
• La relance de l’installateur exige une absence de contenu métier prouvée ; une interruption ne permet pas une réinstallation arbitraire.
• Fédération ActivityPub et inscription publique désactivées par la recette ; courriel réel, web-push, SSO, plugins supplémentaires et charge non qualifiés.
• Exports MongoDB et fichiers distincts ; restauration et atomicité conjointe non qualifiées.
• Scénarios vérifiés, sans certification indépendante ni disponibilité générale déduite.

Prérequis et composition

Un projet autorisé, le code complet avec ses dépendances verrouillées, et la configuration de la recette compatible avec la version retenue.

• N1-NODE · Node.js
• N1-PERSIST · Persistance
• N1-COMPOSE · Composition
• N2-MONGODB · MongoDB

Les ressources N0 sont résolues via les capacités ci-dessus. Les services et bindings requis dépendent de la recette ; un fournisseur existant n’implique pas la création d’un nouveau serveur par application.

Les données persistantes et identités initiales se préparent avant le premier déploiement. Les secrets se gèrent dans le projet, sans les écrire dans Git.

Choisir le parcours adapté

Consultez les versions et préparez votre dépôt avec la configuration publiée. La disponibilité et les conditions de votre projet se confirment avant installation.

Cette fiche n’annonce pas de bouton d’installation en un clic pour une recette non mise à disposition dans votre projet.

Livrer depuis Git

1. Récupérez la configuration complète publiée pour la recette et sa version ; adaptez uniquement ses paramètres autorisés.
2. Versionnez le code complet, les dépendances et paas.toml dans le dépôt relié à l’application.
3. Poussez sur la branche de livraison configurée. Le commit exact passe par construction, tests, scan, inventaire logiciel, signature et admission.
4. Vérifiez la version servie et un usage métier. Pour une mise à jour, contrôlez aussi l’identité et la conservation des données.

# Depuis le dépôt déjà relié à votre projet, sur sa branche de livraison
git add paas.toml
git commit -m "Configure la recette applicative"
git push paas main

L’exemple suppose que le remote paas et la branche main correspondent à votre projet. Le code client et les verrous de dépendances doivent eux aussi être versionnés.

Personnaliser et aller plus loin

Paramètres, thèmes, plugins et code métier évoluent dans le même projet. Une version ou une option compatible réutilise le module existant ; une responsabilité absente exige une évolution de capacité avec ses propres tests.

Chaque personnalisation repasse les contrôles. Un plugin supplémentaire n’hérite pas de la qualification de cette fiche. Les versions, opérations et paramètres du contrat restent consultables dans le détail du module.

Prochaines étapes

Une configuration connue et compatible suit le parcours déterministe, sans appel de modèle. Une configuration manquante ou un échec réparable ouvre une correction bornée ; les changements restent visibles dans Git.