Variables d'environnement

Où se trouvent les paramètres

Créez le fichier de chaque application à partir du .env.example placé à côté, qui documente chaque variable : cp .env.example .env. Les exemples fonctionnent tels quels pour un lancement en local, sauf les deux adresses de l'API du tableau de bord, que vous remplissez pour quitter les données d'exemple.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier du tableau de bord, lu au moment du build du tableau de bord. Toutes ses valeurs sont publiques : il ne contient donc jamais de secret. Omettez-le pour utiliser les données d'exemple ; créez-le à partir de .env.example quand vous connectez une API : cp .env.example .env.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier de l'API, lu par l'API avec yarn dev, et par un conteneur quand vous le lui passez avec --env-file .env. Il contient des secrets : ne le committez jamais. Créez-le à partir de .env.example, qui documente chaque variable et fonctionne tel quel pour un lancement en local : cp .env.example .env.

Paramètres essentiels de l'API

L'API vérifie JWT_SECRET et, en production, CORS_ORIGIN avant de démarrer. Si l'un d'eux manque ou est inutilisable, elle s'arrête avec une ligne qui indique quoi corriger. Les variables déjà définies dans l'environnement l'emportent sur le fichier.

Générez votre propre JWT_SECRET avec :

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

Tout identifiant de stockage ou d'IA ci-dessous qui garde exactement sa valeur de .env.example compte comme non défini : la fonctionnalité concernée se signale alors comme désactivée au lieu d'échouer à son premier appel.

Utiliser MySQL au lieu de SQLite

Créez une base de données vide, puis définissez le pilote et la connexion dans back-end/.env :

DB_TYPE=mysql
DB_HOST=your-mysql-host
DB_PORT=3306
DB_USERNAME=your-mysql-username
DB_PASSWORD=your-mysql-password
DB_DATABASE=your-database-name

Exécutez ensuite yarn seed pour les données de démonstration, ou yarn db:sync pour les tables sans données. L'API en marche ne crée et ne met à jour les tables elle-même que lorsque NODE_ENV=development : avec NODE_ENV=production, l'une de ces commandes s'exécute donc avant le premier démarrage (yarn db:sync:prod ou yarn seed:prod après yarn build), puis yarn db:sync:prod à nouveau après une mise à jour qui modifie le schéma. Vos données sont conservées.

Le template ne fournit sa migration que pour SQLite. back-end/src/database/migrations/mysql/README.md contient la commande unique qui génère celle de MySQL, si vous voulez aussi les migrations de démarrage de l'API sur MySQL.

Tableau de bord

Chaque valeur NEXT_PUBLIC_* est compilée dans le JavaScript que charge le navigateur, et toute personne qui ouvre la page peut la lire. Ne mettez jamais de secret dans ce fichier, et redémarrez ou reconstruisez après en avoir modifié une.

Aucune clé de fournisseur d'IA n'a sa place ici. Les clés se trouvent uniquement dans le .env de l'API.

Options de Docker Compose

Rien n'est à définir pour un lancement en local. Pour changer quelque chose, mettez-le dans un fichier .env à côté de docker-compose.yml et relancez docker compose up --build : le tableau de bord intègre ces valeurs à la compilation.

Le conteneur de l'API lit aussi back-end/.env s'il existe : les clés de stockage, d'IA et de MCP se règlent donc à un seul endroit, pour yarn dev comme pour Docker. Le fichier compose l'emporte pour les valeurs qui diffèrent dans un conteneur : NODE_ENV=production, le port, SQLite dans /data/database.sqlite, DEMO_MODE=false, CORS_ORIGIN et FRONTEND_URL. Sans JWT_SECRET à vous, l'API en génère un et le conserve dans le volume de données. Les données se trouvent dans le volume kinora-data.

L'image Docker de l'API

L'image démarre en production sur SQLite dans /data/database.sqlite, port 8000, avec DEMO_MODE=false et SEED_DEMO_DATA=false, et autorise les appels du navigateur depuis http://localhost:3030 (CORS_ORIGIN et FRONTEND_URL). Modifiez n'importe laquelle avec -e sur docker run, ou passez votre fichier avec --env-file .env.

