docker-compose.yml

# Local development stack: a real PostgreSQL database, the backend API, and
# the frontend behind nginx, all containerized. This mirrors (in miniature)
# the RDS + ECS Fargate + CloudFront/S3 relationship from the target AWS
# production architecture, without needing an AWS account to develop
# against.
#
# Usage: docker compose up --build
# That's it -- the backend applies its own schema and seed data on startup
# (see Backend/src/schema.js), so tables and sample jobs exist whether or
# not this is a fresh volume. Locally, Postgres also auto-runs
# Backend/sql/schema.sql and Backend/sql/seed_jobs.sql on a fresh volume via
# the `db` volumes below; that's a harmless no-op alongside the backend's
# own application, kept only because it lets a bare `docker compose up db`
# be useful on its own. The backend also seeds the admin account on
# startup, and nginx (in the `frontend` service) serves the built React app
# and reverse-proxies /api/* to the backend container, so the frontend can
# call relative paths with zero extra configuration (see Frontend/nginx.conf).
#
# In production the frontend is NOT run as a container: it's built with
# VITE_API_URL set to the ALB/domain's HTTPS address and the static output
# is uploaded to S3, served through CloudFront (see the README).
services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: job_portal
    ports:
      - '5432:5432'
    volumes:
      - db-data:/var/lib/postgresql/data
      # Postgres's official image runs any .sql/.sh files found here, in
      # filename order, but ONLY the very first time a container starts
      # against an empty data directory. That's what gives a fresh
      # `docker compose up` a ready-to-use schema + sample jobs for free.
      - ./Backend/sql/schema.sql:/docker-entrypoint-initdb.d/01-schema.sql:ro
      - ./Backend/sql/seed_jobs.sql:/docker-entrypoint-initdb.d/02-seed-jobs.sql:ro
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U postgres']
      interval: 5s
      timeout: 5s
      retries: 5

  backend:
    build: ./Backend
    restart: unless-stopped
    ports:
      - '3000:3000'
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_NAME: job_portal
      AWS_REGION: ${AWS_REGION:-us-east-1}
      S3_BUCKET_NAME: ${S3_BUCKET_NAME}
      SES_SENDER_EMAIL: ${SES_SENDER_EMAIL}
      JWT_SECRET: ${JWT_SECRET:-change-me-to-a-long-random-string}
      ADMIN_EMAIL: ${ADMIN_EMAIL}
      ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      PORT: 3000
    depends_on:
      db:
        condition: service_healthy
    # No command override -- the Dockerfile's CMD (`node src/index.js`) is
    # enough. index.js applies the schema and seeds the admin account
    # itself before it starts listening (see Backend/src/schema.js and
    # Backend/src/seedAdmin.js), so there's no external command chain to
    # maintain here, and the same image behaves identically under ECS,
    # which runs that CMD directly with no opportunity for a chain like
    # this anyway.

  frontend:
    build:
      context: ./Frontend
      # No VITE_API_URL build arg here on purpose -- leaving it unset makes
      # the app call relative '/api' paths, which nginx.conf forwards to
      # the `backend` service below. See Frontend/src/api/config.js.
    restart: unless-stopped
    ports:
      - '80:80'
    depends_on:
      - backend

volumes:
  db-data: