Von Zero zu Production: Der komplette ayedo SDP-Workflow in einem Beispiel

TL;DR

• Ausgangspunkt ist eine mehrmandantenfähige Django-SaaS-Anwendung, die auf der ayedo Software Delivery Platform (SDP) von der ersten Codezeile bis in den produktiven Betrieb gebracht wird.
• Der Workflow folgt einem klaren Pfad: GitLab-Repository → Packaging mit ohMyHelm → GitLab CI/CD → Container- und Chart-Registry in Harbor → Secrets in Vault via External Secrets Operator → GitOps-Deployment mit ArgoCD auf Kubernetes → TLS mit Cert-Manager → Netzwerk-Sicherheit mit Cilium → Observability mit VictoriaMetrics und zentralen Logs → Alerting → Backups und Disaster-Recovery mit Velero.
• Entlang dieses Pfades werden die Anforderungen aus GDPR, NIS-2, DORA, Cyber Resilience Act, Data Act und europäischer Cloud-Souveränität systematisch adressiert: Datenminimierung, Nachvollziehbarkeit, Security-by-Design, Resilienz und Portabilität.
• Ergebnis: Eine produktionsreife, beobachtbare und gehärtete Plattform-Lösung für Multi-Tenant-SaaS, die technisch und organisatorisch auf europäische Regulierung vorbereitet ist.
• ayedo stellt mit der SDP eine vorkonfigurierte, auditierbare Plattform bereit und begleitet Teams bei Architektur, Umsetzung und End-to-End-Demos, damit dieser Workflow nicht theoretisch bleibt, sondern im eigenen Unternehmen produktiv genutzt werden kann.

---

Das Szenario: Eine europäische Django-SaaS in die Produktion bringen

Stellen Sie sich vor, Sie verantworten ein mehrmandantenfähiges Django-SaaS-Produkt für Unternehmen in regulierten Branchen: personenbezogene Daten, geschäftskritische Workflows, anspruchsvolle Kunden-Audits. Die Anwendung muss mandantensicher, hochverfügbar und auditierbar laufen – idealerweise auf einer europäischen, souveränen Plattform.

Regulatorisch bewegen Sie sich im Spannungsfeld von:

• GDPR seit dem 25.05.2018
• NIS-2, anwendbar ab dem 18.10.2024
• DORA für Finanz- und ICT-Dienstleister ab dem 17.01.2025
• Cyber Resilience Act (CRA), dessen Kernpflichten für Hersteller von Software und digitalen Produkten sukzessive wirksam werden
• Data Act, der seit dem 11.01.2024 schrittweise Anwendung findet

Sie möchten nicht jede Norm im Detail implementieren, sondern eine Plattform, die diese Anforderungen strukturiert abbildet. Genau das leisten wir mit einem integrierten Workflow auf der ayedo SDP – vom Git-Commit bis zum produktiven, beobachtbaren Service.

---

Schritt 1: Architektur- und Compliance-Ziele bewusst setzen

Bevor wir Werkzeuge betrachten, ist die Zielarchitektur entscheidend. Für unsere Django-Multi-Tenant-SaaS definieren wir:

• Multi-Tenancy-Strategie:
  Beispielsweise Mandanten-Trennung auf Datenbank-Schema-Ebene oder eigene Datenbanken pro Mandant, ergänzt durch strikte Authorisierung im Code und Netzwerksegmentierung im Cluster.
• Sicherheitsziele:
  Verschlüsselung in Transit und at Rest, minimale Angriffsfläche, gehärtete Supply-Chain, Secrets konsequent aus dem Code verbannt.
• Betriebsziele:
  GitOps-gestützte Deployments, reproduzierbare Releases, automatisierte Rollbacks, Observability als first-class citizen.
• Compliance-Ziele:
  Nachvollziehbare Changes (Audit-Trail via GitLab und ArgoCD), kontrollierte Zugriffe (RBAC), dokumentierte Datenflüsse und klarer Verantwortungszuschnitt – alles Elemente, die für GDPR, NIS-2 und DORA zentral sind.

