Skip to main content

Le modèle

Docker ne fait tourner que les dépendances. L’API et les fronts tournent sur l’hôte, en hot-reload. Un profil container existe pour tester l’image de l’API, ce n’est pas le mode par défaut.

Démarrer

1

Services de support

2

Base de données

3

API, une audience par terminal

4

Un jeu de données

make help liste toutes les cibles. Le Makefile délègue à yarn : les scripts package.json restent la source de vérité (turbo + CI n’appellent jamais le Makefile).

Ports

Seul provider épingle son port en dev ; kare, backoffice et audit utilisent le défaut Next (3000, auto-incrémenté s’il est pris) et n’écoutent sur 3001 / 3002 qu’en yarn start. L’API écoute aussi 3000 : pour lancer les deux, change PORT dans apps/api/.env ou passe PORT= devant make dev-rs, et ajuste le NEXT_PUBLIC_API_URL du front.
http://api.kare.localhost ne route que le service api de compose, donc uniquement en --profile container. En mode par défaut (API sur l’hôte), on tape http://localhost:3000.

Commandes utiles

Mails et fichiers

  • Tout mail sortant part vers Mailpit : les OTP de connexion prestataire se lisent dans son interface.
  • Les uploads vont dans Garage, compatible S3, initialisé par le service garage-init.
  • Les logs applicatifs passent par Alloy → Loki → Grafana, comme en staging.

Fronts

apps/kare et apps/provider téléchargent le dist HeroUI Pro sous licence via scripts/pull-heroui-pro.mjs : il faut un HEROUI_AUTH_TOKEN dans l’environnement, sinon le dev, le build et le typecheck échouent.