docs: Plesk-API-Key-Anleitung in README ergänzt

Neuer Abschnitt erklärt Schritt-für-Schritt wie man den API-Key in Plesk anlegt:
- Variante 1: Über die Plesk-Oberfläche (Mein Profil → API-Token)
- Variante 2: Über SSH (plesk bin secret_key --create)
- Hinweise zur REST-API-Extension (falls API-Key-Button fehlt)
- Firewall-Konfiguration für Port 8443

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

README.md

@@ -170,12 +170,79 @@ Das System unterstützt die automatische Erstellung von E-Mail-Weiterleitungen a
    - **Name**: Bezeichnung (z.B. "Plesk Hauptserver")
    - **Typ**: Plesk/cPanel/DirectAdmin
    - **API-URL**: Server-URL (z.B. `https://server.de:8443`)
-   - **Benutzername/Passwort**: API-Zugangsdaten
+   - **API-Key** _(empfohlen bei Plesk)_: Key aus Plesk (siehe unten), alternativ Benutzername/Passwort
+   - **Benutzername/Passwort**: Nur wenn kein API-Key vorhanden
    - **Domain**: E-Mail-Domain (z.B. `stressfrei-wechseln.de`)
    - **Standard-Weiterleitung**: Zusätzliche Weiterleitungsadresse (optional)
 3. Provider als "Standard" und "Aktiv" markieren
 4. Verbindung testen
 
+### Plesk: API-Key anlegen
+
+Der API-Key ist die empfohlene Authentifizierungsmethode (sicherer als Passwort, kann pro
+Anwendung vergeben und widerrufen werden).
+
+**Variante 1: Über die Plesk-Oberfläche (einfachster Weg)**
+
+1. In Plesk als Admin einloggen
+2. Oben rechts auf den **eigenen Namen** → **"Mein Profil"** (oder direkt URL `/admin/my-profile/`)
+3. Tab **"API-Token"** oder **"API-Schlüssel"** öffnen
+4. **"API-Schlüssel erstellen"** (bzw. "Add API Key")
+5. Beschreibung vergeben (z.B. "OpenCRM")
+6. Den angezeigten Schlüssel **sofort kopieren** – er wird nur einmal angezeigt!
+7. Im CRM bei "API-Key" einfügen
+
+> **Hinweis:** Bei manchen Plesk-Versionen ist die Option unter
+> **Tools & Einstellungen** → **API-Schlüssel** oder **Werkzeuge & Einstellungen** →
+> **API-Tokens** zu finden. Wenn der Menüpunkt fehlt, muss ggf. die **REST API**
+> Extension installiert werden (siehe Variante 2).
+
+**Variante 2: Über die Kommandozeile (SSH als root)**
+
+Falls der API-Key-Button in Plesk nicht vorhanden ist, lässt er sich auch per SSH erstellen:
+
+```bash
+# API-Key generieren (läuft nicht ab)
+plesk bin secret_key --create -ip-address <IP-DEINES-SERVERS> -description "OpenCRM"
+
+# Beispiel:
+plesk bin secret_key --create -ip-address 0.0.0.0 -description "OpenCRM"
+```
+
+Der Befehl gibt den Key direkt zurück. Diesen kopieren und im CRM eintragen.
+
+**Alle API-Keys anzeigen:**
+```bash
+plesk bin secret_key --list
+```
+
+**API-Key löschen:**
+```bash
+plesk bin secret_key --delete <KEY>
+```
+
+### Plesk: REST API aktivieren (falls nicht vorhanden)
+
+Bei älteren Plesk-Versionen oder Custom-Installationen kann es sein, dass die
+REST API fehlt. Dann:
+
+1. **Tools & Einstellungen** → **Updates** → **Erweiterungen hinzufügen/entfernen**
+2. Nach **"REST API"** suchen und installieren
+3. Plesk-Neustart (meist nicht nötig, aber zur Sicherheit)
+
+### Plesk: Firewall-Hinweis
+
+Der CRM-Server muss den **Plesk-Port 8443** (Standard) erreichen können. Bei Plesk-Firewall:
+
+1. **Tools & Einstellungen** → **Firewall**
+2. **"Plesk-Dienst – Panel"** (Port 8443) für die IP des CRM-Servers erlauben
+
+Bei reiner Linux-Firewall (ufw/firewalld):
+```bash
+# Beispiel ufw
+ufw allow from <CRM-SERVER-IP> to any port 8443
+```
+
 ### Verwendung
 
 Beim Anlegen einer Stressfrei-Wechseln Adresse im Kundenbereich erscheint die Checkbox **"Beim E-Mail-Provider anlegen"**, wenn:

backend/todo.md

@@ -10,6 +10,91 @@
 
 ### Security System testen
 