Die ayedo SDP bringt dafür eine vorkonfigurierte Plattform auf Basis von Kubernetes mit, inklusive GitLab, Harbor, Vault, ArgoCD, Observability-Stack und Backup-Lösungen. Darauf bauen wir im Folgenden auf.

---

Schritt 2: Vom Django-Code zum ohMyHelm-Paket

Die Reise beginnt im GitLab-Repository Ihrer Django-Anwendung:

• Source-Code der Django-App, inklusive Mandantenlogik und Konfiguration.
• Infrastructure-as-Config auf Applikationsebene via Helm-Chart, generiert und verwaltet mit ohMyHelm.
• Policies und Guardrails, die sicherstellen, dass Ihre Deployments Plattform-Standards einhalten (Ressourcen-Limits, Probes, SecurityContext, Labels für Auditing).

ohMyHelm strukturiert den Applikations-Teil Ihrer Plattformkonfiguration:

• Standardisierte Chart-Struktur für alle Services.
• Vorgaben für Logging, Metriken und Health-Checks.
• Vorkonfigurierte Hooks, um Secrets und ConfigMaps ausschließlich über Vault und den External Secrets Operator zu beziehen – ein wichtiger Baustein für Security-by-Design im Sinne des Cyber Resilience Act.

Damit schaffen Sie einen reproduzierbaren Deployable-Artefakt: das Application-Chart, das später von ArgoCD konsumiert wird.

---

Schritt 3: GitLab CI/CD – Build, Test, Security, Packaging

Die GitLab CI/CD-Pipeline übersetzt Commits in geprüfte, deploybare Artefakte:

1. Tests und Qualitätssicherung

   • Unit- und Integrationstests für Django.
   • Linting und statische Analysen, inklusive Security-Checks der Abhängigkeiten.
   • Optional: SCA- und Container-Security-Scans als eigene Pipeline-Jobs.

   Diese Schritte zahlen direkt auf CRA- und NIS-2-Anforderungen ein: dokumentierte Security-Tests, nachvollziehbare Build-Pipelines, reproducible builds.

2. Container-Build

   • Container-Image-Build mit Kaniko oder Buildah, also daemonless und rootless.
   • Klare Tagging-Strategie (Commit-SHA, Semver), um jede Deployment-Version eindeutig rückverfolgen zu können.

3. Chart-Packaging

   • Versionierung des Helm-Charts entsprechend der App-Version.
   • Packaging in ein OCI-kompatibles Chart-Archiv, das später in Harbor bereitgestellt wird.

Die Pipeline bildet damit Ihren „Software-Lieferprozess“ ab – ein zentraler Aspekt von DORA und CRA: nachvollziehbar, wiederholbar, prüfbar.

---

Schritt 4: Images und Charts in Harbor – Ihre Single Source of Truth

Harbor fungiert als zentrale Registry für:

• Container-Images Ihrer Django-App und Sidecars.
• OCI-basierte Helm-Charts.
• Optional: SBOMs und Scan-Ergebnisse.

Typische Features, die gerade im Compliance-Kontext wertvoll sind:

• Projektbasierte Zugriffssteuerung und Audit-Logs.
• Integrierte Vulnerability-Scans.
• Replizierung in weitere Registries oder Regionen, falls nötig.

Für GDPR und Data Act ist Harbor vor allem aus zwei Gründen relevant:

• Transparenz im Software Supply Chain: Sie können jederzeit nachvollziehen, welche Komponenten wo eingesetzt werden.
• Datenlokalität: Betrieb in europäischen Rechenzentren unterstützt eine souveräne, EU-zentrierte Plattformstrategie.

---

Schritt 5: Datenbank und Secrets mit Vault und External Secrets Operator

Ihre Django-Mandanten benötigen Datenbanken, Credentials, API-Keys und Konfigurationen – jedoch nicht als Klartext in Git oder im CI-Log.

Hier übernimmt Vault die Rolle der zentralen Secrets-Authority:

