Guides

Django and PostgreSQL on AWS

Production architecture for a Django app with PostgreSQL, Celery and Redis on AWS. Web and worker processes, migrations, static files, backups and how Brunel designs and prices it from your code.

What Brunel detects in a Django project

django in pyproject.toml, requirements*.txt or Pipfile, and manage.py.
The database engine from settings.py, drivers (psycopg, mysqlclient) and migrations.
celery and its broker (Redis or RabbitMQ) → a worker service and a queue; celery beat → a scheduled job.
A Procfile release: command → migrations run at release.
Static files and media → object storage and a CDN.

The shape of the design

Component	Starter	Growth and above
Web (Gunicorn/Uvicorn)	One container	Several containers, autoscaling, behind a load balancer
Celery worker	Same host or one small container	Separate service, scaled on its own
Celery beat	Scheduled job	Scheduled job
PostgreSQL	Small managed instance, daily backups	High availability, point-in-time recovery, replicas at Scale
Redis	Small managed cache	Managed cache with replicas
Static and media	Object storage + CDN	Object storage + CDN

Migrations and releases

Run manage.py migrate as a release step before new web containers take traffic. The generated deployment workflow runs your tests, builds one image and rolls out; Brunel's migration plans list the ordered steps when you move from another platform (Heroku, Render, Railway…).

Backups

Every stateful component gets backups: the validator refuses a design where the database has less than 7 days of retention.

Get your own design

Paste the repository at https://brunel.cloud/new. If Brunel missed something (a second worker queue, for example), correct the fact and design again.