+### 🚀 SaaS-Ausbau: Instance-per-Customer + Admin-Portal + GoCardless
+
+**Vision:** OpenCRM als SaaS anbieten. Jeder Kunde bekommt seine eigene
+isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
+über ein zentrales Admin-Portal.
+
+**Architektur-Entscheidung:** Weg C (Instance-per-Customer)
+- Pro Kunde eine eigene Docker-Instanz mit eigener DB
+- Keine `tenantId` im CRM-Code → keine Security-Risiken durch vergessene Filter
+- Komplette Datenisolation (DSGVO-freundlich)
+- Updates können gestaffelt ausgerollt werden (erst 10% testen)
+- Bei Kündigung: Docker-Image + DB-Export als "Mitnehm-Paket"
+
+**Bewusst NICHT dabei:** eigener Mailserver. Stattdessen Plesk-Integration
+(die wir schon haben) – Kunde bekommt Mail-Zugang über unseren Plesk bei Bedarf.
+
+---
+
+**Admin-Portal (separate App, neben den CRM-Instanzen):**
+- Kundenverwaltung: wer hat welchen Plan, Status (Trial/Active/Suspended/Cancelled)
+- "Neuen Kunden anlegen" → Provisioning-Script
+  - DB anlegen (Master-DB kennt die Mapping)
+  - Docker-Container starten
+  - Subdomain konfigurieren (`kundenname.deincrm.de` via Caddy/Traefik)
+  - Initial-Admin-Account erstellen + Einladungs-Email senden
+  - Optional: Factory-Defaults für Stammdaten einspielen
+- GoCardless-Integration (Webhook + Dashboard)
+- Instanz-Management: Pause/Resume bei Zahlungsproblemen
+- Logs & Metriken pro Instanz (optional)
+- Support-Bereich (Tickets? oder einfach E-Mail)
+
+---
+
+**Abrechnung mit GoCardless (gocardless.com):**
+- Zahlungsmethoden: SEPA-Lastschrift (Hauptfokus) + Kreditkarte (über GoCardless Embedded/Success)
+- 30 Tage kostenlose Testphase ohne Zahlungsmittel
+- Nach Trial: Mandats-Erfassung → regelmäßige Abbuchung
+- Mehrere Pläne (z.B. Basic / Pro / Enterprise) mit unterschiedlichen Features
+- Webhook-Endpoint im Admin-Portal:
+  - `payment_confirmed` → Instanz aktiv lassen
+  - `payment_failed` → Banner im CRM, nach X Tagen pausieren
+  - `mandate_cancelled` → Kündigungs-Flow
+- Rechnungsstellung: GoCardless liefert Zahlungsbelege, aber **echte Rechnungen**
+  (mit USt-ID, Rechnungsnummer etc.) müssen wir selbst generieren
+  (evtl. über das existierende PDF-Template-System aus dem CRM nutzen)
+
+---
+
+**Provisioning-Flow (grober Entwurf):**
+1. Kunde registriert sich auf Landing Page (Name, Firma, E-Mail, Wunsch-Subdomain)
+2. Admin-Portal: Trial-Instanz starten
+   - DB erstellen, Docker-Container hochfahren, Caddy-Config für Subdomain
+   - Einladungs-Email mit Admin-Login + Passwort-Reset-Link
+3. Tag 25: Erinnerungs-Email "Deine Trial läuft bald ab"
+4. Tag 30: Banner im CRM "Jetzt bezahlen oder pausieren"
+5. Kunde erfasst GoCardless-Mandat im Admin-Portal-Login
+6. Bei erfolgreicher Zahlung: Instanz bleibt aktiv
+7. Bei fehlender Zahlung nach 7 Tagen: Instanz pausiert (DB bleibt, UI zeigt Hinweis)
+
+---
+
+**Technische Bausteine für später:**
+- Master-DB mit Tenant-Tabelle (Name, Subdomain, DB-Name, Plan, Status, GoCardlessIDs)
+- Caddy oder Traefik als Reverse-Proxy mit Auto-SSL (Let's Encrypt)
+- Docker-Orchestrierung: einzelne `docker-compose.yml` pro Kunde oder Docker-Swarm/K8s
+- Backup-Strategie: pro Tenant separate Backups + zentrale Master-DB-Backups
+- Monitoring: ein Fail macht nicht alle down, aber wir müssen es mitbekommen
+- Logs zentral: z.B. Loki + Grafana für aggregierte Logs aller Instanzen
+
+---
+
+**Grobe Zeitschätzung:**
+- Admin-Portal (MVP): ~1 Woche
+- GoCardless-Integration + Webhooks: ~3-5 Tage
+- Provisioning-Automatisierung (Docker + Caddy): ~1 Woche
+- Landing Page + Checkout: ~3-5 Tage
+- Tests + Polishing: ~1 Woche
+- **Gesamt: ~3-4 Wochen**
+
+**Vorbereitung JETZT (einfach, macht später Arbeit leichter):**
+- ✅ Factory-Defaults System (schon erledigt, hilft beim Provisioning)
+- ✅ Domain/Label dynamisch per Provider (schon erledigt)
+- Docker-Compose aufräumen, Env-Variablen dokumentieren (klein, ein Tag)
+- Backup-Script robust + wiederherstellbar (haben wir schon weitgehend)
+
 ---
 
 ## ✅ Erledigt