Desplegar Flask: un microframework necesita microconfiguración, no ninguna

Django trae un ORM, un sistema de migraciones y un admin de fábrica, así que un host puede asumir con seguridad que manage.py migrate existe. Flask no toma ninguna de esas decisiones por ti — que es exactamente el atractivo, y exactamente por qué un despliegue de Flask no debería fingir que hay una convención de framework para autodetectar donde no existe ninguna. La versión honesta: detecta lo que de verdad es una dependencia, y quédate callado sobre todo lo demás.

Qué se detecta

• Flask mismo, a partir de requirements.txt o pyproject.toml que listan flask.
• El proceso web corre gunicorn contra app:app por defecto — si la app vive en otro lado, o está construida con un app factory, esa es una línea que definir explícitamente: "myapp:create_app()".
• psycopg/psycopg2 como dependencia aprovisiona Postgres e inyecta DATABASE_URL; un cliente de Redis (redis, rq) hace lo mismo para REDIS_URL.
• RQ se ofrece automáticamente como worker cuando es una dependencia — RQ tiene una convención obvia (una cola conectada a Redis), así que es seguro detectarla.

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

Qué deliberadamente no se adivina, y por qué

A diferencia de Django, no hay un comando de release por defecto — porque a diferencia de Django, no hay una herramienta de migraciones por defecto. Con Flask-Migrate instalado, define el comando de release como flask db upgrade; con Alembic puro, alembic upgrade head. Lo mismo con Celery: no hay un único lugar donde viva la instancia de Celery de una app de Flask, así que no se autodetecta como sí se hace con RQ — una línea en un Procfile o en la pestaña Workers es el equivalente honesto a una decisión que solo el propio código de la app puede tomar de verdad:

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

railyard scale my-app worker=2

Adivinar mal aquí no solo fallaría — correría en silencio la herramienta de migraciones equivocada o apuntaría a una instancia de Celery que no existe, lo cual es peor que pedir una línea de entrada.

Configuración y secretos

SECRET_KEY, FLASK_ENV, y cualquier otra cosa que lea os.environ viven en Variables, o con railyard env:set my-app KEY=VALUE — variables de entorno simples, nunca horneadas en la imagen, así que exactamente el mismo build corre sin cambios desde staging hasta producción.

Referencia completa: Documentación de Flask, Workers y jobs programados.