Django

• Erkannt anhand von requirements.txt, pyproject.toml oder einer manage.py, die Django importiert.
• Release: python manage.py migrate --no-input.
• Web: gunicorn auf $PORT — setze dein WSGI-Modul im Startbefehl, falls es nicht wsgi:application ist.
• Workers: Celery (celery -A <project> worker, Projekt aus DJANGO_SETTINGS_MODULE gelesen), Celery Beat, RQ, Huey, Dramatiq und Django-Q werden angeboten, wenn sie Abhängigkeiten sind.
• Datenbank: psycopg → Postgres, mit injiziertem DATABASE_URL.

Prozesse: eine Codebasis, mehrere Rollen

web, worker und ein geplanter beat-Prozess sind dasselbe Image, nur mit einem anderen Befehl gestartet — das Prozessmodell von 12-Factor, keine separaten Apps, die man synchron halten muss. Deklariere sie selbst in einem Procfile:

web: gunicorn myproject.wsgi:application --bind 0.0.0.0:$PORT
worker: celery -A myproject worker --loglevel=info
beat: celery -A myproject beat --loglevel=info

oder überspringe das Procfile und lass die Erkennung den Worker für dich anbieten, je nachdem, welche Job-Library in deinen Abhängigkeiten steckt. Füge weitere im Tab Workers der App hinzu, oder skaliere die vorhandenen über die CLI:

railyard scale my-app worker=2

Siehe Workers und geplante Jobs für Cron.

Statische Dateien

python manage.py collectstatic --noinput läuft automatisch im Build-Schritt — dieselbe Konvention, die Herokus Python-Buildpack verwendet —, sodass WhiteNoise oder jedes STATIC_ROOT-Setup ohne Dockerfile-Schritt oder Pre-Deploy-Hook einfach funktioniert. Eine App, die django.contrib.staticfiles nicht nutzt, ist davon nicht betroffen, und ein Fehlschlag hier blockiert nicht den Rest des Builds. Setze DISABLE_COLLECTSTATIC=1, um das abzuschalten.

Konfiguration und Secrets

DATABASE_URL wird automatisch aus deinem Postgres-Addon injiziert; REDIS_URL ebenso, sobald deine Abhängigkeiten einen Redis-Client fixieren (redis, django-redis, rq) — richte Celerys Broker und Result-Backend selbst darauf aus. Alles andere — DJANGO_SETTINGS_MODULE, SECRET_KEY, Feature-Flags — ist eine normale Env-Variable unter Variables, oder railyard env:set my-app KEY=VALUE über die CLI, sodass dasselbe Image unverändert von Staging bis Produktion läuft: Dev/Prod-Parität, kein Branch zur Build-Zeit. Verweise auf eine Datenbank oder Redis, die als eigener Dienst auf dem Canvas laufen, mit ${{redis.RAILYARD_PRIVATE_URL}} — pro Umgebung aufgelöst. Siehe Variablen und Secrets.

So deployst du

• Aus einem Repo: Füge die Git-URL ein, oder wähle es aus der Liste, sobald GitHub verbunden ist — Railyard liest requirements.txt/pyproject.toml, füllt gunicorn, den migrate-Release-Befehl und DATABASE_URL aus und deployt bei jedem Push.
• Über die CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, oder railyard git:remote && git push railyard main aus dem Repo heraus.
• Ein Klick: Füge den Deploy-Button zu deiner README hinzu, oder veröffentliche im Template-Katalog, damit jeder es mit bereits ausgefüllten Addons und Variablen starten kann.