todo: SaaS-Ausbau-Plan (Instance-per-Customer + GoCardless) dokumentiert
Detaillierter Plan für späteren SaaS-Umbau festgehalten, damit wir beim nächsten Mal nicht neu planen müssen: - Architektur: Instance-per-Customer (Weg C) → keine Multi-Tenancy im Code, pro Kunde eigene Docker-Instanz + DB → Isolation statt tenantId-Filter, DSGVO-freundlich - Admin-Portal (separate App) für Provisioning, Kundenverwaltung, Billing - Abrechnung über GoCardless (SEPA + Kreditkarte), 30-Tage-Trial - Plesk-Integration nutzen, KEIN eigener Mailserver - Technische Bausteine, Provisioning-Flow, Zeitschätzung (~3-4 Wochen) Status: erstmal nur auf der Todo, nicht angefangen. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
3e8ee0c1c6
commit
3369893f42
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue