Référence cible infra/runtime - HeyMoov¶

Note de répartition : ce document a été déplacé depuis heymoov-api vers heymoov-docs, car il décrit une cible runtime et opérateur transverse. L'automation exécutable vit dans heymoov-platform; les contrats backend proches du code restent dans heymoov-api.

Objet du document¶

Ce document fixe la cible de migration infra/runtime du backend HeyMoov.

Il sert à la fois:

de référence de travail pour les choix d'architecture runtime
de cible explicite pour les chemins, domaines, services et clients Hydra
de checklist de suivi pour la migration progressive

Statut: cible infra/runtime + suivi de migration Date de mise à jour: 2026-05-01

Périmètre¶

Le document couvre:

les environnements dev, staging, prod
les répertoires runtime sur serveur
les services systemd
les domaines publics et techniques
les variables d'environnement runtime
les clients Hydra/OIDC
la séparation entre provisioning host et bootstrap d'environnement
les préalables repo/scripts nécessaires à la bascule
le template runtime versionné sans valeurs réelles

Le document ne couvre pas:

le détail des secrets
les credentials PostgreSQL, Redis, Hydra ou SMTP
le code Terraform, cloud-init ou Ansible final
la stratégie CI/CD front complète
les valeurs effectives des fichiers runtime de chaque environnement

Constat de départ¶

Au moment de cette référence:

le runtime actif sur ls2i-staging reste majoritairement branché sur l'ancien runtime legacy
l'API active tourne encore via une unité legacy
le cleaner Expo actif tourne encore via des unités legacy
plusieurs binaires actifs observés portent encore un naming historique
les URLs runtime observées mélangent heymoov.com et des domaines hérités
les clients Hydra observés mélangent un client web legacy et un client mobile heymoov

Conclusion:

l'état courant ne doit pas être considéré comme la cible
la migration doit séparer clairement dev, staging et prod
la cible doit sortir du naming legacy et faire passer tout le public possible sous heymoov.com

Décisions cibles retenues¶

1. Environnements logiques¶

Les environnements cibles sont:

dev
staging
prod

2. Hébergement¶

La cible retenue est:

dev sur ls2i-staging
staging sur ls2i-staging
prod sur un serveur distinct

Important:

dev et staging peuvent cohabiter sur la même machine
ils ne doivent partager ni leur runtime, ni leur base, ni leurs clients Hydra, ni leurs uploads

La topologie courante est décrite dans l'inventaire non secret heymoov-platform/deploy/inventory/heymoov.envs. Les ports ne sont pas déduits du nom de l'environnement mais du PORT_SLOT local:

primary: API 9196, readyz 18081, Hydra 4444/4445, Mercure 2022, Redis DB 0
secondary: API 9197, readyz 18082, Hydra 4446/4447, Mercure 2023, Redis DB 1

Inventaire courant:

dev: ls2i-staging, primary
staging: ls2i-staging, secondary
prod: ls2i-rdscrap, primary

3. Provisioning host¶

La source de vérité transverse du provisioning host est:

heymoov-docs/reference/infra/heymoov-host-provisioning.md

Ce repository ne porte que le contrat consommé par les scripts de bootstrap backend. Les scripts make partent d'un serveur déjà provisionné et ne sont pas la couche Terraform, cloud-init ou Ansible.

Chemins plateforme attendus par la cible backend:

Hydra courant: /opt/heymoov-platform/bin/hydra
Mercure courant: /opt/heymoov-platform/bin/mercure

bootstrap-hydra-env et bootstrap-mercure-env n'installent pas ces binaires. Ils configurent et activent les daemons dédiés par environnement.

4. Répertoires runtime cibles¶

Les répertoires cibles sont:

/opt/heymoov-dev
/opt/heymoov-staging
/opt/heymoov-prod

Principe de migration retenu:

ne pas faire de renommage brutal du runtime legacy en place
créer les nouveaux répertoires cibles
y basculer les services proprement
supprimer le runtime legacy seulement après validation complète

5. Domaine parent¶

La cible retenue est:

tout ce qui peut l'être passe sous heymoov.com
ls2i.net peut rester utilisé temporairement pour des outils internes d'exploitation si nécessaire

Matrice cible par environnement¶

Dev¶

