Déployer Flask : un micro-framework a besoin d'une micro-configuration, pas d'aucune

Django livre un ORM, un système de migration et un admin prêts à l’emploi, donc un hébergeur peut supposer sans risque que manage.py migrate existe. Flask ne prend aucune de ces décisions pour vous — ce qui est exactement l’attrait, et exactement pourquoi un déploiement Flask ne devrait pas prétendre qu’il y a une convention de framework à détecter automatiquement là où il n’y en a aucune. La version honnête : détecter ce qui est réellement une dépendance, et rester silencieux sur tout le reste.

Ce qui est détecté

• Flask lui-même, depuis requirements.txt ou pyproject.toml listant flask.
• Le processus web lance gunicorn contre app:app par défaut — si l’application vit ailleurs, ou est construite avec une fabrique d’application, c’est une ligne à régler explicitement : "myapp:create_app()".
• psycopg/psycopg2 comme dépendance provisionne Postgres et injecte DATABASE_URL; un client Redis (redis, rq) fait pareil pour REDIS_URL.
• RQ est offert automatiquement comme worker quand c’est une dépendance — RQ a une convention évidente (une file connectée à Redis), donc c’est sûr de la détecter.

railyard create my-app https://github.com/me/my-app --addons postgres,redis

Ce qui n’est délibérément pas deviné, et pourquoi

Contrairement à Django, il n’y a pas de commande de release par défaut — parce que contrairement à Django, il n’y a pas d’outil de migration par défaut. Avec Flask-Migrate installé, réglez la commande de release sur flask db upgrade; avec Alembic simple, alembic upgrade head. Même chose avec Celery : il n’y a pas d’endroit unique où vit l’instance Celery d’une application Flask, donc elle n’est pas auto-détectée comme RQ l’est — une ligne dans un Procfile ou sur l’onglet Workers est l’équivalent honnête d’une décision que seul le code de l’application lui-même prend réellement :

web:    gunicorn app:app --bind 0.0.0.0:$PORT
worker: celery -A myapp.celery worker

railyard scale my-app worker=2

Deviner mal ici ne ferait pas que échouer — ça ferait silencieusement tourner le mauvais outil de migration ou pointerait vers une instance Celery qui n’existe pas, ce qui est pire que de demander une ligne au préalable.

Config et secrets

SECRET_KEY, FLASK_ENV, et tout ce que os.environ lit vivent sous Variables, ou via railyard env:set my-app KEY=VALUE — des variables d’environnement simples, jamais intégrées dans l’image, donc exactement le même build tourne sans changement de staging jusqu’à la production.

Référence complète : Documentation Flask, Workers et tâches planifiées.