Get your first Django preview environment in under 5 minutes

You've just pushed a branch that changes the checkout flow. The diff looks right, the unit tests pass, and your teammate says "looks good to me." But nobody has actually run the new code — because the only way to see it is to pull the branch, run migrations, and hope your local Postgres matches staging.

That's how a "small" Django change ships with a ValueError that only appears when the Order model has a status field your local DB doesn't have yet.

A preview environment fixes this: every pull request gets its own isolated, live URL running the branch's code. Here's how to get one for a Django app in under five minutes.

What a preview environment actually is

A preview environment is a throwaway deployment of a single branch. When you open a PR, PreviewDrop builds your Django container, runs it in isolation, and posts a URL back to the PR. When the PR closes, the environment is torn down.

The key word is isolated. Each preview gets its own container with its own memory budget and its own lifetime. It does not share a database with staging, and it does not share a port with anything else. Two PRs open at once get two separate URLs.

The one thing that trips up every Django team

Django's ALLOWED_HOSTS is the first thing that breaks in a preview environment. Your preview URL is prv-<id>.previews.previewdrop.dev — a hostname your settings.py has never seen. Django responds with 400 Bad Request until you allow it.

The fix is to read the host from an environment variable instead of hardcoding a list:

# settings.py
import os

ALLOWED_HOSTS = os.getenv("DJANGO_ALLOWED_HOSTS", "localhost,127.0.0.1").split(",")

Then set DJANGO_ALLOWED_HOSTS in the Variables tab of your PreviewDrop project. It's injected into every preview container at start, so you never touch settings.py again when a new preview spins up.

The rest of the setup

Django apps need three things to run in a preview container:

1. A Dockerfile. PreviewDrop builds your container from the branch's code. If you don't have a Dockerfile yet, a minimal one looks like this:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"]

2. A database. For a preview, you don't want to point at your production Postgres. Point Django at a disposable database — SQLite works for most previews, or use a separate Postgres instance if your app needs Postgres-specific features.

3. Static files. If your preview shows unstyled pages, it's usually DEBUG=False with no static file serving. Add a whitenoise middleware or serve static files in the container.

What you get on each plan

Preview environments are available on every plan, with limits that scale with the tier:

• Free — 2 concurrent previews, up to 3 projects, 4-hour preview lifetime, 256MB container memory. Solo only.
• Starter ($19/mo) — 5 concurrent previews, up to 10 projects, 24-hour lifetime, 512MB memory, up to 3 team members.
• Pro ($79/mo) — 20 concurrent previews, unlimited projects, 3-day lifetime, 1GB memory, up to 10 team members, plus password-protected previews.
• Team ($149/mo) — 40 concurrent previews, 7-day lifetime, 2GB memory, up to 25 team members.

The free tier is enough to try it on one project. If you're a solo developer, the free tier's 4-hour lifetime is usually long enough to review a PR in a single sitting.

Why this beats "works on my machine"

The whole point of a preview environment is that the reviewer sees the same thing the user will see. No "it works locally" — the preview is running the actual branch, with the actual dependencies, in a clean container. If it breaks, it breaks in the preview, not in production.

For Django specifically, this catches the class of bugs that unit tests miss: template errors, missing migrations, ALLOWED_HOSTS misconfiguration, and static-file issues. Those are exactly the bugs that show up in staging and cost a deploy cycle.

Get started

Connect your GitHub repo, push a branch, and PreviewDrop builds your Django container and posts the preview URL to the pull request in under 60 seconds. No CI scripts to write, no serverless adapters to configure.

Start free — no credit card required