Élément	Cible
Répertoire runtime	`/opt/heymoov-dev`
Fichier d'environnement runtime	`/etc/heymoov/heymoov-dev.env`
Landing	`https://dev.heymoov.com`
App web + BFF	`https://app.dev.heymoov.com`
Hydra/OIDC issuer	`https://auth.dev.heymoov.com`
Mercure	`https://mercure.dev.heymoov.com`
Topics Mercure	`https://app.dev.heymoov.com/`
Uploads/documents	`https://app.dev.heymoov.com/uploads/`
Cookie domain	`dev.heymoov.com`
Frontend callback Hydra	`https://app.dev.heymoov.com/fr/auth/callback`
Callback web Hydra	`https://app.dev.heymoov.com/v1/web/auth/callback`
Callback mobile Hydra	`https://app.dev.heymoov.com/v1/mobile/auth/callback`
Deep link mobile	`heymoov://mobile/auth/complete`

Particularité structurante de dev:

Mercure dev doit autoriser les subscribers depuis https://app.dev.heymoov.com et http://localhost:3006
publish_origins Mercure dev reste limité à https://app.dev.heymoov.com

Staging¶

Élément	Cible
Répertoire runtime	`/opt/heymoov-staging`
Fichier d'environnement runtime	`/etc/heymoov/heymoov-staging.env`
Landing	`https://staging.heymoov.com`
App web + BFF	`https://app.staging.heymoov.com`
Hydra/OIDC issuer	`https://auth.staging.heymoov.com`
Mercure	`https://mercure.staging.heymoov.com`
Topics Mercure	`https://app.staging.heymoov.com/`
Uploads/documents	`https://app.staging.heymoov.com/uploads/`
Cookie domain	`staging.heymoov.com`
Frontend callback Hydra	`https://app.staging.heymoov.com/fr/auth/callback`
Callback web Hydra	`https://app.staging.heymoov.com/v1/web/auth/callback`
Callback mobile Hydra	`https://app.staging.heymoov.com/v1/mobile/auth/callback`
Deep link mobile	`heymoov://mobile/auth/complete`

Prod¶

Élément	Cible
Répertoire runtime	`/opt/heymoov-prod`
Fichier d'environnement runtime	`/etc/heymoov/heymoov-prod.env`
Landing	`https://heymoov.com`
App web + BFF	`https://app.heymoov.com`
Hydra/OIDC issuer	`https://auth.heymoov.com`
Mercure	`https://mercure.heymoov.com`
Topics Mercure	`https://app.heymoov.com/`
Uploads/documents	`https://app.heymoov.com/uploads/`
Cookie domain	`heymoov.com`
Frontend callback Hydra	`https://app.heymoov.com/fr/auth/callback`
Callback web Hydra	`https://app.heymoov.com/v1/web/auth/callback`
Callback mobile Hydra	`https://app.heymoov.com/v1/mobile/auth/callback`
Deep link mobile	`heymoov://mobile/auth/complete`

Séparation technique obligatoire¶

Pour chaque environnement, les éléments suivants doivent être distincts:

répertoire runtime
fichier d'environnement runtime sous /etc/heymoov
base PostgreSQL
instance Hydra
configuration Hydra
stockage Hydra
clients Hydra
hub Mercure
configuration Mercure
uploads
logs
services systemd
timer Expo cleaner
namespace Redis ou base Redis dédiée

Conventions complémentaires:

app.<env>.heymoov.com est l'unique point d'entrée web utile pour le front, le BFF et les URLs /uploads/
aucun environnement cible ne réserve de vhost api.<env>.heymoov.com tant qu'un besoin technique réel ne l'impose pas
le fichier d'environnement runtime n'est pas stocké dans /opt/heymoov-<env>

Hydra et Mercure par environnement¶

Le binaire Hydra et le binaire Mercure sont des dépendances plateforme du host. Ils sont provisionnés une seule fois par Ansible sous /opt/heymoov-platform.

L'isolation par environnement porte sur les services, les fichiers de configuration, les ports, les stockages, les secrets et les clients, pas sur la présence physique d'un binaire différent pour chaque environnement.

Hydra¶

La cible retenue impose une instance Hydra distincte par environnement.

Chaque environnement doit disposer de:

son propre service Hydra
sa propre configuration Hydra
ses propres endpoints internes admin/public
son propre stockage Hydra
ses propres clients OAuth2/OIDC
ses propres secrets et cookies Hydra

Justification:

