Don't want to set this up manually? Paste a link to this page into a Devin session and ask it to set everything up for you. If you're not sure which services your Django app depends on or how the project is structured, use [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) to investigate first: ```txt Scope the Django project for containerization theme={null} What does our Django app in src/ depend on? 1. Which databases and caches does it connect to? 2. Does it use Celery or any background workers? 3. What's in requirements.txt or pyproject.toml? 4. Are there any existing Docker files or deployment configs? 5. How does the app handle static files and media? ``` You can also start a Devin session directly from Ask Devin, and it will carry over everything it learned as context. Point Devin at the Django project to containerize and mention anything specific — base image preferences, services the app depends on, or image size constraints. Devin reads your `requirements.txt` or `pyproject.toml` to figure out the rest. ```txt Dockerize Django API with Postgres and Redis theme={null} Dockerize the Django API in src/. It uses PostgreSQL for the database and Redis for caching and Celery task queues. - Multi-stage Dockerfile: install dependencies in a builder stage, copy only the venv into a slim python:3.12-slim runtime image - docker-compose.yml with Django (gunicorn), PostgreSQL 16, and Redis 7 - .dockerignore that excludes tests, docs, .git, and __pycache__ - Run as non-root user - Health check on /api/health/ - Celery worker as a separate service in compose ## Testing & verification - Build the image and run docker-compose up - Wait for all services to be healthy - Verify the API responds on localhost:8000/api/health/ - Run the Django test suite inside the container - If anything fails — build errors, missing env vars, connection issues, failing tests — debug and fix it. Keep iterating until the entire stack starts cleanly and all tests pass. - Do not open a PR until everything works end-to-end ``` Devin reads your Django project and dependency files to understand the build process, then creates the Docker configuration: 1. **Reads dependency files** — Parses `requirements.txt` or `pyproject.toml`, identifies Django, psycopg2, redis, celery, and gunicorn 2. **Writes the Dockerfile** — Creates a multi-stage build that installs dependencies in a builder stage and copies the virtual environment into a minimal `python:3.12-slim` runtime image ```dockerfile theme={null} # ---- Builder ---- FROM python:3.12-slim AS builder WORKDIR /app COPY requirements.txt . RUN python -m venv /opt/venv \ && /opt/venv/bin/pip install --no-cache-dir -r requirements.txt # ---- Runtime ---- FROM python:3.12-slim RUN groupadd -r django && useradd -r -g django django COPY --from=builder /opt/venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" WORKDIR /app COPY src/ . RUN python manage.py collectstatic --noinput EXPOSE 8000 USER django CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "3"] ``` 3. **Writes docker-compose.yml** — Adds Django, PostgreSQL, Redis, and a Celery worker with health checks, volumes, and a shared network ```yaml theme={null} services: web: build: . ports: - "8000:8000" env_file: .env depends_on: db: condition: service_healthy redis: condition: service_healthy healthcheck: test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/api/health/')"] interval: 10s retries: 3 db: image: postgres:16-alpine environment: POSTGRES_DB: app_db POSTGRES_USER: app_user POSTGRES_PASSWORD: app_pass volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U app_user -d app_db"] interval: 5s retries: 5 redis: image: redis:7-alpine healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s retries: 5 celery: build: . command: celery -A config worker -l info env_file: .env depends_on: db: condition: service_healthy redis: condition: service_healthy volumes: pgdata: ``` 4. **Adds .dockerignore** — Excludes files that don't belong in the build context (`__pycache__`, `.git`, `tests/`, `docs/`, `*.pyc`) 5. **Runs `docker compose up --build`** — Builds the image and starts all services in Devin's terminal 6. **Verifies the app** — Curls `/api/health/` to confirm Django starts cleanly, connects to PostgreSQL, and reaches Redis Use slash commands during the session to steer Devin's workflow: * **`/plan`** — Ask Devin to outline its approach before writing any Docker configuration. Review the plan and suggest changes. * **`/test`** — Tell Devin to rebuild and re-verify the container stack. Use this after each change to catch issues early. * **`/review`** — Ask Devin to review its own Dockerfile and compose config for security issues, image size, and best practices before opening the PR. Once Devin opens the PR, review the generated files. Common follow-ups: ```txt Optimize image size theme={null} The Docker image is 520MB. Shrink it — make sure we're not copying unnecessary files, strip .pyc files from the venv, and remove pip from the final image. ``` ```txt Add dev hot-reload theme={null} Add a docker-compose.override.yml for local development that mounts the source directory and runs Django's dev server with auto-reload instead of gunicorn. ``` ```txt Add CI docker build theme={null} Create a GitHub Actions workflow that builds the Docker image on every PR, runs pytest inside the container, and pushes to ECR on merge to main. Tag with the git SHA. ``` Once Devin opens the PR, use [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) to review the Docker configuration. Devin Review can catch security issues (running as root, exposed secrets), missing best practices (no `.dockerignore`, no health checks), and inconsistencies with your existing infrastructure.

{title}