• PostgreSQL-Credentials und Mandanten-Datenbanken werden automatisiert provisioniert.
• Rotate-Policies stellen sicher, dass Geheimnisse regelmäßig erneuert werden.
• Zugriff wird fein granular über Policies kontrolliert.

Der External Secrets Operator (ESO):

• Synchronisiert Secrets aus Vault in die Namespaces Ihrer Anwendungs-Deployments.
• Erstellt Kubernetes-Secrets, ohne dass sich Entwickler direkt mit Vault auseinandersetzen müssen.
• Hält Secrets aktuell, ohne Re-Deploy der Anwendung.

Diese Trennung ist ein starkes Argument in Audits nach GDPR und NIS-2:
Zugriff auf Produktionsgeheimnisse ist klar geregelt, dokumentiert und technisch durchgesetzt.

---

Schritt 6: GitOps mit ArgoCD – vom Chart zum laufenden Service

Mit ArgoCD verbindet sich der Workflow:

• Eine ArgoCD Application referenziert das Git-Repository bzw. die Helm-Chart-Definition.
• ArgoCD sorgt dafür, dass der gewünschte Zustand (Chart-Version, Werte, Mandanten-Konfiguration) im Ziel-Cluster eingehalten wird.
• Rollouts, Rollbacks und Progressive Delivery lassen sich nachvollziehbar und sicher steuern.

GitOps bringt mehrere Compliance-Vorteile:

• Jede Änderung an der Live-Umgebung ist ein Git-Commit – inklusive Autor, Review und Pipeline-Historie.
• Der Cluster-Zustand kann jederzeit gegen Git „verglichen“ werden. Drift wird erkannt und optional automatisch korrigiert.
• Für DORA und NIS-2 bedeutet das: klare Governance, technische Change-Kontrolle und ein belastbarer Audit-Trail.

---

Schritt 7: Ingress, Zertifikate und Netzwerk-Sicherheit

Ihre Django-SaaS soll mandantenfähig, aber isoliert und sicher erreichbar sein. Drei Bausteine sind zentral:

1. Ingress & TLS mit Cert-Manager

   • Cert-Manager automatisiert Ausstellung und Erneuerung von TLS-Zertifikaten.
   • Mandantenspezifische Domains oder Subdomains werden mit sauberem TLS-Setup versehen.
   • Datenübertragung „in Transit“ ist abgesichert – ein Kernpunkt der GDPR.

2. Netzwerk-Sicherheit mit Cilium

   • Cilium setzt Network Policies, Mandantenisolation und L7-Awareness um.
   • Für Multi-Tenant-SaaS können Sie dafür sorgen, dass nur die notwendigen Services miteinander sprechen.
   • Das reduziert die laterale Bewegungsfreiheit bei Kompromittierungen – relevant für NIS-2 und CRA.

3. Mandantenseparierung auf Kubernetes-Ebene

   • Dedizierte Namespaces oder Labels je Mandant oder Mandantengruppe.
   • RBAC-Regeln, die sicherstellen, dass Operations-Teams nur den wirklich benötigten Zugriff haben.

Damit verankern Sie „Least Privilege“ in der Plattform – ein Prinzip, das sich durch alle einschlägigen Regulierungen zieht.

---

Schritt 8: Observability und Alerting mit VictoriaMetrics und Logs

Mit dem Deployment allein ist es natürlich nicht getan. Für Resilienz- und Reportingpflichten aus NIS-2 und DORA brauchen Sie belastbare Observability.

In der ayedo SDP übernehmen etwa folgende Komponenten:

• VictoriaMetrics als performante Zeitreihen-Datenbank für Metriken.
• Zentrale Log-Pipeline (zum Beispiel Loki oder Elastic-Stack, je nach Plattformprofil), die Application-, Infrastruktur- und Audit-Logs aggregiert.
• Dashboards in Grafana zur Visualisierung von Anwendungs-SLIs (Verfügbarkeit, Latenz, Fehlerraten) und Infrastrukturzustand.

Aufbauend darauf:

• Alerting-Regeln, die kritische Schwellenwerte, SLA-Verletzungen und Security-Anomalien erfassen.
• Eskalationsketten, die sich mit Ihren Incident-Response-Prozessen verzahnen.

