Fazendo deploy de Flask: um micro-framework precisa de micro-configuração, não de nenhuma

O Django vem com um ORM, um sistema de migrations e um admin de fábrica, então um host pode assumir com segurança que manage.py migrate existe. O Flask não toma nenhuma dessas decisões por você — o que é exatamente o atrativo, e exatamente por que um deploy de Flask não deveria fingir que existe uma convenção de framework pra auto-detectar onde nenhuma existe. A versão honesta: detectar o que de fato é uma dependência, e ficar quieto sobre tudo o mais.

O que é detectado

• O próprio Flask, a partir do requirements.txt ou pyproject.toml listando flask.
• O processo web roda o gunicorn contra app:app por padrão — se a aplicação vive em outro lugar, ou é construída com uma app factory, isso é uma linha pra definir explicitamente: "myapp:create_app()".
• psycopg/psycopg2 como dependência provisiona o Postgres e injeta DATABASE_URL; um cliente Redis (redis, rq) faz o mesmo pro REDIS_URL.
• O RQ é oferecido automaticamente como worker quando é uma dependência — o RQ tem uma convenção óbvia (uma fila conectada ao Redis), então é seguro detectar.

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

O que deliberadamente não é adivinhado, e por quê

Diferente do Django, não existe um comando de release padrão — porque, diferente do Django, não existe uma ferramenta de migration padrão. Com o Flask-Migrate instalado, defina o comando de release como flask db upgrade; com Alembic puro, alembic upgrade head. O mesmo com o Celery: não existe um único lugar onde a instância Celery de uma aplicação Flask vive, então ela não é auto-detectada do jeito que o RQ é — uma linha num Procfile ou na aba Workers é o equivalente honesto de uma decisão que só o próprio código da aplicação de fato toma:

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

railyard scale my-app worker=2

Chutar errado aqui não só falharia — rodaria silenciosamente a ferramenta de migration errada ou apontaria pra uma instância de aplicação Celery que não existe, o que é pior do que pedir uma linha de antemão.

Configuração e secrets

SECRET_KEY, FLASK_ENV, e qualquer outra coisa que os.environ lê vivem em Variables, ou em railyard env:set my-app KEY=VALUE — variáveis de ambiente simples, nunca embutidas na imagem, então o exato mesmo build roda sem mudanças do staging até a produção.

Referência completa: Flask docs, Workers and scheduled jobs.