Deploy Django to Your Own Server

How to deploy Django with Temps

Commands run on your machine unless they say otherwise. The CLI runs with bunx or npx.

1. 1

   Install Temps on a Linux server

   On a VPS with at least 2 CPU cores and 4 GB of RAM, download the installer, read it, then run it. It installs Docker if needed, the Temps binary and its database, and asks how the console is reached: an sslip.io address or your own domain.

   curl -fsSL https://temps.sh/deploy.sh -o deploy.sh
   less deploy.sh
   bash deploy.sh

2. 2

   Log in from your machine

   Point the CLI at your Temps console. It opens a browser to approve the login.

   bunx @temps-sdk/cli login https://console.example.com

3. 3

   Add the production dependencies

   Temps adds Gunicorn when it's missing, but not once a Procfile web: line takes over, so list it yourself.

   requirements.txt

   Django>=5.1
   gunicorn>=22.0
   whitenoise>=6.6
   psycopg[binary]>=3.1

4. 4

   Point the health check at a path that doesn't need the database

   Before switching traffic, Temps probes / until it answers. On the first deploy the tables don't exist yet, so if / queries the database the deploy fails before you can migrate. Set health.path to /health/ in .temps.yaml.

   .temps.yaml

   health:
     path: /health/

5. 5

   Deploy Django

   From the project root, run up. If the directory isn't linked to a project yet, it walks you through creating one first. For a project created from a Git repository, pushes to the tracked branch deploy automatically.

   bunx @temps-sdk/cli up

6. 6

   Create and link a PostgreSQL database

   Temps doesn't create a database for you. Create one, then link it to the project (or use Databases → Create database in the dashboard). Linking injects POSTGRES_URL plus POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD into the next deployment. It doesn't inject DATABASE_URL.

   bunx @temps-sdk/cli services create -t postgres -n my-django-app-db
   bunx @temps-sdk/cli services link --id <service-id> -p my-django-app

7. 7

   Run migrations after deploys that change the schema

   Temps doesn't run migrations and has no release phase. Find the running container, then run the migration in it over SSH, by hand or from CI right after the deploy step. Don't add it to the start command: restarts and replicas would run it more than once.

   bunx @temps-sdk/cli projects show -p my-django-app --json   # note the numeric "id"
   bunx @temps-sdk/cli containers list -p <project-id>     # note the container_name
   ssh your-server 'docker exec <container_name> python manage.py migrate'

Production settings for Django on Temps

# settings.py
import os

SECRET_KEY = os.environ["SECRET_KEY"]
DEBUG = os.environ.get("DEBUG", "False") == "True"

# Temps doesn't inject your domain, so list it in a project variable:
#   ALLOWED_HOSTS=app.example.com,www.example.com
ALLOWED_HOSTS = [h.strip() for h in os.environ.get("ALLOWED_HOSTS", "").split(",") if h.strip()]

# Use the linked managed PostgreSQL; Temps injects these variables.
if os.environ.get("POSTGRES_HOST"):
    DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.postgresql",
            "NAME": os.environ.get("POSTGRES_DB"),
            "USER": os.environ.get("POSTGRES_USER"),
            "PASSWORD": os.environ.get("POSTGRES_PASSWORD"),
            "HOST": os.environ["POSTGRES_HOST"],
            "PORT": os.environ.get("POSTGRES_PORT", "5432"),
        }
    }

# Static files, served by WhiteNoise from the app container
STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"
STORAGES = {
    "default": {"BACKEND": "django.core.files.storage.FileSystemStorage"},
    "staticfiles": {"BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage"},
}

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",
    # ...the rest of your middleware, unchanged
]

# urls.py
from django.http import JsonResponse
from django.urls import path

def health(request):
    # No database query, so the first deploy passes before you migrate.
    return JsonResponse({"status": "ok"})

urlpatterns = [
    path("health/", health),
    # ...your other routes
]

# settings.py — add sentry-sdk[django] to requirements.txt
import sentry_sdk

sentry_sdk.init(dsn=os.environ.get("SENTRY_DSN"))

Common Django deploy errors and fixes

The container exits with gunicorn: not found.

A Procfile web: line replaces the start command Temps generates, and Temps then stops adding Gunicorn for you. List gunicorn (and whitenoise) in requirements.txt or pyproject.toml.

CSS and JavaScript return 404 and the admin is unstyled.

Set STATIC_ROOT and add WhiteNoise as above. Nightly builds run collectstatic during the build; on beta.56 and earlier, run it from the Procfile: web: python manage.py collectstatic --noinput && gunicorn myproject.wsgi:application --bind 0.0.0.0:$PORT.

The first deploy fails its health check.

If / queries tables that don't exist yet, the check fails before you can run migrate. Point health.path in .temps.yaml at the /health/ view above, deploy, then run the migration.

Data disappears after every deploy.

Django is still on its SQLite default. App containers have no persistent volume, so link a PostgreSQL database and read the POSTGRES_* variables.

Error pages show settings and file paths.

DEBUG is on. Set DEBUG=False as a project variable; Django also starts checking ALLOWED_HOSTS once it's off.

How Temps builds and runs Django

Every app runs in a Docker container on your server, behind the Temps proxy. Before traffic switches to a new deployment, Temps health-checks it; if the check fails, the deployment is marked failed and the current version keeps serving.

What works with Django on Temps

• Gunicorn started for you, or your own Procfile web: line
• Static files served by WhiteNoise
• Managed PostgreSQL you create and link
• Health check before each cutover
• Error tracking through any Sentry SDK
• Preview environments per branch (opt-in)

Managed services for Django

Temps runs these services on your server. Create one, link it to the project, and its connection variables reach the next deployment. Set up managed services.

Environment variables for Django

Set your own with environments vars set or in the project settings; values are encrypted at rest.

What it costs to self-host Django

Temps is free to self-host under MIT / Apache 2.0, with no per-seat fee and nothing metered, so hosting Django costs what the server costs. A Hetzner CX23 (2 shared vCPU, 4 GB RAM, 40 GB NVMe, 20 TB traffic) meets the minimum Temps needs and is €5.49/month excluding VAT, plus €0.50/month for an IPv4 address; Hetzner sells it in Germany and Finland only. Prices checked October 10, 2026.

For one to three production apps, the server guide recommends 4 vCPU and 8 GB RAM: a Hetzner CX33 is €8.49/month excluding VAT. Any Linux VPS that meets the minimum works; sizes and other providers are in Choosing a server. For what the same app costs on Heroku, see Temps vs Heroku.

Django on Temps: frequently asked questions

Included with every Temps project

Deployments, analytics, error tracking, session replay and uptime monitoring run in the same self-hosted platform, so your Django app doesn't need separate subscriptions for them.

Related guides

• Every setting for this stack is in the Django deployment reference.
• Which stacks are detected and which need a preset is listed in supported languages and frameworks.
• How health checks, cutover and rollbacks work is covered in Deployments.
• Moving a Django app off Heroku? Follow Migrate from Heroku.
• For a side-by-side of the two platforms, see Temps vs Heroku.
• Python API instead of a full Django site? See Deploy FastAPI to your own server.
• Comparing Heroku alternatives? See 9 best Heroku alternatives.
• Running migrations safely on deploy is covered in how to run database migrations safely on deploy.
• Backing up the database? Read automating PostgreSQL backups in Docker.

Deploy another framework