Für CRA, NIS-2 und DORA ist das entscheidend: Sie können Vorfälle erkennen, bewerten, dokumentieren und fristgerecht melden.

---

Schritt 9: Backups und Disaster Recovery mit Velero

Regulatorisch wird nicht nur Operations gefragt, sondern auch Resilienz und Wiederherstellbarkeit:

• Velero übernimmt Cluster-Backups inklusive Persistent Volumes.
• Sie definieren Backup-Policies für Namespaces, Mandanten-Daten oder komplette Umgebungen.
• Wiederherstellungstests werden als regulärer Teil Ihres Betriebsprozesses etabliert.

So können Sie im Ernstfall:

• Einzelne Mandanten-Datenräume wiederherstellen.
• Komplette Umgebungen nach einem Infrastrukturvorfall auf einer neuen Kubernetes-Instanz hochziehen.
• Nachweisen, dass Backup- und Restore-Konzepte tatsächlich funktionieren – ein wichtiger Punkt für NIS-2 und DORA.

---

Schritt 10: Compliance-Check – GDPR, NIS-2, DORA, CRA, Data Act, Cloud-Souveränität

Fassen wir zusammen, wie der Workflow die regulatorischen Anforderungen adressiert:

• GDPR:

  • Datenminimierung und Zweckbindung durch klare Mandantentrennung und strukturierte Datenflüsse.
  • Technische und organisatorische Maßnahmen: Verschlüsselung (Cert-Manager, Datenbank-Setup), Zugriffskontrolle (RBAC, Vault, Cilium), Audit-Trails (GitLab, ArgoCD, Logging).
  • Unterstützung bei Betroffenenrechten durch klare Isolation und Wiederherstellbarkeit.

• NIS-2:

  • Security-by-Design in der Plattform: Network Policies, Secrets-Management, Vulnerability-Scans, regelmäßige Patches.
  • Incident Detection und Response dank Observability-Stack und Alerting.
  • Nachweisbare Prozesse in Deployment, Change-Management und Backup.

• DORA:

  • Strukturiertes ICT-Risikomanagement durch GitOps, CI/CD-Governance und testbare Recovery-Szenarien.
  • Vendor- und Third-Party-Management wird durch offene, standardbasierte Komponenten erleichtert.
  • Reporting und Auditierung werden durch Logs, Dashboards und Git-/ArgoCD-Historie unterstützt.

• Cyber Resilience Act:

  • Dokumentierter Secure-Development-Lifecycle (Tests, Scans, Reviews).
  • Klare Verantwortlichkeiten für Patches und Updates via CI/CD-Pipeline.
  • Transparenz über eingesetzte Open-Source-Komponenten und Container-Images.

• Data Act:

  • Datenportabilität durch standardisierte Schnittstellen der Plattform und Mandantendaten, die nicht proprietär weggeschlossen sind.
  • Interoperabilität durch offene Protokolle und offene Plattformkomponenten.
  • Klarheit über Datenlokalität und -zugriff über Observability- und Logging-Lösungen.

• Cloud-Souveränität:

  • Betrieb der ayedo SDP in europäischen Rechenzentren mit klaren Datenlokalitätsprinzipien.
  • Einsatz von Open-Source-Bausteinen wie Kubernetes, Harbor, Vault, ArgoCD, Cilium, VictoriaMetrics und Velero minimiert Lock-In.
  • Volle Kontrolle über Deployment-Artefakte, Secrets und Netzwerkpfade – ein starkes Signal gegenüber Kunden, Aufsichtsbehörden und Auditoren.

Damit entsteht ein konsistenter End-to-End-Workflow: nicht nur „Production-ready“, sondern „Production-ready UND compliance-orientiert“.

---

Häufige Fragen

Wie aufwendig ist die Umstellung auf diesen Workflow, wenn wir bereits CI/CD haben?

In vielen Organisationen existieren bereits CI/CD-Pipelines, jedoch oft ohne klaren GitOps-Ansatz, ohne zentrales Secrets-Management oder ohne integrierte Observability.
Die Umstellung verläuft meist in Schritten:

