TempsTemps
2 minutes to production

Deploy Django on Temps

Deploy Django applications with a managed PostgreSQL database, Gunicorn WSGI server, and WhiteNoise for static files. Migrations run automatically.

Follow the TutorialQuick Start Guide
Automatic HTTPSDeploy on git pushFree tier available

What you get with Django on Temps

Everything your Django app needs in production, configured automatically.

Managed PostgreSQL provisioned automatically
Gunicorn as production WSGI server
Static files served via WhiteNoise
Database migrations on deploy
Environment variable injection
Health check monitoring

Prerequisites

Before deploying Django to Temps, make sure your project meets these requirements. Most Django projects already do.

Python 3.10 or newer (3.12 recommended for 2026 deployments)
A requirements.txt, pyproject.toml, or Pipfile at the repository root
A Django project with manage.py at the root or a well-known subdirectory
gunicorn added as a production dependency
whitenoise added for zero-configuration static file serving
dj-database-url to parse the DATABASE_URL connection string Temps injects

Add the production dependencies to your requirements.txt:

# requirements.txt
Django>=4.2
gunicorn>=21.0
whitenoise>=6.6
dj-database-url>=2.0
psycopg[binary]>=3.1

Quick start

A minimal Django project ready for Temps looks like this. The Procfile tells the platform how to start your app; the settings module reads configuration from environment variables at runtime.

Project structure

Temps expects manage.py and Procfile at the repository root.

my-django-app/
├── manage.py
├── Procfile
├── requirements.txt
├── myproject/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── myapp/
    ├── models.py
    ├── views.py
    └── ...

Procfile

The Procfile defines the process types Temps will run. The web process handles HTTP traffic. The release process runs once per deployment, before traffic is routed to the new instance — ideal for migrations. The build process runs during the build phase to collect static assets.

web: gunicorn myproject.wsgi --workers 2 --bind 0.0.0.0:$PORT --timeout 120
release: python manage.py migrate --noinput
build: python manage.py collectstatic --noinput

Production settings

Add these blocks to settings.py. They read configuration from environment variables so the same code works in every environment without modification.

import os
import dj_database_url

# Security
SECRET_KEY = os.environ["SECRET_KEY"]
DEBUG = os.environ.get("DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "127.0.0.1").split(",")

# Database — Temps injects DATABASE_URL when PostgreSQL is attached
DATABASES = {
    "default": dj_database_url.config(
        default="sqlite:///db.sqlite3",
        conn_max_age=600,
        ssl_require=not DEBUG,
    )
}

# Static files — WhiteNoise serves them without a separate web server
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",
    # ... rest of your middleware
]

STATIC_ROOT = BASE_DIR / "staticfiles"
STATIC_URL = "/static/"
STATICFILES_STORAGE = "whitenoise.storage.CompressedManifestStaticFilesStorage"

Required environment variables

Set these in the Temps dashboard under your project's Environment tab, or pass them via --env flags in the CLI.

VariableDescription
SECRET_KEYDjango secret key — generate a new one for production
DEBUGMust be False in production
ALLOWED_HOSTSComma-separated list of allowed hostnames
DATABASE_URLAuto-injected by Temps when PostgreSQL is attached
PYTHON_VERSIONSpecify the Python runtime version

Deploy from the CLI

The Temps CLI deploys your Django app directly from your terminal. No dashboard required — everything is scriptable and CI-friendly. The first deploy provisions your PostgreSQL database, runs migrations, collects static files, and brings your app online with HTTPS in under two minutes.

Terminal

# 1. Authenticate with your Temps account

$ bunx @temps-sdk/cli login

# 2. Create a new project (one-time setup)

$ bunx @temps-sdk/cli projects create -n "my-django-app"

# 3. Attach a managed PostgreSQL database

$ bunx @temps-sdk/cli services add postgresql my-django-app

# 4. Deploy to production (re-run on every update)

$ bunx @temps-sdk/cli deploy my-django-app -e production -y

