Flask deployen: Ein Micro-Framework braucht Micro-Konfiguration, nicht gar keine

Django liefert ein ORM, ein Migrationssystem und ein Admin-Interface direkt mit, sodass ein Host sicher annehmen kann, dass manage.py migrate existiert. Flask trifft keine dieser Entscheidungen für dich — was genau der Reiz ist, und genau der Grund, warum ein Flask-Deploy nicht so tun sollte, als gäbe es eine Framework-Konvention zum automatischen Erkennen, wo keine existiert. Die ehrliche Variante: erkenne, was tatsächlich eine Abhängigkeit ist, und schweige über alles andere.

Was erkannt wird

• Flask selbst, anhand von requirements.txt oder pyproject.toml, die flask auflisten.
• Der Web-Prozess läuft standardmäßig mit gunicorn gegen app:app — wenn die App woanders liegt oder mit einer App-Factory gebaut ist, ist das eine Zeile, die explizit gesetzt wird: "myapp:create_app()".
• psycopg/psycopg2 als Abhängigkeit stellt Postgres bereit und fügt DATABASE_URL ein; ein Redis-Client (redis, rq) macht dasselbe für REDIS_URL.
• RQ wird automatisch als Worker angeboten, wenn es eine Abhängigkeit ist — RQ hat eine offensichtliche Konvention (eine mit Redis verbundene Queue), also lässt es sich sicher erkennen.

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

Was bewusst nicht erraten wird, und warum

Anders als bei Django gibt es keinen Standard-Release-Befehl — weil es anders als bei Django kein Standard-Migrationstool gibt. Mit installiertem Flask-Migrate setze den Release-Befehl auf flask db upgrade; mit reinem Alembic auf alembic upgrade head. Dasselbe gilt für Celery: Es gibt keinen einzigen Ort, an dem die Celery-Instanz einer Flask-App lebt, also wird es nicht automatisch erkannt wie RQ — eine Zeile in einem Procfile oder im Workers-Tab ist das ehrliche Äquivalent zu einer Entscheidung, die eigentlich nur der eigene Code der App trifft:

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

railyard scale my-app worker=2

Hier falsch zu raten würde nicht nur fehlschlagen — es würde stillschweigend das falsche Migrationstool ausführen oder auf eine Celery-App-Instanz zeigen, die nicht existiert, was schlimmer ist, als vorher um eine Zeile zu bitten.

Konfiguration und Secrets

SECRET_KEY, FLASK_ENV und alles andere, was os.environ liest, leben unter Variables, oder railyard env:set my-app KEY=VALUE — reine Umgebungsvariablen, nie ins Image eingebacken, sodass genau derselbe Build unverändert von Staging bis Produktion läuft.

Vollständige Referenz: Flask-Docs, Worker und geplante Jobs.