From Zero to Production: The Complete ayedo SDP Workflow in an Example

TL;DR

• Starting point is a multi-tenant Django SaaS application, which is taken from the first line of code to production operation on the ayedo Software Delivery Platform (SDP).
• The workflow follows a clear path: GitLab repository → Packaging with ohMyHelm → GitLab CI/CD → Container and Chart Registry in Harbor → Secrets in Vault via External Secrets Operator → GitOps deployment with ArgoCD on Kubernetes → TLS with Cert-Manager → Network security with Cilium → Observability with VictoriaMetrics and central logs → Alerting → Backups and disaster recovery with Velero.
• Along this path, the requirements from GDPR, NIS-2, DORA, Cyber Resilience Act, Data Act, and European cloud sovereignty are systematically addressed: data minimization, traceability, security-by-design, resilience, and portability.
• Result: A production-ready, observable, and hardened platform solution for multi-tenant SaaS, technically and organizationally prepared for European regulation.
• ayedo provides a pre-configured, auditable platform with the SDP and supports teams with architecture, implementation, and end-to-end demos so that this workflow is not theoretical but can be productively used in your own company.

The Scenario: Bringing a European Django SaaS to Production

Imagine you are responsible for a multi-tenant Django SaaS product for companies in regulated industries: personal data, business-critical workflows, demanding customer audits. The application must run tenant-secure, highly available, and auditable – ideally on a European, sovereign platform.

Regulatory you are navigating the tension between:

• GDPR since 25.05.2018
• NIS-2, applicable from 18.10.2024
• DORA for financial and ICT service providers from 17.01.2025
• Cyber Resilience Act (CRA), whose core obligations for software and digital product manufacturers become effective successively
• Data Act, which has been gradually applied since 11.01.2024

You do not want to implement every standard in detail, but rather a platform that structurally maps these requirements. This is exactly what we achieve with an integrated workflow on the ayedo SDP – from Git commit to productive, observable service.

Step 1: Consciously Set Architecture and Compliance Goals

Before we look at tools, the target architecture is crucial. For our Django multi-tenant SaaS, we define:

• Multi-Tenancy Strategy:
  For example, tenant separation at the database schema level or separate databases per tenant, complemented by strict authorization in the code and network segmentation in the cluster.
• Security Goals:
  Encryption in transit and at rest, minimal attack surface, hardened supply chain, secrets consistently banned from the code.
• Operational Goals:
  GitOps-supported deployments, reproducible releases, automated rollbacks, observability as a first-class citizen.
• Compliance Goals:
  Traceable changes (audit trail via GitLab and ArgoCD), controlled access (RBAC), documented data flows, and clear responsibility allocation – all elements central to GDPR, NIS-2, and DORA.

The ayedo SDP provides a pre-configured platform based on Kubernetes, including GitLab, Harbor, Vault, ArgoCD, observability stack, and backup solutions. We will build on this in the following.

Step 2: From Django Code to ohMyHelm Package

The journey begins in the GitLab repository of your Django application:

• Source code of the Django app, including tenant logic and configuration.
• Infrastructure-as-config at the application level via Helm chart, generated and managed with ohMyHelm.
• Policies and guardrails that ensure your deployments adhere to platform standards (resource limits, probes, SecurityContext, labels for auditing).

ohMyHelm structures the application part of your platform configuration:

• Standardized chart structure for all services.
• Guidelines for logging, metrics, and health checks.
• Pre-configured hooks to source secrets and ConfigMaps exclusively through Vault and the External Secrets Operator – an important component for security-by-design in the sense of the Cyber Resilience Act.

This creates a reproducible deployable artifact: the application chart, which will later be consumed by ArgoCD.

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

The GitLab CI/CD pipeline translates commits into verified, deployable artifacts:

1. Tests and Quality Assurance

   • Unit and integration tests for Django.
   • Linting and static analysis, including security checks of dependencies.
   • Optional: SCA and container security scans as separate pipeline jobs.

   These steps directly contribute to CRA and NIS-2 requirements: documented security tests, traceable build pipelines, reproducible builds.

2. Container Build

   • Container image build with Kaniko or Buildah, i.e., daemonless and rootless.
   • Clear tagging strategy (commit SHA, Semver) to uniquely trace each deployment version.

3. Chart Packaging

   • Versioning of the Helm chart according to the app version.
   • Packaging into an OCI-compatible chart archive, which will later be provided in Harbor.

The pipeline thus maps your “software delivery process” – a central aspect of DORA and CRA: traceable, repeatable, verifiable.

