documentation/deployment/DEPLOYMENT.md

Deployment Guide - Payload CMS Multi-Tenant

Letzte Aktualisierung: 17. Januar 2026

Wichtig: Für die vollständige Deployment-Strategie siehe DEPLOYMENT_STRATEGY.md

Übersicht

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   DEVELOPMENT   │     │     STAGING     │     │   PRODUCTION    │
│  sv-frontend    │───▶│   sv-payload    │───▶│   Hetzner 3     │
│  Local Dev      │     │ pl.porwoll.tech│     │ cms.c2sgmbh.de │
│  develop branch │     │ develop branch │     │   main branch  │
└─────────────────┘     └─────────────────┘     └─────────────────┘

---

Umgebungen

Umgebung	Server	URL	Branch	Zweck
Development	sv-payload (LXC 700)	https://pl.porwoll.tech	develop	Entwicklung & Testing
Production	Hetzner 3	https://cms.c2sgmbh.de	main	Live-System

---

Git Branching Workflow

Regel: Immer auf develop entwickeln, nach Freigabe mit main mergen.

# 1. Auf develop entwickeln
git checkout develop
git pull origin develop
git add . && git commit -m "feat: neue Funktion"
git push origin develop
# → Automatisches Deployment auf Staging

# 2. Nach Test: Merge in main
git checkout main && git merge develop && git push origin main
# → Manuelles Deployment auf Production

---

Staging Deployment (develop → pl.porwoll.tech)

Automatisch via GitHub Actions

Bei jedem Push auf develop wird automatisch deployed:

1. Pre-deployment Checks (Lint, Tests)
2. SSH-Verbindung zu sv-payload
3. git pull origin develop
4. pnpm install
5. pnpm payload migrate
6. pnpm build
7. pm2 restart payload
8. Health Check

Manuell auf sv-payload

ssh payload@10.10.181.100
cd /home/payload/payload-cms
git pull origin develop
pnpm install
pnpm payload migrate
pnpm build
pm2 restart payload
pm2 logs payload --lines 20

---

Production Deployment (main → cms.c2sgmbh.de)

Option A: Via GitHub Actions (Empfohlen)

git checkout main && git merge develop && git push origin main
gh workflow run deploy-production.yml

Der Workflow führt automatisch aus: Pre-flight Checks, Tests, Datenbank-Backup, Deployment, Health Check, bei Fehler automatischer Rollback.

Option B: Via Deploy-Script auf Server

ssh payload@162.55.85.18
cd ~/payload-cms
./scripts/deploy-production.sh

# Optionen:
./scripts/deploy-production.sh -y              # Ohne Bestätigung
./scripts/deploy-production.sh --skip-backup   # Ohne Backup
./scripts/deploy-production.sh --rollback      # Rollback
./scripts/deploy-production.sh --dry-run       # Dry-Run

---

Rollback

# Automatischer Rollback
./scripts/deploy-production.sh --rollback

# Manuell zu Commit
git log --oneline -10
git reset --hard <commit-sha>
pnpm install && pnpm build
pm2 restart payload

---

CI/CD Pipeline

Workflow	Trigger	Aktion
ci.yml	Push/PR auf main, develop	Lint, Test, Build
security.yml	Push/PR, Schedule	Security Scanning
deploy-staging.yml	Push auf develop	Auto-Deploy zu Staging
deploy-production.yml	Manuell	Production Deployment

GitHub Secrets

Secret	Beschreibung
STAGING_SSH_KEY	SSH Private Key für sv-payload
PRODUCTION_SSH_KEY	SSH Private Key für Hetzner 3

---

Umgebungsvariablen

Production (.env)

DATABASE_URI=postgresql://payload:***@localhost:5432/payload_db
PAYLOAD_PUBLIC_SERVER_URL=https://cms.c2sgmbh.de
NODE_ENV=production
PORT=3001
REDIS_URL=redis://localhost:6379

Staging (.env)

DATABASE_URI=postgresql://payload:***@127.0.0.1:6432/payload_db
PAYLOAD_PUBLIC_SERVER_URL=https://pl.porwoll.tech
NODE_ENV=production
PORT=3000
REDIS_URL=redis://localhost:6379

---

Health Check

pm2 status
pm2 logs payload --lines 50
curl -I https://cms.c2sgmbh.de/api/users
curl -I https://cms.c2sgmbh.de/admin
redis-cli ping