Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/J0S3-LEON/pf_pruebasAseguramientoCalid_SDD/llms.txt

Use this file to discover all available pages before exploring further.

The compose.yml at the repository root orchestrates three services — a PostgreSQL 18 database, the NestJS backend, and the Next.js frontend — all running inside isolated containers on a shared private network. This is the recommended way to reproduce the full application stack locally without installing Node.js or PostgreSQL on your host machine. All inter-service communication happens over an internal Docker network; only the frontend is reachable from your browser.
compose.yml is designed for local development only. Do not use it as a production deployment target. For production, deploy each service independently as described in the Production guide.

​
Services overview

ServiceImage / BuildInternal portExternal access
dbpostgres:18-alpine5432Not exposed — internal network only
backendBuilt from apps/backend/Dockerfile3001Not exposed — internal network only
frontendBuilt from apps/frontend/Dockerfile3000http://localhost:3000

​
Network architecture

All three services are attached to a Docker network declared with internal: true. This means no container can initiate outbound internet connections through this network, and neither db nor backend accepts traffic from outside the Docker environment. The frontend is the sole entry point for external traffic — matching the production topology where a reverse proxy or platform edge terminates public requests and forwards them to the frontend only.

​
Volume and data persistence

PostgreSQL 18 stores its data directory at /var/lib/postgresql/18/docker inside the container — a path change introduced in PostgreSQL 18. For this reason the named volume mindflow_pgdata is mounted at /var/lib/postgresql (the parent directory), not at /var/lib/postgresql/data as was conventional through PostgreSQL 17. This ensures data persists across container restarts and remains compatible with future minor-version upgrades.

​
Starting the stack

1

Verify configuration

Before building anything, confirm that Docker Compose can parse compose.yml and that all variable substitutions resolve correctly:
docker compose config
Review the output for any missing variables. At a minimum, ensure DATABASE_URL, JWT_SECRET, FRONTEND_URL, and AUTH_SECRET are set in your root .env file. See the Environment Variables reference for details.
2

Build the images

Build the backend and frontend Docker images from source. Docker will use the multi-stage Dockerfile in each application directory with the repo root as the build context:
docker compose build
3

Start all services

Start all three containers in detached mode. Docker Compose will wait for the db health check to pass before starting the backend, and will start the frontend after the backend is running:
docker compose up -d
4

Run database migrations

Apply Prisma migrations against the containerised PostgreSQL instance. This step is required on first startup and after any schema change:
docker compose exec backend npm run prisma:migrate:deploy --workspace @mindflow/backend
5

Follow the logs

Watch the live log output from both the backend and frontend to confirm startup completed without errors:
docker compose logs -f backend frontend
Press Ctrl+C to stop tailing the logs without stopping the containers.
6

Open the application

Navigate to http://localhost:3000 in your browser. The frontend proxies API requests to http://backend:3001/api/v1 over the internal network.

​
compose.yml — services section

services:
  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      # PostgreSQL 18+ uses PGDATA=/var/lib/postgresql/18/docker.
      # The parent directory is mounted for persistence and future upgrades.
      - mindflow_pgdata:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 5
    expose:
      - "5432"
    networks:
      - internal

  backend:
    build:
      context: .
      dockerfile: apps/backend/Dockerfile
    environment:
      NODE_ENV: ${NODE_ENV:-development}
      DATABASE_URL: ${DATABASE_URL}
      JWT_SECRET: ${JWT_SECRET}
      AI_SERVICE_API_KEY: ${AI_SERVICE_API_KEY}
      FRONTEND_URL: ${FRONTEND_URL}
      PORT: ${PORT:-3001}
    expose:
      - "3001"
    depends_on:
      db:
        condition: service_healthy
    networks:
      - internal

  frontend:
    build:
      context: .
      dockerfile: apps/frontend/Dockerfile
      args:
        NEXT_PUBLIC_API_URL: ${NEXT_PUBLIC_API_URL:-http://backend:3001/api/v1}
        NEXT_PUBLIC_APP_URL: ${NEXT_PUBLIC_APP_URL:-http://localhost:3000}
    environment:
      NODE_ENV: ${NODE_ENV:-development}
      AUTH_SECRET: ${AUTH_SECRET}
      AUTH_DEBUG: ${AUTH_DEBUG:-false}
      NEXT_PUBLIC_API_URL: ${NEXT_PUBLIC_API_URL:-http://backend:3001/api/v1}
      NEXT_PUBLIC_APP_URL: ${NEXT_PUBLIC_APP_URL:-http://localhost:3000}
    expose:
      - "3000"
    depends_on:
      - backend
    networks:
      - internal

volumes:
  mindflow_pgdata:
    name: mindflow_pgdata

networks:
  internal:
    internal: true

​
Useful commands

CommandDescription
docker compose downStop and remove all containers (data volume is preserved)
docker compose down -vStop and remove containers and the data volume
docker compose exec backend <cmd>Run a command inside the running backend container
docker compose psShow the status of all services
docker compose build --no-cacheForce a full rebuild without the layer cache
Running docker compose down -v will permanently delete the mindflow_pgdata volume and all database data inside it. There is no undo. If you need to reset the database, prefer dropping and recreating the schema via Prisma migrations rather than destroying the volume.

Build docs developers (and LLMs) love

Get started for freeTalk to us