l'issuer OIDC, les URLs login/consent/logout et l'URL publique sont globaux à une instance Hydra
une instance Hydra partagée ne peut pas exposer proprement auth.dev.heymoov.com et auth.staging.heymoov.com comme deux issuers publics indépendants
partager Hydra entre dev et staging réintroduirait un couplage inter-environnements contraire à la cible

Mercure¶

La cible retenue est également un hub Mercure distinct par environnement.

Chaque environnement doit disposer de:

son propre service Mercure
sa propre configuration de hub
ses propres ports internes
ses propres secrets JWT publisher/subscriber
sa propre liste cors_origins
son propre host public Mercure

Justification:

la séparation par environnement évite les mélanges de topics, d'origins et de secrets entre dev, staging et prod
elle simplifie les rotations de secrets et les diagnostics
un Mercure partagé serait techniquement possible, mais ce n'est pas la cible retenue

Répertoires cibles sur serveur¶

Chaque répertoire runtime doit contenir au minimum:

assets/
config/
logs/
templates/
translations/
uploads/
heymoov-apiGo-linux
heymoov-clean-expo-tokens-linux
éventuellement heymoov-notify-linux si ce binaire reste utilisé sur la machine cible

En dehors du runtime applicatif, chaque environnement doit disposer de:

/etc/heymoov/heymoov-dev.env
/etc/heymoov/heymoov-staging.env
/etc/heymoov/heymoov-prod.env

Le repository ne versionne pas les valeurs effectives de ces fichiers.

Il versionne uniquement une trame générique sans valeurs réelles:

heymoov-platform/deploy/env/heymoov-runtime.env.template

Comptes système et permissions¶

La convention cible conserve:

User=gopher
Group=devs

Justification:

gopher est le compte technique non interactif qui exécute déjà les services applicatifs observés sur ls2i-staging
ce compte possède déjà les répertoires runtime et les binaires historiques et heymoov
le groupe devs permet aux développeurs ayant un compte serveur d'accéder au runtime sans exécuter les services sous leur identité personnelle

Services systemd cibles¶

Dev¶

heymoov-dev-apigo.service
heymoov-dev-clean-expo-tokens.service
heymoov-dev-clean-expo-tokens.timer

Staging¶

heymoov-staging-apigo.service
heymoov-staging-clean-expo-tokens.service
heymoov-staging-clean-expo-tokens.timer

Prod¶

heymoov-prod-apigo.service
heymoov-prod-clean-expo-tokens.service
heymoov-prod-clean-expo-tokens.timer

Principes:

chaque unité pointe vers son propre WorkingDirectory
chaque unité charge son propre EnvironmentFile
chaque unité applicative tourne sous gopher:devs
aucun service cible ne doit réutiliser le runtime legacy

Variables d'environnement runtime cibles¶

Chaque environnement runtime doit fournir au minimum:

APP_NAME
APP_ENV
PGS_HOST
PGS_PORT
PGS_LOGIN
PGS_PASS
PGS_DB
AUTH_COOKIE_DOMAIN
CORS_ALLOWED_ORIGINS_WEB
HYDRA_ADMIN_URL
HYDRA_PUBLIC_URL
HYDRA_OIDC_ISSUER_URL
HYDRA_CALLBACK_URL
HYDRA_MOBILE_CALLBACK_URL
HYDRA_MOBILE_APP_RETURN_URL
HYDRA_FRONTEND_CALLBACK_URL
HYDRA_WEB_CLIENT_ID
HYDRA_MOBILE_CLIENT_ID
HYDRA_CLIENT_SECRETS
MERCURE_URL
MERCURE_TOPICS_PREFIX
FRONTEND_DOCUMENT_URL
FRONTEND_SHOWCASE_URL
FRONTEND_APP_URL
TURNSTILE_EXPECTED_HOSTNAME

Note:

HYDRA_WEB_CLIENT_ID et HYDRA_MOBILE_CLIENT_ID sont des variables cibles à introduire dans le code
la situation actuelle garde encore un identifiant client web legacy dans certains defaults
les variables HYDRA_* doivent toujours viser l'instance Hydra du même environnement
FRONTEND_DOCUMENT_URL doit pointer vers https://app.<env>.heymoov.com/uploads/
MERCURE_URL doit toujours viser le hub Mercure du même environnement
la configuration du hub Mercure doit autoriser au minimum le host app du même environnement dans cors_origins
les valeurs effectives doivent être renseignées hors Git à partir de la trame générique runtime

