Checklist de déploiement production¶

Liste actionnable pour mettre une application Forge en production proprement. Cette page est un fil conducteur ; les détails vivent dans les guides liés en bas. Ticket : PRODUCTION-CHECKLIST-DOCS-001.

1. Avant de déployer — vérifications¶

Lance ces commandes depuis le projet, dans l'environnement cible :

forge doctor                    # diagnostic complet (Python, env, DB, SSL, sécurité prod…)
forge migration:apply --dry-run # aperçu des migrations à appliquer + leur SQL, sans rien exécuter

forge doctor inclut un check Sécurité prod : il vérifie que l'application tourne avec un compte base de données applicatif (et non le compte admin), et que les uploads sont bornés (UPLOAD_MAX_SIZE) et restreints (UPLOAD_ALLOWED_EXTENSIONS). Corrige tout [WARN]/[FAIL] avant d'exposer.

[ ] forge doctor ne remonte aucun [FAIL].
[ ] Le check Sécurité prod est [OK].
[ ] forge migration:apply --dry-run montre exactement ce que tu attends.
[ ] La suite de tests passe sur la version déployée.

2. Configuration `env/prod`¶

[ ] env/prod existe et ne contient aucun secret réel commité (les fichiers env/* sont protégés et ignorés du suivi).
[ ] APP_ENV=prod.
[ ] Compte DB applicatif (DB_APP_*) distinct du compte admin (DB_ADMIN_*), avec privilèges minimaux. → Configurer les comptes MariaDB d'un projet.
[ ] SSL_CERTFILE / SSL_KEYFILE configurés (ou TLS terminé par le reverse proxy — voir §4).
[ ] Limites d'upload : UPLOAD_MAX_SIZE, UPLOAD_ALLOWED_EXTENSIONS, UPLOAD_ALLOWED_MIME_TYPES.

3. Sessions¶

[ ] Ne pas utiliser le store mémoire en production (sessions perdues au redémarrage). Forge avertit au démarrage en APP_ENV=prod avec un store mémoire — configure un store partagé (ex. FileSessionStore). Voir ADR-002.

4. Serveur d'application + reverse proxy¶

[ ] Servir via WSGI (pas le serveur de dev forge run). → Déploiement WSGI minimal.
[ ] Placer Forge derrière Caddy / Nginx (TLS, en-têtes, fichiers statiques). → Déploiement avancé.
[ ] Vérifier les en-têtes de sécurité et la CSP. → Sécurité en production.

5. Migrations & exploitation¶

[ ] forge migration:apply --dry-run puis forge migration:apply (sauvegarde la base avant en prod).
[ ] Vérifier les logs côté serveur (les erreurs détaillées y vont ; la page d'erreur publique reste sobre, sans stacktrace).
[ ] Connaître les limites de production assumées.

6. Mise à jour¶

forge update --check     # version installée + commande de mise à jour suggérée

forge update ne modifie pas ton projet et ne lance aucune migration automatiquement (pip en venv, ou pipx upgrade en installation pipx).

À ne jamais faire en production¶

Lancer forge run (serveur de développement) comme serveur public.
Utiliser le compte DB admin comme compte applicatif.
Stocker des secrets réels dans des fichiers commités.
Exposer un store de sessions mémoire.
Appliquer des migrations sans --dry-run préalable ni sauvegarde.