Zum Hauptinhalt springen

Lokales Setup

Vorbedingungen​

  • Docker Engine oder Docker Desktop
  • Für Steam-Bot-Trades: ein separater Steam-Bot-Account, der vorher normal im Browser erstellt wurde

Kurz prüfen:

docker --version
docker compose version

Lokale Dateien erzeugen​

Im Repo-Root des Hauptprojekts:

cp .env.example .env
mkdir -p secrets

Lege danach mindestens diese Secret-Dateien im Ordner secrets/ an:

  • secrets/db_password
  • secrets/jwt_secret

Optionale Secret-Dateien hängen von den aktivierten Features ab und sind unter Secrets dokumentiert.

Die Datei .env.example enthält die nicht-sensitiven Docker- und Runtime-Werte. Secrets liegen bewusst getrennt im secrets/-Ordner.

Für Double-Opt-In müssen SMTP_HOST, SMTP_PORT, SMTP_FROM_EMAIL und die SMTP-Secrets gesetzt sein. Ohne SMTP-Konfiguration kann kein neuer Bestätigungscode versendet werden. Für neue Registrierungen ist außerdem secrets/steam_api_key erforderlich, weil darüber das Mindestalter des Steam-Accounts geprüft wird.

Stack starten​

./scripts/local/docker-up.sh

Das Script nutzt intern die Kombination aus Basis-Compose plus Local-Override:

docker compose -f docker-compose.yml -f docker-compose.local.yml up -d

Dabei passiert lokal Folgendes:

  • fehlende Frontend- und Backend-Dev-Images werden beim ersten Start gebaut
  • PostgreSQL, Backend und Frontend starten
  • das Backend führt automatisch npx prisma migrate deploy aus
  • das Backend startet mit npm run dev und Node-Watch
  • das Frontend startet mit Vite-Hot-Reload
  • der Vite-Dev-Server aktiviert den lokalen /api-Proxy auf das Backend
  • das Script gibt danach die klickbaren lokalen URLs im Terminal aus

Danach erreichst du:

  • Frontend: http://localhost:8080
  • Backend direkt: http://localhost:3001
  • PostgreSQL direkt: localhost:5432

Für normale Codeänderungen brauchst du keinen Image-Rebuild. Frontend-Änderungen werden über Vite-HMR aktualisiert, Backend-Änderungen starten den Node-Prozess im Backend-Container neu.

Rebuilds und Recreates​

Für einen expliziten Rebuild nach Änderungen an Dockerfiles oder package.json / package-lock.json:

docker compose -f docker-compose.yml -f docker-compose.local.yml up -d --build backend frontend

Wenn du nur .env oder Dateien in secrets/ geändert hast, brauchst du normalerweise keinen neuen Image-Build. In dem Fall reicht meist ein Recreate des betroffenen Containers, zum Beispiel:

docker compose -f docker-compose.yml -f docker-compose.local.yml up -d --force-recreate backend

Container stoppen:

docker compose -f docker-compose.yml -f docker-compose.local.yml down

Logs ansehen:

docker compose -f docker-compose.yml -f docker-compose.local.yml logs -f

Praktische lokale Kommandos​

Nur Backend-Logs:

docker compose -f docker-compose.yml -f docker-compose.local.yml logs -f backend

Prisma-Status im Backend-Container:

docker compose -f docker-compose.yml -f docker-compose.local.yml exec backend npx prisma migrate status

Prisma Studio lokal:

./scripts/local/prisma-studio.sh

Market-Price-Monitor lokal:

./scripts/local/market-price-monitor.sh

Backend-Tests im laufenden Backend-Container:

docker compose -f docker-compose.yml -f docker-compose.local.yml exec backend sh -lc '. /usr/local/bin/load-runtime-env.sh && npm test'

PSQL im Datenbank-Container:

docker compose -f docker-compose.yml -f docker-compose.local.yml exec postgres sh -lc 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"'

Codex-Hinweise für lokale Arbeit​

  • Das Hauptprojekt läuft über Docker.
  • Tests, Prisma und Datenbankzugriffe sollen über die laufenden Container ausgeführt werden.
  • Keine Einmalcontainer für normale Diagnose- oder Testläufe starten, wenn ein laufender Service-Container dafür verwendet werden kann.
  • Backend-Tests lokal immer im Backend-Container mit geladener Runtime-Env ausführen.