LogShip Cloud
Betriebskonzept für den SaaS-Betrieb

Betriebskonzept SaaS · Zusammenfassung

Was gebaut werden soll – auf einer Seite

LogShip wird in zwei Formen als SaaS angeboten. Beide laufen als vollständige Instanz (iDempiere + PostgreSQL + Nuxt-Frontend + Strapi + Elasticsearch) in je einer VM, geklont von der Golden-VM. Neu ist die Steuerungsebene, die alle Instanzen kennt, erzeugt, aktualisiert und abrechnet.

Drei Entscheidungen (01.11.2026)

Betriebskonzept SaaS · Zielarchitektur

Organigramm der Zielumgebung

Alle Instanzen stehen hinter dem zentralen Edge-Proxy. Die Cloud Console ist eine eigene, kleine VM außerhalb jeder Kundeninstanz und spricht über APIs mit Proxmox, Proxy, DNS, Jenkins, Monitoring und mit jeder Instanz. LogYou-Prod bleibt gewöhnliche Instanz und Buchhaltungs-Ledger.

Legende: blaue Rahmen = Instanzen bzw. Dienste, dunkel = Netzwerk-/Steuerungsebene, grau = Template und Infrastruktur. Ringe 1–3 = Reihenfolge beim Ausrollen (Kapitel 5). Grüner Doppelpfeil = einziger Berührungspunkt mit LogShip: Katalog lesen, Rechnungen schreiben.

Betriebskonzept SaaS · Mandantenmodell

Dedicated und Shared im iDempiere-Datenmodell

Beide Formen nutzen denselben Mandanten 1000000 aus der Golden-VM, weil die Anwendung diesen voraussetzt (Belegarten, Preisliste, Partnergruppe sind je Mandant konfiguriert). Die Trennung der Händler erfolgt über Organisationen und Rollen – das Modell, das heute schon zwischen LogYou und seinen Händlern gilt.

Regeln für geteilte Instanzen

• Rollen: Händlerrollen ohne Zugriff auf alle Organisationen, Org-Zugriff nur auf die eigene. Der Assistent erzeugt das bereits; die bekannte Lücke in Schritt 10 (Org-Zugriff anderer Rollen bleibt stehen, wenn ein eingeschränkter Admin ausführt) wird behoben, indem Schritt 10 mit dem Service-Token läuft.
• Konfiguration auf Mandantenebene (Belegarten, Preisliste, Versanddienstleister-Stammdaten) gehört dem Betreiber; Händler ändern sie nicht.
• Integrationen: Vor dem Verkauf von Marktplatz-/Carrier-Funktionen auf shared-Instanzen prüfen, dass jede Integration ihre Zugangsdaten aus der Org des Händlers liest, nicht aus mandantenweiten Zeilen.
• Bewusst nicht gewählt: ein AD_Client je Händler. Das wäre die stärkere Trennung, erfordert aber eine Umstellung der Anwendung (feste Mandanten-IDs in der Konfiguration) und steht dem Nutzen bei unter zehn Instanzen nicht gegenüber.

Betriebskonzept SaaS · Steuerungsebene

Repo logship-cloud: Inventar, Playbooks, Console

Ein Repo neben erp-nuxt-frontend. Das Inventar ist die einzige Quelle der Wahrheit über die Flotte und wird per Git nachvollziehbar geändert. Jede Lebenszyklus-Aktion ist ein Playbook, das dieses Inventar liest. Die Console ist die Bedienoberfläche für genau diese Playbooks – nicht mehr.

logship-cloud/
  inventory/
    instances.yml      # Quelle der Wahrheit
    group_vars/        # dedicated / shared / all
  playbooks/
    provision.yml      # Klon → Identität → Env
                       # → Secrets → DNS → Proxy
                       # → Monitoring → Abnahme
    deploy.yml         # Ring-Deploy, ein Build
    migrate.yml        # Schema-Migrationen
    rotate-service-token.yml
    os-update.yml · snapshot.yml
    decommission.yml
  roles/               # proxmox_clone, instance_env,
                       # npm_host, ionos_dns,
                       # checkmk_register, pbs_job,
                       # idempiere_migrate,
                       # frontend_deploy
  migrations/          # 0000-baseline.sql, 0001-…
  console/             # Nuxt 4 Cloud Console
  CLAUDE.md · README.md