Clients Hydra cibles¶

Dev¶

heymoov-dev-web
heymoov-dev-mobile

Staging¶

heymoov-staging-web
heymoov-staging-mobile

Prod¶

heymoov-prod-web
heymoov-prod-mobile

Règles:

chaque environnement a son propre couple web/mobile
chaque client a ses propres secrets
chaque client a ses propres callbacks
aucun environnement cible ne doit continuer à dépendre d'un client web legacy

Écarts identifiés entre l'état courant et la cible¶

Runtime serveur¶

le runtime legacy reste actif sur le serveur
l'unité API legacy pointe encore vers les binaires historiques
l'unité du cleaner Expo legacy pointe encore vers les binaires historiques
le log applicatif portait encore un nom historique avant nettoyage du repo
le front app.dev.heymoov.com est temporairement servi depuis l'ancien web root /var/www/staging.sports-connect.net tant que la CI/CD front n'a pas encore été refactorisée

URLs¶

la landing staging existe déjà sous staging.heymoov.com
l'app staging reste encore exposée sur un domaine hérité
l'API staging reste encore exposée sur un domaine hérité
Mercure staging reste encore exposé sur un domaine hérité
l'issuer Hydra staging est encore sous staging.authorization.ls2i.net

Hydra¶

le client web observé reste encore un client legacy
le client mobile observé est heymoov-mobile
le code applicatif gardait encore des defaults historiques avant nettoyage
l'instance Hydra observée sur ls2i-staging reste configurée autour d'un issuer public historique
cette instance partagée ne peut pas servir proprement dev et staging comme deux surfaces OIDC publiques indépendantes
la chaîne repo/déploiement configure maintenant un service Hydra dédié par environnement et vérifie l'issuer live via verify-env
le binaire Hydra observé sur ls2i-staging est maintenant exposé par le contrat cible /opt/heymoov-platform/bin/hydra

Mercure¶

le hub Mercure observé reste encore configuré avec des cors_origins historiques
app.dev.heymoov.com a été ajouté manuellement dans la configuration live du hub dev; la chaîne repo permet maintenant de le porter via bootstrap-mercure-env
la chaîne repo/déploiement configure maintenant un hub Mercure dédié par environnement et vérifie /healthz + CORS live via verify-env
le binaire Mercure observé sur ls2i-staging est maintenant exposé par le contrat cible /opt/heymoov-platform/bin/mercure

Repo/scripts¶

le Makefile principal expose maintenant heymoov-dev, heymoov-staging et heymoov-prod, et isole les cibles de rollback dans legacy/runtime-compat.mk
les scripts systemd supportent maintenant les EnvironmentFile=/etc/heymoov/heymoov-<env>.env et l'interface opérateur install-env / verify-env / activate-env
le repository expose maintenant un inventaire de topologie non secret pour associer ENV, HOST et PORT_SLOT
le repository expose maintenant topology-env pour rendre et contrôler localement la topologie résolue avant exécution
le repository expose maintenant bootstrap-storage-env pour préparer PostgreSQL + Redis côté serveur
le repository expose toujours bootstrap-postgres-env et bootstrap-redis-env comme briques bas niveau
le repository expose maintenant bootstrap-runtime-env pour compléter les conventions runtime et générer les secrets applicatifs locaux
le repository expose maintenant bootstrap-hydra-env pour configurer ou mettre à jour le daemon Hydra dédié d'un environnement
le repository expose maintenant bootstrap-mercure-env pour configurer ou mettre à jour le daemon Mercure dédié d'un environnement
verify-env contrôle maintenant l'issuer Hydra live, le healthcheck Mercure et le CORS Mercure du même environnement
le repository expose maintenant bootstrap-hydra-clients pour créer ou mettre à jour les clients OAuth2 Hydra par environnement
toute la surface nginx de heymoov-dev et heymoov-staging est maintenant versionnée dans le repository
la landing staging.heymoov.com est maintenant déployée par GitHub Actions avec build GitHub-hosted et deploy sur runner self-hosted
heymoov-prod reste encore à versionner côté edge
des labels techniques historiques restaient encore visibles dans certains chemins de migration, logs et docs avant ce nettoyage

Plan de mise en œuvre cible¶

Phase 0 - Provisioning host¶

