Reliable operations
for your software stack
Certified hosting for cloud-native software: the ayedo Software Delivery Platform (SDP) makes operations predictable – Platform Clusters for platform services, Workload Clusters for your applications. ayedo takes over the operations lifecycle in ayedo Cloud, Dedicated, or BYOC/On-Premises.
What is the Software Delivery Platform?
You build it. We run it. The SDP combines Managed Kubernetes, Identity, CI/CD, GitOps, registry, secrets, and observability on platform and workload clusters. The underlying ayedo Cloud (Compute Cloud, Edge Cloud, shared services) provides infrastructure and multi-tenant services – documented at docs.ayedo.de.
Three operating models
All operating models use the same SDP building blocks – they differ in isolation, infrastructure, and pricing tier.
ayedo Cloud
You use central shared instances of ayedo ID, GitLab, Argo CD, Harbor, OpenBao, Grafana, and further services.
Your environment is cleanly isolated via tenants.
Managed Kubernetes is available across many regions and providers – compute runs on ayedo accounts.
You get started quickly with minimal operational effort.
Dedicated
You receive your own Platform Cluster, exclusively for your organization.
All SDP apps run as dedicated instances.
You benefit from higher isolation and custom SLAs.
This model is particularly suited to regulated environments.
BYOC / On-Premises
BYOC: you provide your own cloud account or infrastructure provider.
On-premises: the same model runs in your own data center.
Air-gapped environments and enterprise requirements are supported.
Please review the technical prerequisites – see the FAQ below.
Ship software to enterprise buyers
When ayedo should not operate the site – you or your buyer will: a reusable package, not only managed BYOC. Compare enablement and operations under Ship software to enterprise customers.
Enablement
Workspace template, primitives, air-gap bundle, runbooks and update trains – your team runs the sites.
Managed on buyer Kubernetes
The buyer provides Kubernetes; ayedo runs Day-2 for your application. Often faster when you have few sites.
SDP building blocks
Each building block has its own detail page. The SDP is the product – offered as ayedo Cloud, Dedicated, or BYOC/On-Premises. ayedo ID authenticates your users to the ayedo Cloud services.
Managed Kubernetes
Your clusters run in ayedo Cloud, Dedicated, or BYOC/On-Premises – ayedo manages the control plane and operations.
Identity
ayedo ID authenticates you to all ayedo Cloud services – in the Dedicated model, you receive your own Keycloak instance.
Code & CI/CD
GitLab provides your repositories and CI/CD pipelines on sovereign infrastructure.
Delivery
Argo CD delivers your applications to workload clusters via GitOps – ayedo operates the control plane; your teams deploy declaratively.
Container Registry
Harbor manages your OCI images – including vulnerability scanning and signing.
Secrets
OpenBao manages your secrets, PKI, and encryption-as-a-service – centrally and auditably.
Observability
VictoriaMetrics, VictoriaLogs, traces, and Grafana provide visibility into the availability of your systems and help you detect issues early.
App Hosting
We operate catalog apps and custom business applications for you – managed on workload clusters.
Cluster foundation
These baseline services run in every cluster. They rarely take center stage, but they are essential for safe operations. You can find the details in the SDP components & features.
Cilium
Cilium provides eBPF-based networking, network policies, and observability – the cluster network of the SDP.
Kyverno
Kyverno implements policy-as-code: guardrails for images, resources, privileges, and best practices.
Cert-Manager
Cert-Manager automatically issues TLS certificates for ingress and internal PKI workflows.
Velero
Velero backs up your clusters to S3-compatible object storage and restores them when needed – the foundation for disaster recovery.
External Secrets
External Secrets synchronizes secrets from OpenBao into your workload clusters – without credentials in Git.
Ingress & TLS
Ingress handles routing and TLS termination for your applications and the platform interfaces.
Excellent performance and maximum uptime - that's what we wake up for. And sometimes even in the middle of the night.
100+ clusters
We operate more than 100 Kubernetes clusters in production for our customers.
300+ databases
We operate, monitor, and protect more than 300 production databases.
1 Petabyte Object-Storage
We operate one petabyte of object storage for backups, artifacts, and application data.
100 million timeseries
Our monitoring systems ingest 4 million datapoints per second.
38.000+ Logs
Our collectors capture logs continuously and store them GDPR-compliant — over 100 billion entries per month.
5.000+ Backups
We write more than 5,000 backups every day to encrypted long-term storage — about 150 terabytes of backup volume per month.
270 million end users
More than 9 million end users use software we operate every day, on the internet or on-premises.
99,99% Uptime
Our managed services are unavailable for less than one hour per year on average.
MTTD < 5 minutes
Our alerting typically detects faults and outages within a few minutes.
Die ayedo Software Delivery Platform erfüllt die Anforderungen aktueller EU-Verordnungen. Von GDPR über NIS-2 bis DORA – designed für regulierte Branchen und kritische Infrastrukturen.
GDPR-konforme Datenverarbeitung
EU-Datenhaltung (Deutschland), Customer-Managed Keys (BYOK/BYOHSM), Verschlüsselung at rest/in transit. ISO 27001-zertifiziertes Datenschutz-Management. Mehr zur GDPR.
NIS-2-konformer Betrieb
24/7 Monitoring, Incident-Response, BCP/DR-Prozesse, Supply-Chain-Transparenz (SBOM). Mehr zu NIS-2.
DORA-ready für Finanzinstitute
IKT-Risikomanagement, dokumentierte Exit-Strategien, Drittpartei-Risiko-Management, TLPT-Readiness. Mehr zu DORA.
CRA-konforme Software Supply Chain
SBOM-Generation, CVE-Scanning, signierte Container-Images, GitOps-basierte Audit-Trails. Mehr zum CRA.
Cloud Sovereignty Framework
EU-basierte Operations, offene Standards, Exit-Fähigkeit ohne Lock-in. Mehr zum Framework.
Data Act-konforme Portabilität
Offene APIs, standardisierte Formate, vollständige Exit-Runbooks. Mehr zum Data Act.
Integrierte Compliance-Roadmap
Wie ayedo GDPR, NIS-2, DORA, CRA, Data Act und ISO 27001/9001 systematisch adressiert. Zur Übersicht.
Reference sizing
Baseline figures for typical setups – the final sizing depends on your workload profile.
Workload cluster
Each worker typically provides 8 cores / 32 GB RAM for standard business applications.
Platform Cluster
One platform cluster serves up to 5 workload clusters. Plan for +3 workers for every additional five workload clusters.
At least 4 workers
Three replicas with PDBs and anti-affinity need room for a fourth replica during rolling updates (e.g. CloudNativePG) – hence at least 4 workers.
Frequently asked questions
Essential prerequisites and exclusion criteria for running the SDP – especially relevant for BYOC and on-premises. You can find more depth at docs.ayedo.de.
What is the difference between ayedo Cloud, Dedicated, and BYOC?
The Software Delivery Platform (SDP) is the product. In ayedo Cloud, you use multi-tenant ayedo Cloud services (including ayedo ID); compute runs on ayedo accounts across many regions. In the Dedicated model, you receive your own platform cluster with dedicated platform services, operated by ayedo. With BYOC / On-Premises, you provide the infrastructure – a cloud account or your own data center – and ayedo runs the SDP on it. BYOC and on-premises represent the same operating tier.
Why separate platform and workload clusters?
Platform services such as Keycloak, Harbor, GitLab, Argo CD, OpenBao, and observability are central shared services. Your business applications run in workload clusters and consume those services. This keeps blast radius, sizing, and updates cleanly decoupled.
Why no NFS- or SMB-backed VMs / CSI storage?
NFS or SMB as a backend for node disks or CSI volumes is slow and fragile. Distributed storage such as Longhorn compounds the problem, for example through slow database fsyncs. For bare metal, locally attached disks are mandatory; Ceph is preferred over Longhorn – with a proper disk layout and ideally at least 10 Gbit/s networking.
Why at least 4 workers?
Many data-bearing applications run with three replicas plus anti-affinity and PodDisruptionBudgets. Rolling updates often start a fourth replica. With only three workers, the PodDisruptionBudget can block the update – a typical example is CloudNativePG.
What network prerequisites apply for BYOC/on-prem?
You need a stable underlay, ARP-capable floating IPs or VIPs, and ideally BGP. In addition, plan for predictable pod and service CIDRs, working node-to-node communication, and reliable DNS and NTP. Allowing “port 443 only” without a plan for cluster traffic and image pulls is not viable – except in a true air-gapped environment with a registry mirror.
Do we need separate object storage?
Yes. Velero and backup pipelines require S3-compatible object storage in addition to the node disks. Backups on the same NFS or local storage do not constitute disaster recovery.
Why does cloud-native often look more expensive than my old root server?
Idiomatic patterns such as 15-Factor and isolation per application and database create more pods, volumes, and headroom – in exchange, you get high availability and clearly bounded blast radii. Providers also often enforce minimum volume sizes (e.g. 10 GB). Profile your workloads early; see 15-Factor App.
Platform Cluster