- slug: shared-1
  kind: shared        # dedicated | shared
                      # demo | internal
  vmid: 119
  node: prox2
  ip: 192.168.12.69
  fqdn: shared-1.logship.cloud
  client_name: LogShip Cloud
  company: LogYou GmbH
  sizing: {memory_mb: 24576, cores: 4}
  app_ring: 1         # 0 Demo · 1 Shared
                      # 2 Dedicated · 3 Prod
  schema_version: 2026.11.0
  state: active       # provisioning |
                      # suspended | decommissioned
  created: 2026-11-05

Betriebskonzept SaaS · Provisionierung

Von der Golden-VM zur fertigen Instanz in zehn Schritten

Ein Lauf von provision.yml ersetzt den heutigen Klon plus rund acht Handschritte. Ergebnis: eine erreichbare, überwachte, gesicherte Instanz mit frischen Secrets und einem Eintrag im Inventar.

Betriebskonzept SaaS · Ausrollen

Ein Build, vier Ringe, ein Schema-Gate

Heute baut Jenkins je Zielhost neu. Künftig wird ein Build einmal auf dem Controller erzeugt, als Artefakt abgelegt und in fester Reihenfolge an alle Instanzen verteilt. Zwischen den Ringen stoppt der Lauf beim ersten Fehler; je Host bleiben Swap, /signin-Prüfung und automatischer Rollback wie im bestehenden Skript.

Betriebskonzept SaaS · Migrationen

Die größte Lücke: Instanzen müssen Änderungen nachziehen

Heute entstehen neue Spalten, Listenwerte und Fenster direkt auf Produktion; die Golden-VM holt sie per sync-from-prod.sh nach, bereits geklonte Instanzen nie. Für eine Flotte braucht jede Änderung eine versionierte, wiederholbar anwendbare Datei.

Betriebskonzept SaaS · Abrechnung

Katalog in LogShip, Messung in der Console, Rechnung auf Prod

Pakete, Features, Add-ons und Preise werden weiterhin in LogShip gepflegt (Einstellungen → Software-Katalog). Die Console liest diesen Katalog nur, misst die Nutzung jeder Instanz bzw. Händler-Org per REST-Zähler, rechnet und legt je Rechnungsempfänger einen Rechnungsentwurf auf LogYou-Prod an. Ab dort gelten die vorhandenen Prozesse.

Alle Feldnamen existieren bereits in CUST_SoftwarePlan; die Formel bildet genau das heutige Paketmodell ab: Monatspreis mit inkludierten Bestellungen, jede weitere Transaktion zum festen Satz.

Betriebskonzept SaaS · Abrechnung

Was gezählt wird und wie die Rechnung aussieht

Beispiel: Rechnungsentwurf für einen Händler auf shared-1 (Oktober 2026)

Preise sind Platzhalter aus dem aktuellen Katalog-Default. Jede Zeile trägt den beim Lauf gültigen Katalogpreis als Snapshot (Nachvollziehbarkeit bei späteren Preisänderungen).

Betriebskonzept SaaS · Feature-Buchung

Zuschalten, anteilig zahlen, bis Monatsende behalten

Künftig schaltet ein Kunden-Admin kostenpflichtige Funktionen im Einstellungsbereich selbst ein und aus. Eine Funktion wird monatlich berechnet; bei Aktivierung mitten im Monat nur anteilig nach Tagen; nach Deaktivierung bleibt sie bis zum Ende des bezahlten Monats aktiv. Noch nicht umgesetzt – hier als Zustandsmodell festgehalten, damit Daten und Abrechnung von Anfang an dazu passen.

Betriebskonzept SaaS · Feature-Buchung

Logik in der Console, dünne Oberfläche im ERP

Einordnung: Das ist die einzige geplante Code-Berührung des ERP für den SaaS-Betrieb, ausdrücklich gewünscht, weil der Kunde die Buchung in seinem Frontend vornehmen soll. Sie kommt in Phase 7, nachdem Flotte, Migrationen und Rechnungslauf stehen.

Betriebskonzept SaaS · Cloud Console

Eine kleine Nuxt-4-Anwendung auf eigener VM

Nuxt 4 mit Nuxt UI (keine AG-Grid-Lizenzfrage), SQLite im data/-Verzeichnis, Zugang nur für LogYou-Mitarbeiter (YubiKey/WebAuthn, LAN/VPN bzw. IP-Allowlist am Edge-Proxy). Läuft mit pm2 wie die Instanzen, hat eigenen Backup-Job und Monitoring. VM-Vorschlag: logship-cloud-1, 2 vCPU / 4 GB, Debian 12 cloud-init.

Betriebskonzept SaaS · Fahrplan

Sieben Phasen, jede für sich nutzbar

Betriebskonzept SaaS · Offene Punkte

Was vor dem ersten zahlenden SaaS-Kunden geklärt sein muss