Get Your First Django Preview in 5 Minutes — No Kubernetes, No CI Scripts

Django teams have been underserved by the preview-environment revolution. Vercel doesn't run Django. Netlify doesn't understand wsgi.py. Railway can do it, but usage billing turns a 10-PR sprint into a surprise bill. Most Django shops still merge to a shared staging server and hope two people aren't testing simultaneously.

PreviewDrop gives every Django branch its own live URL in under 60 seconds on warm redeploys — no CI scripts, no Kubernetes, no per-resource billing. Here's how to get your first Django preview running in five minutes.

Why Django previews are harder than they look

Django is not a static site. It needs a WSGI or ASGI server, a database connection, static file serving, and often a background worker. The "just deploy to a static host" path that works for Next.js or Gatsby doesn't apply.

Most Django teams handle previews in one of three ways, all of which have problems:

Shared staging server. Every branch merges into develop and deploys to staging. Two engineers testing at once step on each other's state. The designer clicks a button that changes because someone else's branch just deployed on top.

Ngrok from localhost. You run python manage.py runserver, then ngrok http 8000, and paste the URL in Slack. It works for demos. It stops working when your laptop goes to sleep, and it gives you zero integration with PR workflows, build logs, or team access control.

A hand-rolled CI pipeline. GitHub Actions builds a Docker image, pushes it to a registry, SSHs into a server, and starts a container with a branch-specific subdomain. It works until the registry auth token expires, the server IP changes, or someone needs to add a second framework to the same workflow.

PreviewDrop replaces all three with a single GitHub App installation and zero configuration files.

Step-by-step: your first Django preview

Step 1 — Install the GitHub App. From the PreviewDrop dashboard, authorize the app on your Django repo. It takes about 60 seconds and requires no code changes to your project. The app receives push and PR webhooks automatically.

Step 2 — Set your environment variables. In the PreviewDrop project dashboard, add the environment variables your Django app needs for preview mode:

DJANGO_SETTINGS_MODULE=myproject.settings
SECRET_KEY=your-preview-secret-key
DATABASE_URL=postgres://user:pass@host:5432/preview_db
DEBUG=False

Use a dedicated development database — PreviewDrop previews are ephemeral, so point DATABASE_URL at a shared dev Postgres instance or use a database-branching service that creates isolated databases per preview.

Step 3 — Push a branch (or open a PR). That's it. PreviewDrop detects Django from your requirements.txt or pyproject.toml, determines the right Python version, generates a build plan that includes pip install, runs python manage.py migrate as part of your startup command, and starts the container.

Within 60 seconds on a warm redeploy, you get a live URL. A PR comment lands automatically when you open a pull request — your designer, PM, or client clicks one link and sees the running app.

What PreviewDrop detects in your Django project

When PreviewDrop scans your repo, it looks for:

• requirements.txt or pyproject.toml — determines Python version and dependencies
• manage.py — confirms it's a Django project
• wsgi.py or asgi.py — identifies the application entry point
• Dockerfile — if you have one, PreviewDrop uses it directly instead of generating one

The build process installs Python, runs pip install -r requirements.txt, executes python manage.py migrate as part of the startup sequence, and starts the application server. If your project uses Gunicorn, uWSGI, or Daphne, PreviewDrop detects the entry point from your Procfile or startup scripts.

Database strategy for Django previews

The most common question from Django teams is: "what about the database?"

PreviewDrop doesn't provision databases for you — it runs your application container and connects to whatever DATABASE_URL you provide. Here are the patterns that work well:

Option 1 — Shared dev database. Point all previews at a single development Postgres instance. This is the simplest setup and works well for read-heavy testing (design reviews, PM walkthroughs). The trade-off: two branches that run conflicting migrations will step on each other.

Option 2 — Per-branch isolation with database branching. Use a service that creates lightweight Postgres branches in under a second. Set the branch name as an environment variable in your preview configuration, and each preview gets its own isolated database. Zero coordination between team members.

Option 3 — SQLite for previews. For simpler Django apps, configure a separate settings module that uses SQLite for preview environments. This avoids external database dependencies entirely and works well for frontend-heavy Django projects.

Performance on Django

Django deploys benefit from the same build-cache optimization that speeds up every other framework. Here's what a warm redeploy looks like:

dependency install (cached)  ..  10s
python manage.py collectstatic .  8s
python manage.py migrate  ......  4s
container start  ...............  3s
stability poll  ................  12s
─────────────────────────────────────
Total: ~37 seconds

Dependencies are cached across builds — only the application code layer changes between pushes. The first deploy on a branch (cold) takes 2–4 minutes depending on the size of your dependency tree. After that, every push rebuilds only your application code.

Migrations on every deploy

Running python manage.py migrate on every preview deploy is safe if your migrations are backward-compatible — which they should be anyway. The migration runs during container startup, before the application starts serving requests. If you prefer to skip migrations for previews (and use a pre-migrated database), you can configure the startup command in your PreviewDrop project settings.

For teams using per-branch database isolation, migrations on deploy give you an exact replica of what production would look like. Add a postdeploy script that seeds test data, and your previews become fully functional test environments.

Static files and media

Django's static file handling adds a wrinkle to containerized deploys. PreviewDrop runs python manage.py collectstatic during the build phase so your static files are served from the container itself. For media uploads (user-uploaded content), point MEDIA_URL at an S3-compatible bucket or use a local /media/ directory inside the container — just remember that container-local files are ephemeral and disappear when the preview expires.

Integrating with your existing CI

If you already have a linting, testing, or type-checking CI pipeline in GitHub Actions, PreviewDrop doesn't interfere with it. The preview deploy runs alongside your existing CI — they're separate events that don't block each other. Your tests can pass or fail independently of the preview URL being available, which is exactly what you want when a designer just wants to click around the UI.

Start your first Django preview

PreviewDrop works with any Django project — from a single-app prototype to a multi-service Django + Celery + Redis stack. The free tier gives you 2 concurrent previews with no credit card required.

Connect your Django repo now →