Le détail de cette phase est suivi dans heymoov-docs/reference/infra/heymoov-host-provisioning.md.

Côté backend, la phase consiste seulement à vérifier que les chemins plateforme cibles existent et sont consommés par les scripts:

/opt/heymoov-platform/bin/hydra
/opt/heymoov-platform/bin/mercure

Phase 1 - Repo et scripts¶

rendre les clients Hydra configurables par environnement
séparer clairement heymoov-dev, heymoov-staging, heymoov-prod dans le Makefile
sortir les valeurs par défaut legacy des binaires, services et répertoires
mettre à jour les templates/systemd et scripts de déploiement

Phase 2 - Hydra, Mercure et variables runtime¶

fixer la convention d'isolement Hydra par environnement
fixer la convention d'isolement Mercure par environnement
préparer les fichiers de configuration et les secrets associés hors Git
ajouter les vérifications de cohérence Hydra live et Mercure live dans la chaîne opérateur via verify-env
intégrer explicitement la gestion de cors_origins Mercure dans la chaîne, avec https://app.<env>.heymoov.com comme origin web de référence et suppression des origins legacy
corriger les exemples legacy du repo qui pointent encore vers /.well-known/mercure quand ils décrivent l'URL publique, et réserver /.well-known/mercure au proxy interne Nginx vers le hub
versionner/piloter la configuration live du hub Mercure dans la chaîne repo/déploiement, via bootstrap-mercure-env: env daemon, Caddyfile, ports internes par slot, cors_origins, clés JWT publisher/subscriber, transport bolt { path mercure.db size 10 cleanup_frequency 1 } et grace_period 30s
créer les clients Hydra cibles pour dev
créer les clients Hydra cibles pour staging
préparer les secrets et callbacks associés
préparer les fichiers /etc/heymoov/heymoov-<env>.env
préparer les bases PostgreSQL applicative/Hydra et le namespace Redis via un bootstrap storage dédié
générer les secrets runtime locaux via un bootstrap dédié
aligner les variables runtime sur les domaines heymoov.com

Phase 3 - Runtime dev¶

créer /opt/heymoov-dev
bootstrapper le daemon Hydra dev
bootstrapper le daemon Mercure dev
y copier/installer le runtime utile depuis l'ancien runtime legacy
créer les nouvelles unités systemd dev
installer les vhosts dev.heymoov.com, app.dev.heymoov.com, auth.dev.heymoov.com, mercure.dev.heymoov.com
démarrer et valider heymoov-dev
une fois la CI/CD front refactorisée, rebasculer explicitement app.dev.heymoov.com vers son web root cible /var/www/app.dev.heymoov.com

Phase 4 - Runtime staging¶

créer /opt/heymoov-staging
bootstrapper le daemon Hydra staging
bootstrapper le daemon Mercure staging
y installer le runtime dédié staging
créer les nouvelles unités systemd staging
installer les vhosts staging.heymoov.com, app.staging.heymoov.com, auth.staging.heymoov.com, mercure.staging.heymoov.com
valider heymoov-staging

Phase 5 - Nettoyage final¶

retirer les dépendances runtime au legacy
retirer les unités systemd legacy
archiver puis supprimer le runtime legacy
nettoyer les docs et scripts restants portant un naming historique

Fichiers repo à modifier ou revisiter¶

Repo / déploiement¶

Hydra / auth / realtime¶

Logging / naming¶

heymoov-api/config/gin.go

Suivi d'avancement¶

Décisions déjà prises¶

[x] Le module Go cible est lso-labs/heymoov
[x] Le nouveau dépôt distant est git@github.com:LSO-Labs/heymoov.git
[x] La branche de migration est heymoov-migration
[x] L'historique de l'ancien binaire principal a été purgé sur le nouveau remote
[x] Les imports Go historiques ont été remplacés
[x] Les anciens chemins locaux du projet ont été nettoyés
[x] La cible de domaines publics passe prioritairement sous heymoov.com
[x] La cible runtime est heymoov-dev + heymoov-staging sur ls2i-staging
[x] Hydra doit être isolé par environnement
[x] Mercure doit être isolé par environnement

Repo / code¶

