Framework Francfort, Allemagne

Déployez Django sur Nodion

Q: Nodion exécute-t-il mes migrations Django ?

Seulement si vous le demandez : ajoutez release: python manage.py migrate --noinput à un Procfile. Cette ligne s'exécute une fois par build, avant le démarrage de la nouvelle version, et un échec arrête le déploiement.

Q: Pourquoi mon déploiement Django n'est-il jamais prêt ?

En général, le health check reçoit un 400 à cause de ALLOWED_HOSTS ou un 404 sur /. Répondez sur un chemin comme /healthz dans un middleware placé avant la vérification de l'hôte, et indiquez-le comme chemin du health check de l'app.

Q: Puis-je utiliser Poetry au lieu de requirements.txt ?

Oui. Avec un poetry.lock, Nodion installe Poetry et exécute poetry install --only main. Pipenv fonctionne avec un Pipfile.lock.

Nodion reconnaît Django à la présence de manage.py et de Django dans vos dépendances. Le buildpack Python les installe, exécute collectstatic et démarre Gunicorn sur le module WSGI de votre projet. Avec une ligne release: dans un Procfile, les migrations s'exécutent avant la mise en production de chaque nouvelle version, et l'app comme sa base de données PostgreSQL tournent à Francfort.

Documentation Nodion Site web Django

Déployer sur Nodion ›

à partir de 1 EUR / mois

Jusqu'à 15 € de crédit de bienvenue à l'inscription

Détecté par: manage.py et Django dans vos dépendances
Démarrage: gunicorn <projet>.wsgi, 3 workers
Python: de 3.10 à 3.15, 3.13 par défaut
Région: EU Central (Francfort)

Déployez Django étape par étape

Ajoutez Gunicorn, WhiteNoise et un pilote de base de données Nodion démarre Gunicorn mais ne l'installe pas : il doit donc figurer dans vos dépendances. Gunicorn ne sert pas les fichiers statiques ; WhiteNoise sert ce qu'écrit collectstatic. Fixez la version de Python dans .python-version, car une plage comme requires-python = ">=3.10" sélectionne la version la plus récente. requirements.txt
```
Django>=5.2
gunicorn
whitenoise
dj-database-url
psycopg[binary]
```

Lisez la configuration depuis l'environnement collectstatic s'exécute pendant le build, où seules les variables marquées Build existent : la configuration doit donc pouvoir être importée sans les secrets nécessaires à l'exécution. Django ne vérifie SECRET_KEY qu'au moment où elle est utilisée. Ajoutez WhiteNoise juste après SecurityMiddleware. settings.py

import os
import dj_database_url

SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "")
DEBUG = os.environ.get("DJANGO_DEBUG") == "1"
ALLOWED_HOSTS = os.environ.get("DJANGO_ALLOWED_HOSTS", "").split(",")
CSRF_TRUSTED_ORIGINS = [f"https://{h}" for h in ALLOWED_HOSTS if h]

DATABASES = {"default": dj_database_url.config(conn_max_age=600)}

STATIC_ROOT = BASE_DIR / "staticfiles"
# MIDDLEWARE: "whitenoise.middleware.WhiteNoiseMiddleware"
# right after "django.middleware.security.SecurityMiddleware"

Répondez au health check avant la vérification de l'hôte Le health check de Nodion appelle chaque instance par son adresse interne, qui ne figure pas dans ALLOWED_HOSTS : Django répondrait 400 et la release ne serait jamais mise en ligne. Placez un petit middleware en tête de MIDDLEWARE et indiquez /healthz comme chemin du health check dans les paramètres de l'app. health.py
```
from django.http import HttpResponse


class HealthCheckMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        if request.path == "/healthz":
            return HttpResponse("ok")
        return self.get_response(request)
```
Exécutez les migrations à chaque déploiement Une ligne release: dans un Procfile s'exécute une fois par build, après le build et avant le démarrage de la nouvelle version. Si elle échoue, le déploiement s'arrête et la version en cours reste en ligne. Procfile
```
release: python manage.py migrate --noinput
```
Créez l'app et la base de données Créez une application depuis votre dépôt dans la région EU Central, puis une base de données PostgreSQL dans la même région, et rattachez-la dans l'onglet Environment : elle arrive sous la forme DATABASE_URL au déploiement suivant. Définissez DJANGO_SECRET_KEY comme secret et DJANGO_ALLOWED_HOSTS avec le nom d'hôte de votre app et vos propres domaines, puis faites un push.

