Déployer Django en production, Celery compris
Une application Django en production, c’est un serveur WSGI ou ASGI, une base, Redis, des workers Celery et un beat. Les cinq se posent en blocs sur le canvas et se déploient depuis votre dépôt Git, sans YAML.
Sans carte bancaire, sans engagement.
Votre dépôt Django
- Application Django
- PostgreSQL
- Redis
- Workers Celery
- Celery beat
- Stockage objet
Kubernetes, monté et opéré par Fransys
Le cloud européen choisi Scaleway · OVHcloud · Hetzner · Outscale
Ce qu’il faut construire entre runserver et la production
Sur le poste du développeur, Django tient dans une commande. En production, la checklist de Django demande un vrai serveur WSGI ou ASGI, le debug coupé, une clé secrète, des hôtes autorisés, des fichiers statiques collectés et des médias à part. Celery ajoute un broker, des workers et un ordonnanceur. Le canvas décrit toute cette architecture, code compris, et la plateforme l’opère.
- 5blocs pour une app Django complète
- 1geste de déploiement : git push
- 0ligne de YAML à écrire
L’architecture Django type, bloc par bloc
-
L’application
Votre dépôt, construit depuis son Dockerfile et servi par un serveur WSGI ou ASGI, Gunicorn ou Uvicorn par exemple. Domaines, TLS et variables d’environnement se règlent dans le bloc.
-
La base de données
PostgreSQL managé, sauvegardes automatiques. Reliez le bloc :
DB_HOST,DB_PASSWORDet les autres identifiants sont injectés dans l’application. -
Redis
Le broker de Celery et le cache sur un bloc dédié, dimensionné à part. L’URL du broker se compose à partir des variables injectées.
-
Les workers Celery
Un second bloc Docker sur le même dépôt, avec son Dockerfile, lance
celery -A proj worker -l INFOsur ses propres ressources. Au signalTERM, il finit les tâches en cours avant de s’arrêter. -
Celery beat
Un bloc à part, et une seule instance : deux ordonnanceurs enverraient les tâches en double. La documentation de Celery déconseille de l’embarquer dans le worker en production.
-
Les fichiers
Les statiques entrent dans l’image avec
collectstatic, servis par WhiteNoise par exemple. Les médias, envoyés par vos utilisateurs, vont sur un stockage objet compatible S3, jamais dans l’image.
Du push à la mise en ligne
-
git pushLe commit part sur la branche configurée.
-
buildL’image est construite avec vos dépendances Python et vos fichiers statiques collectés.
-
migrateLes migrations s’exécutent avant la bascule du trafic.
-
liveLa nouvelle version reçoit le trafic. En cas d’échec, retour automatique à la précédente.
Avec votre agent, ou à la main
Avec votre agentexemple
Déploie mon app Django : PostgreSQL, Redis, un worker Celery et le beat.
- L'agent lit votre dépôt et prépare le plan : les blocs, chacun avec son prix.
- Une personne de l'équipe valide le plan.
- Le moteur exécute ; les migrations passent avant la bascule du trafic.
À la main
- Posez les blocs sur le canvas : application, base, Redis, worker, beat.
- Branchez votre dépôt Git, déclarez la migration dans les commandes de déploiement.
- Poussez sur la branche configurée : la version part en ligne.
Ce qu’on nous demande sur Django
Fransys a-t-il un bloc Django ?
Django passe par le bloc Docker, avec votre Dockerfile. Laravel, React, Angular et Vue ont un bloc natif ; les autres frameworks passent par ce bloc, qui a les mêmes connexions, variables, métriques et journaux.
Comment sont gérées les migrations ?
python manage.py migrate se déclare dans les commandes de déploiement du bloc. Elle s’exécute après le déploiement de la nouvelle image et avant la bascule du trafic. Si elle échoue, le déploiement s’arrête et la version en ligne n’est pas touchée.
Mes formulaires renvoient une erreur CSRF en HTTPS : pourquoi ?
Le certificat est posé à l’entrée du cluster, et le proxy peut masquer à Django que la requête d’origine était en HTTPS. Réglez SECURE_PROXY_SSL_HEADER sur le couple HTTP_X_FORWARDED_PROTO et https, ajoutez vos domaines à ALLOWED_HOSTS et leurs origines en https à CSRF_TRUSTED_ORIGINS.
Que vérifier avant la mise en production ?
Lancez python manage.py check --deploy, comme le demande la checklist de Django. DEBUG reste à False, SECRET_KEY vit dans les variables du bloc, hors du dépôt, et ALLOWED_HOSTS porte vos domaines : sans lui, Django ne fonctionne pas.
Quelle version de Django choisir ?
Au 2 novembre 2026, la 5.2 LTS, dont le dernier patch est le 5.2.18, est en support étendu jusqu’en avril 2028 : correctifs de sécurité et bugs de perte de données. La dernière version officielle est la 6.1.2. La version de Python et l’image de base restent votre choix, dans votre Dockerfile.
Et des tâches planifiées sans Celery ?
Une commande manage.py peut tourner comme tâche récurrente du bloc application, un cron avec ses journaux. Celery beat devient utile quand vous avez déjà des workers.
Pour aller plus loin : le CI/CD sur Kubernetes et l'autoscaling Kubernetes.
Votre appli Django sur Fransys, par où commencer
Voyez la console en démo, à votre nom. Pour chiffrer votre appli, le plan d’infra le fait ligne par ligne, machines comprises.
Sans carte bancaire, sans engagement.
À lire sur le blog
Combien coûte vraiment un DevOps en 2026 ? (et comment limiter cette dépense)
Salaire, charges, recrutement, turnover : le coût réel d'un DevOps en France dépasse 90 000 €/an. Analyse complète et alternatives pour startups sans DevOps.
Heroku et Vercel deviennent trop chers : où migrer en 2026 ?
Heroku sans free tier, Vercel qui explose les factures : comparatif des alternatives européennes pour startups. Migration vers Kubernetes managé sans DevOps.
AWS vs Fransys : combien coûte vraiment votre infrastructure cloud en 2026 ?
Comparatif détaillé AWS vs Fransys sur hébergeur européen. Les prix poste par poste, et trois scénarios de startup chiffrés.