eduardweb.
Docker & ContainersÎncepător#docker#nextjs#devops#redis#postgres

Docker Compose curat pentru Next.js, Postgres și Redis (fără bătăi de cap pe local)

De Radu Grigore, 5 iun. 2026 · 2 vizualizări · 2 like-uri

Postat acum 4 zile
yaml
version: '3.8'

services:
  db:
    image: postgres:15-alpine
    container_name: nextjs_db
    restart: always
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: local_password_123
      POSTGRES_DB: myapp_dev
    ports:
      - "5435:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

  cache:
    image: redis:7-alpine
    container_name: nextjs_cache
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

M-am lovit de prea multe ori de colegi noi care pierdeau prima zi de onboarding configurând Postgres și Redis local. Ba nu aveau versiunea de Node potrivită, ba se băteau porturile cu alte proiecte mai vechi. Am trecut serviciile grele în Docker Compose și acum pornim totul cu o singură comandă.

De ce Next.js rămâne pe "host"

Văd des greșeala asta la juniori: vor să pună absolut totul în Docker, inclusiv aplicația Next.js aflată în plină dezvoltare. Sună bine în teorie, dar pe macOS sau Windows e un coșmar din cauza performanței sistemului de fișiere (gândește-te la tonele de fișiere din node_modules care trebuie sincronizate în timp real).

Am avut un proiect mediu, cu vreo 15 pagini și destul de multe dependințe. Când am rulat Next.js în Docker pe un MacBook cu M1, timpul de Fast Refresh sărise de la 200ms la aproape 3 secunde. Era insuportabil pentru workflow. Trade-off-ul e simplu: rulează baza de date și Redis în containere, dar Next.js lasă-l să ruleze nativ pe mașina ta prin npm run dev. Obții ce e mai bun din ambele lumi.

Configurația de la care pornesc mereu

Mai jos ai un docker-compose.yml simplu și curat pe care îl copiez în rădăcina proiectului. Am mapat porturile și am adăugat volume persistente ca să nu pierzi datele de fiecare dată când oprești containerele. Versiunile Alpine pe care le-am ales sunt mult mai ușoare, economisesc cam 400MB de RAM pe mașina de dev, lucru care contează când ai și Slack-ul și Chrome-ul deschise cu 50 de tab-uri.

Am schimbat și portul extern al Postgres-ului în 5435. De ce? Pentru că sigur ai deja un Postgres instalat local de acum doi ani pe portul standard 5432 de care ai uitat, iar Docker-ul ar fi crăpat direct cu "port already in use".

Cum legăm Next.js de aceste servicii

În fișierul .env.local din proiectul tău Next.js, conexiunile vor arăta extrem de simplu:

DATABASE_URL="postgresql://postgres:local_password_123@localhost:5435/myapp_dev?schema=public" REDIS_URL="redis://localhost:6379"

Nu folosi localhost în interiorul rețelei Docker dacă vreodată decizi să bagi și Next-ul în Compose. Acolo va trebui să folosești numele serviciilor (db sau cache). Dar pentru rularea hibridă pe care o recomand, localhost funcționează perfect.

Pe un proiect cu 8k useri activi de care mă ocup acum, folosim Prisma. Am adăugat o comandă în package.json de tipul "db:up": "docker compose up -d". Astfel, colegii de la frontend nu sunt nevoiți să învețe comenzi complexe de Docker. Ei dau doar npm run db:up și apoi npm run dev. Atât.

Voi cum faceți? Țineți și Next-ul în Docker pe local sau mergeți pe varianta asta hibridă care nu-ți omoară procesorul?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.