Reliable operations
for your software stack
Leading companies trust our technology ↘
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 .
Platform Cluster
Infrastructure · ayedo Cloud
Substrate under every workspace · Compute Cloud · Edge Cloud · Dedicated · BYOC / On-Premises — distinct from SDP blocks above
Platform · SDP (Polycrate)
Workload workspace
Blocks (Apps)
Workload Cluster
On Managed Kubernetes
, your business applications
and managed apps
run in production. ayedo operates the clusters; Workload Clusters consume the central platform services of your operating model.
Workloads
Apps
Three operating models
All operating models use the same SDP building blocks – they differ in isolation, infrastructure, and pricing tier.
ayedo Cloud
Multi-tenant · ayedo accounts
- ✓ 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
Single-tenant · operated by ayedo
- ✓ 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
Your infrastructure
- ✓ 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.
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.
Cluster
Compute
Identity
ayedo ID authenticates you to all ayedo Cloud services – in the Dedicated model, you receive your own Keycloak instance.
Keycloak
ayedo ID
Code & CI/CD
GitLab provides your repositories and CI/CD pipelines on sovereign infrastructure.
GitLab
CI/CD
Delivery
Argo CD delivers your applications to workload clusters via GitOps – ayedo operates the control plane; your teams deploy declaratively.
Argo CD
GitOps
Container Registry
Harbor manages your OCI images – including vulnerability scanning and signing.
Harbor
OCI
Secrets
OpenBao manages your secrets, PKI, and encryption-as-a-service – centrally and auditably.
OpenBao
ESO
Observability
VictoriaMetrics, VictoriaLogs, traces, and Grafana provide visibility into the availability of your systems and help you detect issues early.
Metrics
Logs
Traces
App Hosting
We operate catalog apps and custom business applications for you – managed on workload clusters.
Apps
Business apps
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 Kubernetes features .
Cilium
Cilium provides eBPF-based networking, network policies, and observability – the cluster network of the SDP.
CNI
eBPF
Policies
Kyverno
Kyverno implements policy-as-code: guardrails for images, resources, privileges, and best practices.
Policy
Guardrails
Cert-Manager
Cert-Manager automatically issues TLS certificates for ingress and internal PKI workflows.
TLS
PKI
Velero
Velero backs up your clusters to S3-compatible object storage and restores them when needed – the foundation for disaster recovery.
Backup
DR
External Secrets
External Secrets synchronizes secrets from OpenBao into your workload clusters – without credentials in Git.
ESO
OpenBao
Ingress & TLS
Ingress handles routing and TLS termination for your applications and the platform interfaces.
Ingress
TLS
You build it. We run it.
Excellent performance and maximum uptime - that’s what we wake up for. And sometimes even in the middle of the night.
100+ Clusters
under management
We operate more than 100 Kubernetes clusters in production for our customers.
300+ Databases
under management
We operate, monitor, and back up more than 300 databases in production.
1 Petabyte Object Storage
under management
We operate one petabyte of object storage for backups, artifacts, and application data.
100 Million Timeseries
on average
4 million datapoints per second are ingested by our monitoring systems.
38,000+ Logs
per second
Our collectors continuously ingest logs and store them in a GDPR-compliant way – more than 100 billion entries per month.
5,000+ Backups
per day
We secure more than 5,000 backups every day on encrypted long-term storage – around 150 terabytes of backup volume per month.
270 Million End Users
per month
More than 9 million end users use software we deploy every day, on the internet or on-premise.
99.99% Uptime
annual average
Our managed services are unavailable for less than 1 hour per year on average.
MTTD < 5 Minutes
on average
Our alerting typically detects errors and outages within a few minutes.
Compliance & Regulatory Requirements
The ayedo Software Delivery Platform meets the requirements of current EU regulations. From GDPR to NIS-2 to DORA – our platform is designed for regulated industries and critical infrastructures.
GDPR-Compliant Data Processing
Privacy by Design & Default.
EU data residency (Germany), Customer-Managed Keys (BYOK/BYOHSM), encryption at rest/in transit. ISO 27001-certified data protection management. Support for data subject rights, DPA, incident response. More about GDPR
.
NIS-2-Compliant Operations
Resilience for critical infrastructures.
24/7 monitoring, incident response, BCP/DR processes, supply chain transparency (SBOM). EU-based operations, MFA/PAM, vulnerability management, patch processes. Ideal for essential/important entities. More about NIS-2
.
DORA-Ready for Financial Institutions
ICT resilience tailored.
ICT risk management framework, documented exit strategies, third-party risk management, TLPT readiness. Structured incident reporting chains, continuous resilience testing, ISO 27001-certified. More about DORA
.
CRA-Compliant Software Supply Chain
Security by Design across the entire lifecycle.
SBOM generation, CVE scanning, vulnerability disclosure processes, update management. Signed container images, GitOps-based audit trails, transparent supply chain. More about CRA
.
Cloud Sovereignty Framework
Digital sovereignty made measurable.
EU-based operations, open standards, exit capability without lock-in. Designed for SEAL-4 (Full Digital Sovereignty) across all eight sovereignty objectives. No dependencies on non-EU control. More about the Framework
.
Data Act-Compliant Portability
Switching without barriers.
Open APIs (OpenAPI), standardized formats (YAML/JSON/OCI), complete exit runbooks, Infrastructure-as-Code portability. Multi-cloud capable, no egress fees, functional equivalence. More about Data Act
.
Integrated Compliance Roadmap
Holistic approach.
How ayedo systematically addresses GDPR, NIS-2, DORA, CRA, Data Act, Cloud Sovereignty Framework, ISO 27001/9001. Certifications, processes, technical measures, audit readiness. To overview
.
Reference sizing
Baseline figures for typical setups – the final sizing depends on your workload profile.
Workload cluster
4–10 workers
Each worker typically provides 8 cores / 32 GB RAM for standard business applications.
4–10 workers
8C/32GB
Platform Cluster
4 workers × 8C / 32GB
One platform cluster serves up to 5 workload clusters. Plan for +3 workers for every additional five workload clusters.
Platform services
Scaling
At least 4 workers
Production readiness
Three replicas with PDBs and anti-affinity need room for a fourth replica during rolling updates (e.g. CloudNativePG) – hence at least 4 workers.
HA
PDB
Updates
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
.
