Preview environments for Django + React
The heaviest stack to stand up per pull request — Python deps and system libraries, migrations and fixtures, a Celery worker and beat, plus a separate React build — provisioned together on a managed VPS behind one HTTPS URL. Reproduced identically every time, torn down clean.
- ✓ pip / Poetry / uv
- ✓ Celery + beat on Redis
- ✓ Isolated Postgres
A Django + React PR is the most setup of any stack
Reviewing a branch means installing Python deps with the right system libraries, migrating a database, loading fixtures, starting Celery and Redis, and building a separate React bundle — then wiring the two halves together. Doing all of that by hand for every pull request is the kind of toil nobody on the team volunteers for.
Native deps won't compile
psycopg, Pillow or cryptography need system libraries a reviewer doesn't have. The install fails, and now the review is a half-hour of apt-get instead of reading the diff.
Celery never gets started
The web app runs but the worker doesn't, so emails, exports and async tasks silently hang. The bug reported against the PR can't be reproduced because half the stack isn't running.
Two builds, one origin
Django serves the API, Vite builds React separately, and getting them to talk — CORS, base URLs, static paths — is fiddly enough that it's skipped, so reviewers test against stale assets.
What every Django + React preview includes
Each branch boots the entire Python + JS stack on its own VPS — interpreter, backing services, background workers and the compiled front end, served together on one origin.
pip, poetry or uv into the image — system libs and C extensions included.manage.py migrate then loaddata (or your seed command) on first boot.runserver.npm ci then npm run build; the bundle served same-origin or pointed at the API base.collectstatic with WhiteNoise, and a per-environment Postgres database.Exactly the steps you'd run by hand
You declare the install, migrate, seed and build commands once. We run them in a clean container on every push — no bespoke CI YAML, no SSH, no missing system packages.
# on every push to the branch pip install -r requirements.txt # or: poetry install / uv sync python manage.py migrate python manage.py loaddata seed.json # fixtures → realistic data python manage.py collectstatic --noinput npm ci && npm run build # Vite → React bundle gunicorn config.wsgi # + celery -A config worker -B ✓ ready https://acme-reporting-api.admn.cloud
From branch to shareable URL in three steps
- 01
Connect the repo
Point ADMN at your Django + React repository and declare your dependency resolver, build commands and database template — once.
- 02
Pick a branch
Choose any branch or PR. We provision a dedicated VPS, install Python deps, migrate and seed Postgres, build React and start Celery on Redis.
- 03
Share the URL
A real HTTPS environment for QA, design review or a stakeholder demo. Renew the lease to keep it, or let it expire and tear down clean.
Django + React preview environments, answered
How are Python dependencies installed?
However you already pin them. If you use pip we run `pip install -r requirements.txt`; if you use Poetry we run `poetry install`; if you use uv we run `uv sync`. The install happens inside the environment’s Docker image, so the C extensions that need system libraries — psycopg, Pillow, lxml, cryptography — compile against the same OS every time instead of against whatever a reviewer happens to have on their laptop.
Are migrations and seed data applied on boot?
Yes. Each environment runs `python manage.py migrate` against its own fresh Postgres, then loads your data — either Django fixtures via `python manage.py loaddata seed.json` or a custom management command if that’s how you seed. The preview opens on realistic data, and because the database is per-environment there’s nothing shared to corrupt between branches.
Do Celery workers and Django Channels run?
They do. We provision Redis as the broker and run your Celery worker and Celery beat scheduler as long-lived processes alongside the web app, so background tasks and periodic jobs behave like production. If your project is async and uses Django Channels, serve it under an ASGI server (uvicorn or Daphne) and the WebSocket consumers run against the same Redis.
How does the React frontend talk to the Django API — CORS or same origin?
Either works. The simplest setup builds the React app with Vite and serves the compiled bundle from the same origin as Django, so there’s no CORS at all and cookies/session auth flow naturally. If you prefer a decoupled deploy, we inject the API base URL into the frontend build and set `django-cors-headers` to allow the environment’s own HTTPS origin — wired automatically per branch.
What happens with static files — collectstatic and WhiteNoise?
We run `python manage.py collectstatic --noinput` during the build so Django’s admin and any server-rendered static assets are gathered, and WhiteNoise serves them straight from the app process with no separate CDN to configure. Your React build output is served as static assets too, so the whole front end ships inside the one environment.
Does each environment get its own isolated Postgres?
Yes — every branch or PR gets a dedicated managed VPS with its own Postgres instance (MySQL or Mongo are available too). Migrations and seeds run into that database only, and when the lease expires the database is destroyed with the environment. No shared staging database, no cleanup, nothing left behind.
Ship your next Django + React PR with a live URL
Connect GitHub and get a full Python + React preview environment for every branch — deps installed, migrated, seeded and built, with Celery running, then destroyed without a trace.