[x] Renommer le module Go vers lso-labs/heymoov
[x] Rendre HYDRA_WEB_CLIENT_ID configurable
[x] Rendre HYDRA_MOBILE_CLIENT_ID configurable
[x] Sortir le client web legacy des constantes/appels applicatifs
[x] Sortir heymoov-mobile hardcode au profit d'une variable d'environnement
[ ] Renommer les derniers labels techniques historiques restants
[x] Refactorer le Makefile pour heymoov-dev
[x] Refactorer le Makefile pour heymoov-staging
[x] Refactorer le Makefile pour heymoov-prod
[x] Exposer install-env, verify-env et activate-env
[x] Exposer bootstrap-storage-env
[x] Exposer bootstrap-postgres-env
[x] Exposer bootstrap-redis-env
[x] Exposer bootstrap-runtime-env
[x] Exposer bootstrap-hydra-env
[x] Exposer bootstrap-mercure-env
[x] Exposer bootstrap-hydra-clients
[x] Versionner le vhost app.dev.heymoov.com
[x] Versionner toute la surface nginx de heymoov-dev
[x] Versionner les vhosts nginx cibles de heymoov-staging
[ ] Versionner les vhosts nginx cibles de heymoov-prod

Infra serveur¶

[x] Créer /opt/heymoov-dev
[ ] Créer /opt/heymoov-staging
[x] Aligner Hydra sur /opt/heymoov-platform/bin/hydra
[x] Aligner Mercure sur /opt/heymoov-platform/bin/mercure
[ ] Bootstrapper les bases PostgreSQL heymoov_staging et heymoov_staging_hydra
[ ] Bootstrapper le namespace Redis de heymoov-staging
[ ] Bootstrapper les valeurs runtime de heymoov-staging
[ ] Bootstrapper le daemon Hydra dédié de heymoov-staging
[ ] Bootstrapper le daemon Mercure dédié de heymoov-staging
[ ] Préparer /opt/heymoov-prod sur le serveur de production
[x] Préparer /var/www/staging.heymoov.com avec releases/, .tmp/ et current
[x] Installer le runner heymoov-landing-deploy-staging sur ls2i-staging
[x] Configurer l'environnement GitHub staging du repo heymoov-landing
[x] Activer la CI/CD GitHub Actions de la landing staging.heymoov.com
[ ] Migrer la landing prod hors du builder historique /opt/builder
[ ] Retirer l'exception temporaire heymoov-dev qui autorise staging.heymoov.com en CORS public et Turnstile, une fois app.staging.heymoov.com en service
[ ] Revenir à la cible heymoov-dev cohérente après cette exception: CORS_ALLOWED_ORIGINS_WEB_DEV=http://localhost:3006 et TURNSTILE_EXPECTED_HOSTNAME=app.dev.heymoov.com
[ ] Reconfigurer la landing staging pour pointer vers https://app.staging.heymoov.com au lieu de https://app.dev.heymoov.com
[ ] Bloquer l'exposition publique de /release.json sur la landing prod (le garder au besoin seulement en staging)
[x] Créer les unités heymoov-dev-apigo et heymoov-dev-clean-expo-tokens
[ ] Créer les unités heymoov-staging-apigo et heymoov-staging-clean-expo-tokens
[x] Installer les vhosts dev.heymoov.com, app.dev.heymoov.com, auth.dev.heymoov.com, mercure.dev.heymoov.com
[x] Émettre les certificats TLS dev
[x] Activer le runtime applicatif heymoov-dev sur ls2i-staging
[x] Basculer heymoov-dev sur heymoov_dev et heymoov_dev_hydra, puis supprimer les bases legacy spoc et hydra après backup final /var/backups/heymoov-legacy-postgres-drop/20260430T202011Z
[ ] Supprimer le backup serveur /root/heymoov-cleanup-20260423T212541Z une fois validé que le rollback sports-connect n'est plus nécessaire
[ ] Supprimer le backup serveur /root/heymoov-cleanup-20260423T214115Z/systemd une fois validé que le rollback des unités legacy n'est plus nécessaire
[ ] Supprimer le backup serveur /root/heymoov-cleanup-20260424T145826Z/landing-staging une fois validé que le rollback de la landing staging n'est plus nécessaire
[ ] Rebasculer app.dev.heymoov.com du web root temporaire /var/www/staging.sports-connect.net vers le web root cible /var/www/app.dev.heymoov.com
[ ] Supprimer la dépendance active à sportsconnect-apigo.service
[ ] Supprimer la dépendance active au cleaner Expo legacy

