Deploy Django on Nodion

Deploy Django step by step

1. Add Gunicorn, WhiteNoise and a database driver Nodion starts Gunicorn but does not install it, so it belongs in your dependencies. Gunicorn does not serve static files; WhiteNoise serves what collectstatic writes. Pin the Python version in .python-version, because a range such as requires-python = ">=3.10" picks the newest release. requirements.txt

   Django>=5.2
   gunicorn
   whitenoise
   dj-database-url
   psycopg[binary]

2. Read settings from the environment collectstatic runs during the build, where only variables marked Build exist, so the settings must import without runtime secrets. Django checks SECRET_KEY only when it is used. Add WhiteNoise right after 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"

3. Answer the health check before the host check Nodion's health check calls each instance by its internal address, which is not in ALLOWED_HOSTS, so Django would answer 400 and the release never goes live. Put a small middleware first in MIDDLEWARE and set the health check path to /healthz in the app settings. 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)

4. Run migrations on every deploy A release: line in a Procfile runs once per build, after the build and before the new version starts. If it fails, the deploy stops and the running version stays live. Procfile

   release: python manage.py migrate --noinput

5. Create the app and the database Create an application from your repository in the region EU Central, then a PostgreSQL database in the same region, and attach it on the Environment tab: it arrives as DATABASE_URL on the next deploy. Set DJANGO_SECRET_KEY as a secret and DJANGO_ALLOWED_HOSTS to your app's hostname and your own domains, then push.

Good to know

• Celery and other workersAdd worker: celery -A myproject worker to the Procfile together with an explicit web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT; without a web: line the first Procfile entry other than release: becomes the default command. Then add a process named worker without a port on the Processes tab. Valkey in the same region gives you REDIS_URL as broker.
• ASGIThe default start command is WSGI. For Channels or async views, set your own web: line, for example with Uvicorn workers, and bind it to 0.0.0.0:$PORT.
• Dependency filesrequirements.txt, poetry.lock and Pipfile.lock are installed as they are. A Pipfile without its lock file installs nothing.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Heroku Alternatives with EU Hosting: 5 Options Compared A German platform and US clouds with EU regions, compared by headquarters, regions and managed databases.
• Preview Environments Explained: An App per Pull Request A running copy of your app for every pull request: what preview environments are good for, where they get tricky and how Nodion handles them.

Django on Nodion: questions and answers