1. Aufnahme des Status quo: Wo liegen Images, wie werden Secrets gehandhabt, wie erfolgt Deployment?
2. Einführung von Harbor und Vault als zentrale Ankerpunkte.
3. Schrittweise Migration des Deployments auf ArgoCD und Helm/ohMyHelm.
4. Ergänzung von Observability, Alerting und Backup.

Der Mehrwert entsteht schnell: transparentere Prozesse, bessere Auditierbarkeit und eine spürbare Entlastung des Teams, weil viele „Sonderfälle“ in standardisierte Wege überführt werden.

Wie unterstützt dieser Ansatz konkret bei Mandantentrennung und Datensicherheit?

Multi-Tenancy ist nicht nur ein Architekturthema, sondern auch ein Compliance-Thema:

• Auf Datenebene: getrennte Datenbanken oder Schemas, strenge Authorisierung im Django-Code, unterstützende Policies in Vault.
• Auf Plattformebene: Namespaces, Network Policies mit Cilium, feingranulare RBAC-Regeln.
• Auf Betriebs- und Compliance-Ebene: Logs und Metriken je Mandantengruppe, dokumentierte Zugriffspfade, definierte Backup- und Restore-Szenarien pro Mandant.

Diese Trennung lässt sich im Audit nachvollziehbar zeigen – ein wesentlicher Punkt für GDPR und NIS-2.

Welche Rolle spielt ayedo, und was bleibt in der Verantwortung meines Teams?

Die ayedo SDP liefert:

• Die vorkonfigurierte Plattform mit GitLab, Harbor, Vault, ArgoCD, Observability- und Backup-Stack.
• Guardrails, Best Practices und Templates (z. B. via ohMyHelm), die Compliance-Anforderungen strukturiert abbilden.
• Unterstützung bei Architektur-Workshops, Onboarding und der schrittweisen Umsetzung – inklusive End-to-End-Demos.

Ihr Team behält die Verantwortung für:

• Fachliche Architektur der Django-Anwendung und Mandantenlogik.
• Definition von SLAs, internen Prozessen und Governance-Vorgaben.
• Operative Entscheidungen, welche Risiken akzeptiert oder weiter mitigiert werden.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Ein End-to-End-Workflow wie in diesem Beispiel ist mehr als eine technische Spielerei. Er ist eine Antwort auf eine sehr reale Situation: europäische Software-Unternehmen, die hochwertige Produkte bauen und zugleich eine wachsende Zahl an regulatorischen Anforderungen verantwortungsvoll erfüllen wollen.

Die ayedo Software Delivery Platform bündelt genau die Bausteine, die dafür nötig sind:

• Eine konsistente, Kubernetes-basierte Plattform, in der GitLab, Harbor, Vault, ArgoCD, Cilium, VictoriaMetrics und Velero zusammenspielen.
• Guardrails und Best Practices, die Ihre Teams anleiten, Services wie Ihre Django-Multi-Tenant-SaaS von Anfang an „compliance-aware“ zu designen.
• Ein Betriebsmodell, das Cloud-Souveränität ernst nimmt: europäische Infrastruktur, offene Komponenten, transparente Lieferketten.

In der Praxis bedeutet das: Sie müssen nicht jede Komponente selbst evaluieren, integrieren und auditfest dokumentieren. Stattdessen arbeiten Sie mit einem kuratierten Stack, der bereits auf die relevanten Normen wie GDPR, NIS-2, DORA, Cyber Resilience Act und Data Act ausgerichtet ist – und passen diesen Stack an die Besonderheiten Ihres Geschäftsmodells an.

Der beste Weg, diesen Ansatz zu bewerten, ist eine konkrete End-to-End-Demonstration an Ihrer eigenen Anwendung oder einem repräsentativen Beispiel. Genau dabei unterstützen wir Sie: von der gemeinsamen Analyse über die Einrichtung der Pipeline bis zur produktionsnahen Demo, die Sie intern wie extern präsentieren können.

End-to-End Demo