Hydra / DNS / URLs¶

[x] Créer heymoov-dev-web
[x] Créer heymoov-dev-mobile
[ ] Créer heymoov-staging-web
[ ] Créer heymoov-staging-mobile
[ ] Créer heymoov-prod-web
[ ] Créer heymoov-prod-mobile
[x] Créer les entrées DNS dev, app.dev, auth.dev, mercure.dev
[ ] Basculer l'app dev vers app.dev.heymoov.com
[ ] Basculer Hydra dev vers auth.dev.heymoov.com
[ ] Basculer Mercure dev vers mercure.dev.heymoov.com
[ ] Basculer l'app staging vers app.staging.heymoov.com
[ ] Basculer Hydra staging vers auth.staging.heymoov.com
[ ] Basculer Mercure staging vers mercure.staging.heymoov.com

Hydra / Mercure par environnement¶

[x] Provisionner le binaire Hydra host sous /opt/heymoov-platform/bin/hydra
[x] Provisionner le binaire Mercure host sous /opt/heymoov-platform/bin/mercure
[x] Bootstrapper un daemon Hydra dédié pour dev
[ ] Bootstrapper un daemon Hydra dédié pour staging
[ ] Bootstrapper un daemon Hydra dédié pour prod
[x] Bootstrapper un hub Mercure dédié pour dev
[ ] Bootstrapper un hub Mercure dédié pour staging
[ ] Bootstrapper un hub Mercure dédié pour prod
[x] Intégrer la vérification live de l'issuer Hydra dans la chaîne verify
[x] Intégrer la vérification des cors_origins Mercure dans la chaîne verify
[x] Intégrer le rendu/déploiement des cors_origins Mercure dans la chaîne de bootstrap daemon
[ ] Corriger les exemples et templates legacy qui publient encore /.well-known/mercure comme URL externe, pour conserver https://mercure.<env>.heymoov.com comme URL publique et http://127.0.0.1:<port>/.well-known/mercure uniquement comme upstream Nginx interne
[x] Intégrer la configuration live du hub Mercure dans la chaîne repo/déploiement, avec une trame explicite pour cors_origins, publisher_jwt, subscriber_jwt, les ports internes par environnement, transport bolt { path mercure.db size 10 cleanup_frequency 1 }, et grace_period 30s

Secrets runtime¶

[ ] Phase 1: créer le groupe strict heymoov-deploy
[ ] Phase 1: passer /etc/heymoov/heymoov-<env>.env en root:heymoov-deploy 0640
[ ] Phase 1: exécuter les migrations sur le serveur avec /usr/local/bin/heymoov-goose
[ ] Phase 1: synchroniser uniquement les migrations exécutables vers /opt/heymoov-<env>/migrations
[ ] Phase 1: retirer les tunnels PostgreSQL et les .env.heymoov-* locaux du chemin release
[ ] Phase 1: exiger une confirmation explicite avant toute release prod
[ ] Phase 2: garder dans EnvironmentFile uniquement la configuration runtime non sensible
[ ] Phase 2: migrer les secrets runtime (PGS_PASS, clés JWT, secrets Hydra, secrets Mercure, secrets providers) vers LoadCredential= ou LoadCredentialEncrypted=
[ ] Phase 2: adapter le bootstrap Go pour lire ces secrets depuis les credentials systemd au lieu d'attendre un .env
[ ] Phase 2: lancer le runner de migrations via systemd-run ou une unité dédiée chargeant les credentials

Nettoyage final¶

[ ] Retirer le runtime legacy du serveur
[ ] Retirer les références runtime legacy
[ ] Retirer les références systemd legacy
[ ] Archiver puis supprimer le runtime legacy

Notes de pilotage¶

Toute modification infra doit permettre un rollback simple.
Les secrets ne doivent pas être documentés ici.
Le code garde encore un fallback par défaut sur un client web legacy / heymoov-mobile tant que les nouvelles variables runtime ne surchargent pas explicitement ces IDs.
Le bootstrap Hydra cible crée un client web confidentiel en client_secret_post et un client mobile public en token_endpoint_auth_method=none.
Tant que Hydra et Mercure ne sont pas isolés par environnement, la coexistence dev / staging reste incomplète.
Tant que les URLs app/auth/mercure ne sont pas toutes basculées sur heymoov.com, le rebranding infra reste partiel.