Temps runs your build and release Procfile commands automatically on each deploy — no extra CI configuration needed. Read the full Django deployment guide for advanced options including zero-downtime deploys, rollbacks, and custom domains.

Common errors and how to fix them

These four issues account for the majority of failed Django deployments. Understanding them before you deploy saves significant debugging time.

1

ALLOWED_HOSTS causes DisallowedHost errors

Django raises DisallowedHost at / with message: Invalid HTTP_HOST header. You may need to add your domain to ALLOWED_HOSTS.

Read ALLOWED_HOSTS from an environment variable so it works in every environment without code changes: # settings.py ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "127.0.0.1").split(",") Then set the env var in Temps: ALLOWED_HOSTS=your-app.temps.sh,yourdomain.com With DEBUG=False, Django validates the Host header on every request. Getting this wrong is the single most common reason a Django app works locally but fails immediately on first deploy.
2

DATABASE_URL not parsed — app silently uses SQLite

Migrations appear to succeed but data is lost on every deploy. The app connects to a local SQLite file that disappears when the container restarts.

Install dj-database-url and parse DATABASE_URL in settings.py: # settings.py import dj_database_url DATABASES = { "default": dj_database_url.config( default="sqlite:///db.sqlite3", conn_max_age=600, ssl_require=True, ) } Temps injects DATABASE_URL automatically when you attach a PostgreSQL service to your project. Without parsing it, Django falls back to the default SQLite configuration.
3

DEBUG=True leaks secrets and bypasses security middleware

Django's debug toolbar is visible in production. Error pages expose local file paths, environment variables, and installed apps to anyone who triggers a 500.

Always read DEBUG from an environment variable: # settings.py DEBUG = os.environ.get("DEBUG", "False") == "True" Set DEBUG=False in your Temps environment variables. Never commit DEBUG=True to a Procfile or any file that is deployed. With DEBUG=True, Django also skips ALLOWED_HOSTS validation, which masks the previous gotcha until you turn it off.
4

Static files return 404 — collectstatic not configured

CSS and JavaScript load fine in development but return 404 in production. The Django admin is completely unstyled.

Install whitenoise and wire it up in settings.py: # settings.py MIDDLEWARE = [ "django.middleware.security.SecurityMiddleware", "whitenoise.middleware.WhiteNoiseMiddleware", # must be second ... ] STATIC_ROOT = BASE_DIR / "staticfiles" STATIC_URL = "/static/" STATICFILES_STORAGE = "whitenoise.storage.CompressedManifestStaticFilesStorage" Add collectstatic to your Procfile build phase: build: python manage.py collectstatic --noinput Temps calls the build command before starting Gunicorn. Without STATIC_ROOT set, collectstatic has nowhere to write files and static serving silently breaks.

Managed services for Django

Provision a production database with one command. The connection string is injected as DATABASE_URL automatically — no copy-pasting credentials.

PostgreSQL

Production database with automatic backups

Deploy in 2 minutes

1

Connect your repo

Link your GitHub, GitLab, or Bitbucket repository. Temps detects your Procfile and Python version automatically.

2

Add PostgreSQL

Provision a managed PostgreSQL database with one click. DATABASE_URL is injected into your Django environment automatically.

3

Push to deploy

Push to your branch and Temps builds your app, runs migrations, collects static files, and serves with automatic HTTPS.

Everything included

No separate subscriptions for analytics, monitoring, or error tracking.

Automatic HTTPS

Free SSL certificates for every domain. Provisioned and renewed automatically.

Preview Deployments

Every pull request gets its own URL. Review changes before they go live.

Built-in Analytics

Privacy-first analytics included. No third-party scripts or cookie banners.

Error Tracking

Sentry-compatible error tracking with stack traces, context, and alerts.

Session Replay

Watch how users interact with your app. Debug issues visually.

Uptime Monitoring

24/7 health checks with Slack, Discord, and email alerts.

Ready to deploy Django?

Follow the step-by-step tutorial or deploy from the CLI in 2 minutes. Free tier available — no credit card required.

Deploy DjangoCompare Platforms