Bon à savoir

Celery et autres workersAjoutez worker: celery -A myproject worker au Procfile avec une ligne explicite web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT ; sans ligne web:, la première entrée du Procfile autre que release: devient la commande par défaut. Ajoutez ensuite, dans l'onglet Processes, un processus nommé worker sans port. Valkey dans la même région vous fournit REDIS_URL comme broker.
ASGILa commande de démarrage par défaut utilise WSGI. Pour Channels ou des vues asynchrones, définissez votre propre ligne web:, par exemple avec des workers Uvicorn, et faites écouter le serveur sur 0.0.0.0:$PORT.
Fichiers de dépendancesrequirements.txt, poetry.lock et Pipfile.lock sont installés tels quels. Un Pipfile sans son lockfile n'installe rien.

Ce que Nodion gère pour vous

Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

Django sur Nodion : questions et réponses

Nodion exécute-t-il mes migrations Django ?

Seulement si vous le demandez : ajoutez release: python manage.py migrate --noinput à un Procfile. Cette ligne s'exécute une fois par build, avant le démarrage de la nouvelle version, et un échec arrête le déploiement.

Pourquoi mon déploiement Django n'est-il jamais prêt ?

En général, le health check reçoit un 400 à cause de ALLOWED_HOSTS ou un 404 sur /. Répondez sur un chemin comme /healthz dans un middleware placé avant la vérification de l'hôte, et indiquez-le comme chemin du health check de l'app.

Puis-je utiliser Poetry au lieu de requirements.txt ?

Oui. Avec un poetry.lock, Nodion installe Poetry et exécute poetry install --only main. Pipenv fonctionne avec un Pipfile.lock.

Où tourne mon app Django ?

Dans la région EU Central, à Francfort (Allemagne). Le build, le registry, l'app et ses bases de données, volumes, buckets, logs et métriques restent dans cette région. L'API et le plan de contrôle de Nodion sont hébergés en Allemagne. Nodion GmbH a son siège à Stuttgart.

Puis-je utiliser Django en conformité avec le RGPD ?

Nodion en pose les bases : Nodion GmbH a son siège à Stuttgart (Allemagne). Dans la région de Francfort, l'app, ses bases de données et ses volumes fonctionnent en Allemagne. Vous concluez le DPA (accord de traitement des données, art. 28 RGPD) par voie électronique dans le dashboard. La conformité de votre déploiement dépend aussi de la façon dont vous configurez et utilisez l'app.

Combien coûte l'hébergement Django sur Nodion ?

Une instance d'app coûte à partir de 1 EUR par mois. La configuration présentée dans l'encadré des coûts revient à 3.50 EUR par mois : App 2 EUR, PostgreSQL 1.50 EUR. Les prix sont HT, avec une facturation à la seconde. Vous pouvez choisir des tailles plus grandes ou davantage d'instances dès que vous en avez besoin.

Puis-je utiliser mon propre domaine pour mon app Django ?

Oui. Chaque app reçoit un nom d'hôte par défaut avec HTTPS. Ajoutez votre propre domaine dans l'onglet Domains de l'app. Le certificat TLS est émis et renouvelé automatiquement.

Offrez un cloud à votre agent.

Jusqu'à 15 € de crédit de bienvenue à l'inscription.

Continuer avec GitHub

ou par e-mail