• Sur un volume neuf, le conteneur crée les tables, et n'ajoute les données de démonstration qu'avec SEED_DEMO_DATA=true. Une base de données existante n'est pas modifiée.
• Sans JWT_SECRET, ou avec celui de l'exemple, il génère un secret et le conserve dans /data/.jwt-secret, pour que les connexions survivent à un redémarrage.
• Avec DB_TYPE=mysql, il ne crée rien : exécutez vous-même une fois node dist/database/sync-schema.js ou node dist/database/seeder.js dans le conteneur.

Stockage des médias

Les photos de profil, les photos de progression, les couvertures de groupe et les pièces jointes des messages sont envoyées vers un bucket Cloudflare R2, ou n'importe quel bucket compatible S3. Définissez les cinq variables dans back-end/.env et donnez au tableau de bord l'hôte public du bucket via NEXT_PUBLIC_MEDIA_HOSTNAME (avec Docker Compose, MEDIA_HOSTNAME).

R2_ACCESS_KEY_ID=your-r2-access-key-id
R2_SECRET_ACCESS_KEY=your-r2-secret-access-key
R2_ENDPOINT=https://your-account-id.r2.cloudflarestorage.com
R2_BUCKET_NAME=your-bucket-name
R2_PUBLIC_URL=https://your-public-url.r2.dev

Sans bucket, tout ce qu'écrit le seed est un chemin /assets/images/… que le tableau de bord sert depuis son propre dossier public/assets : chaque écran s'affiche donc sans aucun envoi. Seul l'envoi de nouveaux fichiers cesse de fonctionner : un envoi répond 400 tant que le bucket n'est pas configuré. Gardez public/assets dans le tableau de bord tant qu'une ligne y fait encore référence.

Un fichier fait au maximum 150 Mo. L'outil d'envoi du tableau de bord envoie de lui-même les gros fichiers en parties de 16 Mo au maximum via POST /api/helpers/upload-chunk.

E-mail

Le template ne contient aucun service d'envoi d'e-mails : aucun message n'est donc jamais envoyé par e-mail. Le « resend verification email » de l'écran des membres répond sans rien envoyer, et les pages de mot de passe oublié et de réinitialisation ne sont que des écrans : aucune réinitialisation n'est envoyée et l'API n'a aucune route derrière elles. Connectez votre propre fournisseur d'e-mails, et ajoutez les routes de réinitialisation, avant la mise en ligne si vos membres ont besoin de l'un ou de l'autre.

• « Forgot password » n'envoie rien

Assistant IA

Serveur MCP

Mode démo

Mise en ligne

Avant de déployer quelque part en public :

1. Définissez NODE_ENV=production et un JWT_SECRET long et aléatoire qui vous est propre dans back-end/.env.
2. Définissez CORS_ORIGIN sur l'adresse de votre tableau de bord, et FRONTEND_URL sur la même adresse.
3. Gardez DEMO_MODE=false dans l'API et NEXT_PUBLIC_DEMO_MODE=false dans le tableau de bord.
4. Sur une base de données vide, exécutez yarn build, puis une fois yarn db:sync:prod (ou yarn seed:prod pour les données de démonstration), puis yarn start:prod.
5. Pointez la vérification de santé de votre hébergeur vers GET /api/health. Elle ne demande aucun jeton et n'est pas soumise à une limite de requêtes.
6. Construisez le tableau de bord avec NEXT_PUBLIC_API_BASE_URL et NEXT_PUBLIC_WEBSOCKET_BASE_URL pointant vers votre API déployée.
7. Changez les mots de passe du seed, ou partez de tables vides.

Pour supprimer entièrement le code de démo, exécutez yarn remove:demo dans les deux applications, sur un arbre propre : sans gestion de versions, c'est irréversible. yarn remove:mock dans le tableau de bord supprime les données d'exemple.