Step 4: Images and Charts in Harbor – Your Single Source of Truth

Harbor acts as a central registry for:

• Container images of your Django app and sidecars.
• OCI-based Helm charts.
• Optional: SBOMs and scan results.

Typical features that are particularly valuable in the compliance context:

• Project-based access control and audit logs.
• Integrated vulnerability scans.
• Replication to other registries or regions if necessary.

For GDPR and Data Act, Harbor is especially relevant for two reasons:

• Transparency in the software supply chain: You can always trace which components are used where.
• Data locality: Operation in European data centers supports a sovereign, EU-centered platform strategy.

Step 5: Database and Secrets with Vault and External Secrets Operator

Your Django tenants need databases, credentials, API keys, and configurations – but not as plain text in Git or the CI log.

Here, Vault takes on the role of the central secrets authority:

• PostgreSQL credentials and tenant databases are automatically provisioned.
• Rotate policies ensure secrets are regularly renewed.
• Access is finely controlled via policies.

The External Secrets Operator (ESO):

• Synchronizes secrets from Vault into the namespaces of your application deployments.
• Creates Kubernetes secrets without developers having to deal directly with Vault.
• Keeps secrets up-to-date without redeploying the application.

This separation is a strong argument in audits according to GDPR and NIS-2:
Access to production secrets is clearly regulated, documented, and technically enforced.

Step 6: GitOps with ArgoCD – From Chart to Running Service

With ArgoCD, the workflow connects:

• An ArgoCD application references the Git repository or the Helm chart definition.
• ArgoCD ensures that the desired state (chart version, values, tenant configuration) is maintained in the target cluster.
• Rollouts, rollbacks, and progressive delivery can be managed in a traceable and secure manner.

GitOps brings several compliance advantages:

• Every change to the live environment is a Git commit – including author, review, and pipeline history.
• The cluster state can always be “compared” against Git. Drift is detected and optionally automatically corrected.
• For DORA and NIS-2, this means: clear governance, technical change control, and a robust audit trail.

Step 7: Ingress, Certificates, and Network Security

Your Django SaaS should be tenant-capable but isolated and securely accessible. Three components are central:

1. Ingress & TLS with Cert-Manager

   • Cert-Manager automates issuance and renewal of TLS certificates.
   • Tenant-specific domains or subdomains are provided with a clean TLS setup.
   • Data transmission “in transit” is secured – a core point of the GDPR.

2. Network Security with Cilium

   • Cilium implements network policies, tenant isolation, and L7 awareness.
   • For multi-tenant SaaS, you can ensure that only the necessary services communicate with each other.
   • This reduces lateral movement in case of compromises – relevant for NIS-2 and CRA.

3. Tenant Separation at the Kubernetes Level

   • Dedicated namespaces or labels per tenant or tenant group.
   • RBAC rules that ensure operations teams only have the access they truly need.

This anchors “least privilege” in the platform – a principle that runs through all relevant regulations.

Step 8: Observability and Alerting with VictoriaMetrics and Logs

Deployment alone is, of course, not enough. For resilience and reporting obligations from NIS-2 and DORA, you need reliable observability.

In the ayedo SDP, components such as:

• VictoriaMetrics as a high-performance time-series database for metrics.
• Central log pipeline (e.g., Loki or Elastic Stack, depending on the platform profile) that aggregates application, infrastructure, and audit logs.
• Dashboards in Grafana to visualize application SLIs (availability, latency, error rates) and infrastructure status.

Building on this:

• Alerting rules that capture critical thresholds, SLA violations, and security anomalies.
• Escalation chains that integrate with your incident response processes.

For CRA, NIS-2, and DORA, this is crucial: You can detect, assess, document, and report incidents in a timely manner.

Step 9: Backups and Disaster Recovery with Velero

Regulatory requirements are not only about operations but also resilience and recoverability:

• Velero handles cluster backups, including persistent volumes.
• You define backup policies for namespaces, tenant data, or entire environments.
• Recovery tests are established as a regular part of your operational process.

So in the event of a disaster:

• Restore individual tenant data spaces.
• Rebuild entire environments on a new Kubernetes instance after an infrastructure incident.
• Prove that backup and restore concepts actually work – an important point for NIS-2 and DORA.

Step 10: Compliance Check – GDPR, NIS-2, DORA, CRA, Data Act, Cloud Sovereignty

Let’s summarize how the workflow addresses regulatory requirements:

• GDPR:
  • Data minimization and purpose limitation are …