Django · Documentation

Django

Déployez Django avec Postgres, des workers Celery ou RQ, collectstatic et les migrations.

Détecté à partir de requirements.txt, pyproject.toml ou un manage.py qui importe Django.
Version : python manage.py migrate --no-input.
Web : gunicorn sur $PORT, définissez votre module WSGI dans la commande de démarrage s’il n’est pas wsgi:application.
Workers : Celery (celery -A <project> worker, le projet est lu depuis DJANGO_SETTINGS_MODULE), Celery Beat, RQ, Huey, Dramatiq et Django-Q sont proposés quand ce sont des dépendances.
Base de données : psycopg → Postgres, avec DATABASE_URL injecté.

Processus : un seul code, plusieurs rôles

web, worker et un processus planifié beat sont la même image démarrée avec une commande différente — le modèle de processus 12-factor, pas des applications séparées à garder synchronisées entre elles. Déclarez-les vous-même dans un 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

ou sautez le Procfile et laissez la détection proposer le worker pour vous à partir de la bibliothèque de tâches présente dans vos dépendances. Ajoutez-en d’autres depuis l’onglet Workers de l’application, ou mettez à l’échelle ce qui existe déjà depuis la CLI :

railyard scale my-app worker=2

Voir Workers et tâches planifiées pour le cron.

Fichiers statiques

python manage.py collectstatic --noinput s’exécute automatiquement dans l’étape de build — la même convention que le buildpack Python de Heroku — donc WhiteNoise ou n’importe quelle configuration STATIC_ROOT fonctionne sans Dockerfile ni pre-deploy hook à écrire. Une application qui n’utilise pas django.contrib.staticfiles n’est pas affectée, et un échec ici ne bloque pas le reste du build. Définissez DISABLE_COLLECTSTATIC=1 pour désactiver ce comportement.

Configuration et secrets

DATABASE_URL est injecté automatiquement à partir de votre addon Postgres; REDIS_URL aussi, dès que vos dépendances déclarent un client Redis (redis, django-redis, rq) — pointez le broker et le result backend de Celery vers lui vous-même. Tout le reste — DJANGO_SETTINGS_MODULE, SECRET_KEY, feature flags — est une simple variable d’environnement sous Variables, ou définie avec railyard env:set my-app KEY=VALUE depuis la CLI, donc la même image tourne sans changement de staging jusqu’en production : la parité dev/prod, pas une branche au moment du build. Pour pointer vers une base de données ou un Redis qui tourne comme son propre service sur le canvas, référencez-le avec ${{redis.RAILYARD_PRIVATE_URL}} — résolu par environnement. Voir Variables et secrets.

Déployez-le

Depuis un dépôt : collez l’URL Git, ou choisissez-le dans le sélecteur une fois GitHub connecté — Railyard lit requirements.txt/pyproject.toml, remplit gunicorn, la commande de release migrate et DATABASE_URL, et déploie à chaque push.
Depuis la CLI : railyard create my-app https://github.com/me/my-app --addons postgres,redis, ou railyard git:remote && git push railyard main depuis le dépôt.
En un clic : ajoutez le bouton de déploiement à votre README, ou publiez-le dans le catalogue de modèles pour que n’importe qui puisse le lancer avec ses addons et variables déjà remplis.