- Add Products collection with comprehensive fields (pricing, inventory, SEO, CTA) - Add ProductCategories collection with hierarchical structure - Implement CI/CD pipeline with GitHub Actions (lint, typecheck, test, build, e2e) - Add access control test utilities and unit tests - Fix Posts API to include category field for backwards compatibility - Update ESLint config with ignores for migrations and admin components - Add centralized access control functions in src/lib/access - Add db-direct.sh utility script for database access 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
20 KiB
Payload CMS Multi-Tenant Project
Projektübersicht
Multi-Tenant CMS für 4 Websites unter einer Payload CMS 3.x Instanz:
- porwoll.de
- complexcaresolutions.de
- gunshin.de
- zweitmein.ng
Tech Stack
- CMS: Payload CMS 3.x
- Framework: Next.js 15.4.7
- Sprache: TypeScript
- Datenbank: PostgreSQL 17 (separater Server)
- Connection Pool: PgBouncer 1.24.1 (Transaction-Mode)
- Reverse Proxy: Caddy 2.10.2 mit Let's Encrypt
- Process Manager: PM2
- Package Manager: pnpm
- Cache: Redis (optional, mit In-Memory-Fallback)
- Job Queue: BullMQ (Redis-basiert)
Architektur
Internet → 37.24.237.181 → Caddy (443) → Payload (3000)
↓
PgBouncer (6432)
↓
PostgreSQL (10.10.181.101:5432)
| Server | IP | Funktion |
|---|---|---|
| sv-payload (LXC 700) | 10.10.181.100 | App Server |
| sv-postgres (LXC 701) | 10.10.181.101 | Datenbank |
Wichtige Pfade
/home/payload/payload-cms/ # Projektroot
├── src/
│ ├── payload.config.ts # Haupt-Konfiguration
│ ├── collections/ # Alle Collections
│ │ ├── Users.ts
│ │ ├── Media.ts
│ │ ├── Tenants.ts
│ │ ├── Posts.ts
│ │ ├── Categories.ts
│ │ ├── Portfolios.ts
│ │ ├── PortfolioCategories.ts
│ │ ├── FAQs.ts
│ │ ├── Team.ts
│ │ ├── ServiceCategories.ts
│ │ ├── Services.ts
│ │ ├── EmailLogs.ts
│ │ ├── AuditLogs.ts
│ │ └── ...
│ ├── app/(payload)/api/ # Custom API Routes
│ │ ├── users/login/route.ts # Custom Login mit Audit
│ │ ├── send-email/route.ts
│ │ ├── email-logs/
│ │ │ ├── export/route.ts
│ │ │ └── stats/route.ts
│ │ └── test-email/route.ts
│ ├── lib/
│ │ ├── email/ # E-Mail-System
│ │ │ ├── tenant-email-service.ts
│ │ │ ├── payload-email-adapter.ts
│ │ │ ├── newsletter-service.ts # Newsletter Double Opt-In
│ │ │ └── newsletter-templates.ts # E-Mail-Templates
│ │ ├── security/ # Security-Module
│ │ │ ├── rate-limiter.ts
│ │ │ ├── csrf.ts
│ │ │ ├── ip-allowlist.ts
│ │ │ └── data-masking.ts
│ │ ├── queue/ # BullMQ Job Queue
│ │ │ ├── queue-service.ts
│ │ │ ├── jobs/email-job.ts
│ │ │ ├── jobs/pdf-job.ts
│ │ │ ├── workers/email-worker.ts
│ │ │ └── workers/pdf-worker.ts
│ │ ├── pdf/ # PDF-Generierung
│ │ │ └── pdf-service.ts
│ │ ├── search.ts # Volltextsuche
│ │ └── redis.ts # Redis Cache Client
│ └── hooks/ # Collection Hooks
│ ├── sendFormNotification.ts
│ ├── sendNewsletterConfirmation.ts # Newsletter Double Opt-In
│ ├── invalidateEmailCache.ts
│ └── auditLog.ts
├── tests/ # Test Suite
│ ├── unit/security/ # Security Unit Tests
│ └── int/ # Integration Tests
├── scripts/
│ ├── run-queue-worker.ts # Queue Worker Starter
│ └── backup/ # Backup-System
│ ├── backup-db.sh # PostgreSQL Backup-Skript
│ ├── restore-db.sh # PostgreSQL Restore-Skript
│ ├── setup-backup.sh # Interaktives Setup
│ └── README.md # Backup-Dokumentation
├── .env # Umgebungsvariablen
├── ecosystem.config.cjs # PM2 Config
└── .next/ # Build Output
Umgebungsvariablen (.env)
Hinweis: Sensible Credentials (DB_PASSWORD, SMTP_PASS, etc.) werden aus
~/.pgpassund Umgebungsvariablen gelesen. Niemals Klartext-Passwörter in diese Datei schreiben!
# Datenbank (Passwort in ~/.pgpass oder als Umgebungsvariable)
DATABASE_URI=postgresql://payload:${DB_PASSWORD}@127.0.0.1:6432/payload_db
PAYLOAD_SECRET=a53b254070d3fffd2b5cfcc3
PAYLOAD_PUBLIC_SERVER_URL=https://pl.c2sgmbh.de
NEXT_PUBLIC_SERVER_URL=https://pl.c2sgmbh.de
NODE_ENV=production
PORT=3000
# E-Mail (Global Fallback)
SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_SECURE=false
SMTP_USER=user@example.com
SMTP_PASS=secret
SMTP_FROM_ADDRESS=noreply@c2sgmbh.de
SMTP_FROM_NAME=Payload CMS
# Redis Cache
REDIS_URL=redis://localhost:6379
# Security
CSRF_SECRET=your-csrf-secret
SEND_EMAIL_ALLOWED_IPS= # Optional: Komma-separierte IPs/CIDRs
BLOCKED_IPS= # Optional: Global geblockte IPs
PgBouncer Connection Pooling
PgBouncer läuft auf dem App-Server und pooled Datenbankverbindungen:
# Konfiguration
/etc/pgbouncer/pgbouncer.ini
/etc/pgbouncer/userlist.txt # chmod 600
# Service
sudo systemctl status pgbouncer
sudo systemctl restart pgbouncer
# Statistiken abfragen
# Pool-Statistiken (Passwort aus ~/.pgpass)
PGPASSWORD="$DB_PASSWORD" psql -h 127.0.0.1 -p 6432 -U payload -d pgbouncer -c "SHOW POOLS;"
PGPASSWORD="$DB_PASSWORD" psql -h 127.0.0.1 -p 6432 -U payload -d pgbouncer -c "SHOW STATS;"
Konfiguration:
| Parameter | Wert | Beschreibung |
|---|---|---|
| pool_mode | transaction | Verbindung wird nach Transaktion freigegeben |
| default_pool_size | 20 | Standard-Pool-Größe pro DB/User |
| min_pool_size | 5 | Mindestens gehaltene Verbindungen |
| reserve_pool_size | 5 | Reserve für Lastspitzen |
| max_db_connections | 50 | Max. Verbindungen zu PostgreSQL |
| max_client_conn | 200 | Max. Clients zu PgBouncer |
Verbindungen:
- App → PgBouncer:
127.0.0.1:6432(DATABASE_URI) - PgBouncer → PostgreSQL:
10.10.181.101:5432(TLS 1.3,server_tls_sslmode = require)
Direkte Verbindung (für Migrationen/CLI):
PgBouncer im Transaction-Mode kann Probleme mit lang laufenden Migrationen verursachen.
Für solche Fälle das db-direct.sh Skript verwenden:
# Migrationen direkt an PostgreSQL (umgeht PgBouncer)
./scripts/db-direct.sh migrate
# Interaktive psql-Session
./scripts/db-direct.sh psql
# Schema-Änderungen
./scripts/db-direct.sh migrate:create
Das Skript liest Credentials aus ~/.pgpass (chmod 600).
Multi-Tenant Plugin
Verwendet @payloadcms/plugin-multi-tenant für Mandantenfähigkeit.
Aktuelle Tenants:
| ID | Name | Slug |
|---|---|---|
| 1 | porwoll.de | porwoll |
| 4 | Complex Care Solutions GmbH | c2s |
| 5 | Gunshin | gunshin |
User-Tenant-Zuweisung: Tabelle users_tenants
Wichtige Befehle
# Entwicklung
pnpm dev
# Production Build
pnpm build
# Migrationen
pnpm payload migrate:create
pnpm payload migrate
# ImportMap nach Plugin-Änderungen
pnpm payload generate:importmap
# PM2
pm2 status
pm2 logs payload
pm2 logs queue-worker
pm2 restart payload
pm2 restart queue-worker
# Tests
pnpm test # Alle Tests
pnpm test:security # Security Tests
pnpm test:access-control # Access Control Tests
pnpm test:coverage # Mit Coverage-Report
# Datenbank prüfen
# Verwende ./scripts/db-direct.sh psql oder:
PGPASSWORD="$DB_PASSWORD" psql -h 10.10.181.101 -U payload -d payload_db
# Backup
/home/payload/backups/postgres/backup-db.sh --verbose # Manuelles Backup
scripts/backup/setup-backup.sh # Backup-System einrichten
Workflow nach Code-Änderungen
- Code ändern
pnpm buildpm2 restart payload- Testen unter https://pl.c2sgmbh.de/admin
Bekannte Besonderheiten
- ES Modules: package.json hat
"type": "module", daher PM2 Config als.cjs - Plugin ImportMap: Nach Plugin-Änderungen
pnpm payload generate:importmapausführen - User-Tenant-Zuweisung: Neue User müssen manuell Tenants zugewiesen bekommen
- Admin Login: Custom Route mit Audit-Logging, unterstützt JSON und
_payloadFormData
Build-Konfiguration
Der Build ist für speichereffizientes Kompilieren optimiert:
package.json:--max-old-space-size=2048(2GB Heap-Limit)next.config.mjs:experimental.cpus: 1,workerThreads: false
WICHTIG: Der Server hat 8GB RAM ohne Swap. Bei laufendem VS Code Server kann der Build mit reduziertem Memory ausgeführt werden:
pm2 stop payload # Speicher freigeben
NODE_OPTIONS="--no-deprecation --max-old-space-size=1024" ./node_modules/.bin/next build
pm2 start payload
Ohne PM2-Stop und mit VS Code wird der Build vom OOM Killer beendet (Exit code 137).
Mehrsprachigkeit (i18n)
Das System unterstützt Deutsch (default) und Englisch:
- Admin UI:
@payloadcms/translationsfür DE/EN - Content: Localization mit Fallback auf Deutsch
- Datenbank: 36
_localesTabellen für lokalisierte Felder - API:
?locale=deoder?locale=enParameter - Frontend: Routing über
/[locale]/...
# Locales in der Datenbank prüfen
# Verwende ./scripts/db-direct.sh psql oder:
PGPASSWORD="$DB_PASSWORD" psql -h 10.10.181.101 -U payload -d payload_db -c "\dt *_locales"
URLs
- Admin Panel: https://pl.c2sgmbh.de/admin
- API: https://pl.c2sgmbh.de/api
- API-Dokumentation (Swagger UI): https://pl.c2sgmbh.de/api/docs
- OpenAPI JSON: https://pl.c2sgmbh.de/api/openapi.json
- E-Mail API: https://pl.c2sgmbh.de/api/send-email (POST, Auth erforderlich)
- Test-E-Mail: https://pl.c2sgmbh.de/api/test-email (POST, Admin erforderlich)
- E-Mail Stats: https://pl.c2sgmbh.de/api/email-logs/stats (GET, Auth erforderlich)
- PDF-Generierung: https://pl.c2sgmbh.de/api/generate-pdf (POST/GET, Auth erforderlich)
- Newsletter Anmeldung: https://pl.c2sgmbh.de/api/newsletter/subscribe (POST, öffentlich)
- Newsletter Bestätigung: https://pl.c2sgmbh.de/api/newsletter/confirm (GET/POST)
- Newsletter Abmeldung: https://pl.c2sgmbh.de/api/newsletter/unsubscribe (GET/POST)
Security-Features
Rate-Limiting
Zentraler Rate-Limiter mit vordefinierten Limits:
publicApi: 60 Requests/Minuteauth: 5 Requests/15 Minuten (Login)email: 10 Requests/Minutesearch: 30 Requests/Minuteform: 5 Requests/10 Minuten
CSRF-Schutz
- Double Submit Cookie Pattern
- Origin-Header-Validierung
- Token-Endpoint:
GET /api/csrf-token - Admin-Panel hat eigenen CSRF-Schutz
IP-Allowlist
- Konfigurierbar via
SEND_EMAIL_ALLOWED_IPS - Unterstützt IPs, CIDRs (
192.168.1.0/24) und Wildcards (10.10.*.*) - Globale Blocklist via
BLOCKED_IPS
Data-Masking
- Automatische Maskierung sensibler Daten in Logs
- Erkennt Passwörter, Tokens, API-Keys, SMTP-Credentials
- Safe-Logger-Factory für konsistentes Logging
E-Mail-System
Multi-Tenant E-Mail-System mit tenant-spezifischer SMTP-Konfiguration:
Architektur:
- Globaler SMTP als Fallback (via .env)
- Tenant-spezifische SMTP in Tenants Collection
- Transporter-Caching mit automatischer Invalidierung
- EmailLogs Collection für Audit-Trail
Tenant E-Mail-Konfiguration:
Tenants → email → fromAddress, fromName, replyTo
→ email → useCustomSmtp (Checkbox)
→ email → smtp → host, port, secure, user, pass
API-Endpoint /api/send-email:
curl -X POST https://pl.c2sgmbh.de/api/send-email \
-H "Content-Type: application/json" \
-H "Cookie: payload-token=..." \
-d '{
"to": "empfaenger@example.com",
"subject": "Betreff",
"html": "<p>Inhalt</p>",
"tenantId": 1
}'
Sicherheit:
- Authentifizierung erforderlich
- Tenant-Zugriffskontrolle (User muss Tenant-Mitglied sein)
- Rate-Limiting: 10 E-Mails/Minute pro User
- SMTP-Passwort nie in API-Responses
Newsletter Double Opt-In
DSGVO-konformes Newsletter-System mit Double Opt-In:
Flow:
- User meldet sich an → Status:
pending, Token wird generiert - Double Opt-In E-Mail wird automatisch gesendet
- User klickt Bestätigungs-Link → Status:
confirmed - Willkommens-E-Mail wird gesendet
- Abmeldung jederzeit über Link in E-Mails möglich
API-Endpoints:
# Newsletter-Anmeldung
curl -X POST https://pl.c2sgmbh.de/api/newsletter/subscribe \
-H "Content-Type: application/json" \
-d '{
"email": "user@example.com",
"firstName": "Max",
"tenantId": 1,
"source": "footer"
}'
# Bestätigung (via Link aus E-Mail)
GET https://pl.c2sgmbh.de/api/newsletter/confirm?token=<uuid>
# Abmeldung (via Link aus E-Mail)
GET https://pl.c2sgmbh.de/api/newsletter/unsubscribe?token=<uuid>
Features:
- Automatischer E-Mail-Versand bei Anmeldung
- Token-Ablauf nach 48 Stunden
- Willkommens-E-Mail nach Bestätigung
- Abmelde-Bestätigung per E-Mail
- Rate-Limiting: 5 Anmeldungen/10 Minuten pro IP
- Erneute Anmeldung nach Abmeldung möglich
BullMQ Job Queue
Das System verwendet BullMQ für asynchrone Job-Verarbeitung mit Redis als Backend.
PM2 Worker
Der Queue-Worker läuft als separater PM2-Prozess:
# Worker-Status prüfen
pm2 status
pm2 logs queue-worker
# Worker neustarten
pm2 restart queue-worker
Email Queue
E-Mails können asynchron über die Queue versendet werden:
import { queueEmail } from '@/lib/queue'
await queueEmail({
tenantId: 1,
to: 'empfaenger@example.com',
subject: 'Betreff',
html: '<p>Inhalt</p>',
source: 'form-submission'
})
PDF Queue
PDF-Generierung erfolgt über Playwright (HTML/URL zu PDF):
API-Endpoint /api/generate-pdf:
# PDF aus HTML generieren
curl -X POST https://pl.c2sgmbh.de/api/generate-pdf \
-H "Content-Type: application/json" \
-H "Cookie: payload-token=..." \
-d '{
"source": "html",
"html": "<h1>Test</h1><p>Inhalt</p>",
"filename": "test.pdf"
}'
# Job-Status abfragen
curl "https://pl.c2sgmbh.de/api/generate-pdf?jobId=abc123" \
-H "Cookie: payload-token=..."
Programmatisch:
import { queuePdfFromHtml, queuePdfFromUrl, getPdfJobStatus } from '@/lib/queue'
// HTML zu PDF
const job = await queuePdfFromHtml('<h1>Test</h1>', { filename: 'test.pdf' })
// URL zu PDF
const job2 = await queuePdfFromUrl('https://example.com', { format: 'A4' })
// Status abfragen
const status = await getPdfJobStatus(job.id)
Worker-Konfiguration
Über ecosystem.config.cjs:
QUEUE_EMAIL_CONCURRENCY: Parallele E-Mail-Jobs (default: 3)QUEUE_PDF_CONCURRENCY: Parallele PDF-Jobs (default: 2)QUEUE_DEFAULT_RETRY: Retry-Versuche (default: 3)QUEUE_REDIS_DB: Redis-Datenbank für Queue (default: 1)
Redis Caching
Redis wird für API-Response-Caching und E-Mail-Transporter-Caching verwendet:
import { redis } from '@/lib/redis'
// Cache setzen (TTL in Sekunden)
await redis.set('key', JSON.stringify(data), 'EX', 60)
// Cache lesen
const cached = await redis.get('key')
// Pattern-basierte Invalidierung
await redis.keys('posts:*').then(keys => keys.length && redis.del(...keys))
Backup-System
Automatisches tägliches PostgreSQL-Backup mit lokalem Speicher und S3-Offsite-Backup.
Setup auf neuem Server:
cd /home/payload/payload-cms/scripts/backup
./setup-backup.sh
Konfigurationsdateien (nicht im Repo):
~/.pgpass- PostgreSQL-Credentials (chmod 600)~/.s3cfg- S3-Credentials (chmod 600)
Backup-Speicherorte:
| Ort | Pfad | Retention |
|---|---|---|
| Lokal | /home/payload/backups/postgres/ |
30 Tage |
| S3 | s3://c2s/backups/postgres/ |
30 Tage |
Cron-Job: Täglich um 03:00 Uhr
Manuelles Backup:
/home/payload/backups/postgres/backup-db.sh --verbose
Restore aus Backup:
# Lokal
gunzip -c /home/payload/backups/postgres/payload_db_YYYY-MM-DD_HH-MM-SS.sql.gz | \
psql -h 10.10.181.101 -U payload -d payload_db
# Aus S3
s3cmd get s3://c2s/backups/postgres/payload_db_YYYY-MM-DD_HH-MM-SS.sql.gz
gunzip -c payload_db_*.sql.gz | psql -h 10.10.181.101 -U payload -d payload_db
Dokumentation: scripts/backup/README.md
Datenbank-Direktzugriff
# Verwende ./scripts/db-direct.sh psql oder:
PGPASSWORD="$DB_PASSWORD" psql -h 10.10.181.101 -U payload -d payload_db
# Nützliche Queries
SELECT * FROM tenants;
SELECT * FROM users_tenants;
SELECT * FROM email_logs ORDER BY created_at DESC LIMIT 10;
SELECT * FROM audit_logs ORDER BY created_at DESC LIMIT 10;
\dt -- Alle Tabellen
Collections Übersicht
| Collection | Slug | Beschreibung |
|---|---|---|
| Users | users | Benutzer mit isSuperAdmin Flag |
| Tenants | tenants | Mandanten mit E-Mail-Konfiguration |
| Media | media | Medien mit 11 responsive Image Sizes |
| Pages | pages | Seiten mit Blocks |
| Posts | posts | Blog/News/Presse mit Kategorien |
| Categories | categories | Kategorien für Posts |
| Portfolios | portfolios | Portfolio-Galerien (Fotografie) |
| PortfolioCategories | portfolio-categories | Kategorien für Portfolios |
| Testimonials | testimonials | Kundenbewertungen |
| FAQs | faqs | Häufig gestellte Fragen (FAQ) |
| Team | team | Team-Mitglieder und Mitarbeiter |
| ServiceCategories | service-categories | Kategorien für Leistungen |
| Services | services | Leistungen und Dienstleistungen |
| NewsletterSubscribers | newsletter-subscribers | Newsletter mit Double Opt-In |
| SocialLinks | social-links | Social Media Links |
| Forms | forms | Formular-Builder |
| FormSubmissions | form-submissions | Formular-Einsendungen mit Status-Workflow |
| EmailLogs | email-logs | E-Mail-Protokollierung |
| AuditLogs | audit-logs | Security Audit Trail |
| CookieConfigurations | cookie-configurations | Cookie-Banner Konfiguration |
| CookieInventory | cookie-inventory | Cookie-Inventar |
| ConsentLogs | consent-logs | Consent-Protokollierung |
FormSubmissions CRM-Workflow
Die FormSubmissions Collection wurde zu einem leichtgewichtigen CRM erweitert:
Status-Workflow:
- 🆕 Neu → 👀 Gelesen → 🔄 In Bearbeitung → ⏳ Warten → ✅ Erledigt → 🗑️ Archiviert
Features:
- Priorität (Hoch/Normal/Niedrig)
- Zuständigkeits-Zuweisung an User
- Interne Notizen mit Auto-Autor und Zeitstempel
- Antwort-Tracking (Methode, Zeitstempel, Zusammenfassung)
- Tags zur Kategorisierung
- Auto-Markierung als gelesen beim ersten Öffnen
Dateien:
src/collections/FormSubmissionsOverrides.ts- Feld-Definitionensrc/hooks/formSubmissionHooks.ts- Automatisierungen
Globals
| Global | Slug | Beschreibung |
|---|---|---|
| SiteSettings | site-settings | Allgemeine Website-Einstellungen |
| Navigation | navigation | Navigationsmenü |
| SEOSettings | seo-settings | SEO-Einstellungen |
| PrivacyPolicySettings | privacy-policy-settings | Datenschutz-Einstellungen |
Test Suite
# Alle Tests ausführen
pnpm test
# Security Tests
pnpm test:security
# Coverage Report
pnpm test:coverage
Test Coverage Thresholds:
- Lines: 35%
- Functions: 50%
- Branches: 65%
CI/CD Pipeline
GitHub Actions Workflows in .github/workflows/:
ci.yml (Main CI Pipeline)
Läuft bei Push/PR auf main und develop:
| Job | Beschreibung |
|---|---|
| lint | ESLint + Prettier Check |
| typecheck | TypeScript Compiler (tsc --noEmit) |
| test | Unit & Integration Tests (Vitest) |
| build | Next.js Production Build |
| e2e | Playwright E2E Tests |
Lokale Ausführung:
pnpm lint # ESLint
pnpm typecheck # TypeScript Check
pnpm format:check # Prettier Check
pnpm format # Prettier Auto-Fix
pnpm test # Alle Tests
pnpm build # Production Build
security.yml (Security Scanning)
- Gitleaks: Secret Scanning
- pnpm audit: Dependency Vulnerabilities
- CodeQL: Static Analysis (SAST)
- Security Tests: Unit & Integration Tests für Security-Module
Dokumentation
CLAUDE.md- Diese Datei (Projekt-Übersicht)docs/INFRASTRUCTURE.md- Server-Architektur & Deploymentdocs/anleitungen/TODO.md- Task-Liste & Roadmapdocs/anleitungen/SECURITY.md- Sicherheitsrichtlinienscripts/backup/README.md- Backup-System Dokumentation
Letzte Aktualisierung: 12.12.2025