Catalog or custom app
Two paths
20+ apps from the managed apps catalog or your custom software via bring-your-own-app – same operations platform.
App Hosting in
Kubernetes
Let experts run your cloud-native business application. On European infrastructure, with a 99.9% availability guarantee.
Made in Germany
ISO 27001
ISO 9001
DSGVO-konform
DORA Compliant
24/7 Support
Software operations like from the factory
Your application runs in production on Kubernetes in Europe – we handle infrastructure, operations, and the operational framework. You provide code or pick a catalog app; we ensure availability, scaling, and compliance.
Kubernetes foundation
Production-ready base
Managed Kubernetes hosting from Germany with Cilium, CSI, ingress, WAF, and integrated monitoring.
Fully managed
Operations included
Updates, backups, alerts, endpoint monitoring, and 24/7 support – you focus on product development.
How we do it
From platform to support – book modularly or as a package. Each layer builds on the previous one.
Platform
Managed Kubernetes
Cluster, networking, storage, ingress, and certificates – production-ready in Germany.
Add-ons
Catalog apps
Proven tools from the managed apps catalog – installed, updated, and operated for you.
Line-of-business app
GitOps with Argo CD
Delivery of your custom software – controlled releases from staging to production.
Observability
Observability
Metrics, logs, traces, and endpoint checks – alerts and runbooks included.
Onboarding
Your team ready to go
Access, tools, and deployment workflows – we onboard you to GitLab, Argo CD, and day-to-day operations.
Support
Expert support
Defined response times, optional 24/7 – when it matters, we are there.
Added Value
Edge services, storage, and tooling around your app hosting – book modularly on sovereign infrastructure.
Endpoint Monitoring
We monitor your endpoints every minute from our edge cloud.
Anycast DNS
Multi-region DNS with anycast routing on our own infrastructure – fast, resilient, and sovereign.
Anycast Load Balancing
EU-wide TCP load balancing (Layer 4) with anycast routing and our own AS – Made in Germany.
S3 Storage
S3-compatible object storage on European infrastructure – for backups, app data, and archives.
Container Registry
Private container registry for your images – secure, performant, and seamlessly integrated with Kubernetes.
Code Repository
Managed GitLab for source code, CI/CD, and DevSecOps – repositories and pipelines on sovereign infrastructure.
Secrets Management
Managed OpenBao for secrets, certificates, and dynamic credentials – centralized and auditable.
Delivery
Get your app reliably to customers – managed Argo CD for GitOps in your Kubernetes clusters.
Backups
Automated backups for Kubernetes, apps, and data – with tested recovery and EU storage.
Cloud + IaaS
Our technologies and products are available at numerous locations across Europe and on-premises.
Reasons to Work with Us
ayedo's technologies and services enable you to run your SaaS solution without your own DevOps team. You develop software, we handle operations on infrastructure of your choice.
100% Cost-Effective
Our managed services and individual support from our platform team provide the value of a 3-person DevOps team.
24/7 Available
Our priority support provides around-the-clock care for your critical services. Including weekends and holidays.
90% Less Operations
We handle operations so you can develop. Optionally including packaging, pipelines, monitoring, and backups.
Dual-Certified Security
Our managed services are ISO9001 and ISO27001 certified and secured according to BSI standards.
70% Faster MTTR
Our 360° observability and intelligent forecasting enable proactive discovery and remediation of errors and real-time incident response.
100% Compliant
We offer to run your software on certified infrastructure using auditable methods, so you're always compliant.
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 protect more than 300 production databases.
1 Petabyte Object-Storage
under Management
We operate one petabyte of object storage for backups, artifacts, and application data.
100 million timeseries
on average
Our monitoring systems ingest 4 million datapoints per second.
38.000+ Logs
per second
Our collectors capture logs continuously and store them GDPR-compliant — over 100 billion entries per month.
5.000+ Backups
per day
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
per month
More than 9 million end users use software we operate every day, on the internet or on-premises.
99,99% Uptime
annual average
Our managed services are unavailable for less than one hour per year on average.
MTTD < 5 minutes
on average
Our alerting typically detects faults and outages within a few minutes.
We Work with Digital Pioneers
Companies from various industries across the European Economic Area rely on our technologies and services to operate their software-as-a-service products.
What Can We Do for You?
ayedo offers certified solutions for operating container-based workloads according to cloud-native standards for companies with high requirements for availability, compliance, and sovereignty.
Operations platform
Operations platform for SaaS, demos, tenants, and releases – tooling and integration into your IT landscape.
Delivery
Get your app reliably to customers – GitOps with Argo CD on Kubernetes.
Full Coverage Insurance
We provide 24/7 incident resolution and support for our managed Kubernetes clusters and apps, with custom SLA available on request.
Edge Services
Access over 700 TLDs, multi-region DNS and load balancing, custom IP prefixes, and WAF & DDoS protection for your apps.
Convenience Services
Need European S3-compatible object storage? Mail gateways with good IP reputation? An alternative to Datadog?
Knowledge Transfer
Want to take the next step in your cloud-native journey? We'll guide you and give you access to over 15 years of operational experience.
Compliance & regulatorische Anforderungen
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
Privacy by Design & Default.
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
Resilienz für kritische Infrastrukturen.
24/7 Monitoring, Incident-Response, BCP/DR-Prozesse, Supply-Chain-Transparenz (SBOM). Mehr zu NIS-2.
DORA-ready für Finanzinstitute
IKT-Resilienz nach Maß.
IKT-Risikomanagement, dokumentierte Exit-Strategien, Drittpartei-Risiko-Management, TLPT-Readiness. Mehr zu DORA.
CRA-konforme Software Supply Chain
Security by Design über den gesamten Lifecycle.
SBOM-Generation, CVE-Scanning, signierte Container-Images, GitOps-basierte Audit-Trails. Mehr zum CRA.
Cloud Sovereignty Framework
Digitale Souveränität messbar gemacht.
EU-basierte Operations, offene Standards, Exit-Fähigkeit ohne Lock-in. Mehr zum Framework.
Data Act-konforme Portabilität
Switching ohne Hürden.
Offene APIs, standardisierte Formate, vollständige Exit-Runbooks. Mehr zum Data Act.
Integrierte Compliance-Roadmap
Ganzheitlicher Ansatz.
Wie ayedo GDPR, NIS-2, DORA, CRA, Data Act und ISO 27001/9001 systematisch adressiert. Zur Übersicht.
Digital Sovereignty Does Not End at the Data Center
An application can be fully operated in Germany and still rely on US infrastructure for every single access.
DNS, Routing, Anycast: Why Europe's Cloud Also Needs Its Own Edge
We recently introduced the ayedo Edge Cloud, a European edge infrastructure for DNS, Anycast, load balancing, web application firewall, DDoS protection, and controlled access to applications.
Building the Edge — Part 1
The more powerful our platforms have become, the simpler their architecture seems at first glance.
TLS Certificates for Public Kubernetes Endpoints
TLS for Kubernetes does not necessarily end at the Ingress. Central TLS termination at the ayedo Edge Cloud simplifies certificate management, WAF integration, and traffic control. However, additional encryption up to the cluster protects further network segments. The right decision depends on trust boundaries, operating model, compliance, and desired fault isolation.
DNS Automation for Kubernetes Behind the Edge Cloud
Kubernetes DNS and public name resolution address different challenges. Cluster resources are aware of services, ingresses, and workloads; the Edge Cloud manages public endpoints, DNS zones, and backend forwarding. A resilient operational model separates these responsibilities but automates their handovers through clearly defined interfaces.
Operating Load Balancers for Kubernetes Independently of Providers
A Kubernetes Service of type `LoadBalancer` often ties public access to the respective cloud or infrastructure provider. An independent edge layer separates this responsibility from the cluster: routing, protection, TLS, and accessibility are centrally organized, while Kubernetes can be operated at ayedo or another provider. This reduces provider dependencies and simplifies multi-cloud architectures.
Securely Accessing the Kubernetes API Server Over the Edge
A publicly accessible Kubernetes API server doesn't need to allow direct internet access to its backend address. A preceding edge layer can handle routing, TLS, DDoS protection, and backend cloaking. The key remains the separation between public accessibility, cryptographic authentication, and actual authorization within the cluster.
Ingress and Edge Cloud: Clearly Separating Responsibilities
Kubernetes Ingress and Edge Cloud serve different purposes. The Edge Cloud controls the public entry point, protects applications, and terminates TLS. In contrast, Kubernetes Ingress describes the routing within the cluster. A clear separation prevents duplicate rules, contradictory security configurations, and complex operational states.
Making Security Decisions at the Edge Transparent
Edge Security Monitoring reveals how protective measures impact public traffic. Traffic and usage statistics help operationally assess WAF rules, DDoS protection, and exposed endpoints. However, they do not fully explain individual attacks nor replace logs, traces, and application-centric security telemetry.
Multi-Cloud Security with Centralized Edge Architecture
Multi-Cloud Security often fails not due to a lack of protective features, but because of its distributed implementation. A centralized edge architecture consolidates public access, WAF, DDoS protection, TLS termination, and routing in front of heterogeneous backends. Provider independence, an autonomous system, and active-active operation reduce control and dependency points.
Integrating DDoS Protection with Application Logic at the Edge
DDoS protection and application security address different levels of attacks. The edge can assess volume, protocols, connection rates, and request patterns to discard malicious traffic early. However, whether a valid request is being misused can often only be determined in the application context. Effective protection combines both levels with clear responsibilities.
TLS, WAF, and Backend: A Layered Architecture
A robust **security layered architecture** distributes protection tasks across different levels: TLS secures the transport connection, the WAF evaluates HTTP requests, and the backend remains responsible for authorization, validation, and data protection. The critical points are the handover points between these layers. Each decryption, forwarding, and protocol conversion creates its own trust and operational requirements.
Distributing Security Functions Between Edge and Application
Security functions should not be confined to a single location. The edge is suitable for protective measures with high visibility, significant scaling needs, and standardizable rules. The application remains responsible for identity, authorization, and business access controls. Key factors include context requirements, misconfiguration risks, and how early an attack can be detected and mitigated.
Systematically Reducing Public Attack Surfaces
A public attack surface is not just created by individual vulnerabilities, but by the entire internet-exposed architecture. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination, and Backend Cloaking must therefore be considered as an interconnected security zone in front of the backends. The key is which traffic actually reaches the backends and under what conditions.
Architectural Planning for TLS Termination at the Edge
TLS termination at the edge shortens the path from client to protected entry point but shifts responsibilities. Certificates, trust boundaries, and backend connections must therefore be planned separately. The central question is not whether TLS ends at the public entrance, but which connections remain encrypted afterwards and how their identities are verified.
Backend Cloaking as a Component of Edge Security
Backend Cloaking reduces the direct public accessibility of origin services by preventing clients from communicating directly with the backends. This decreases the public attack surface but does not replace WAF rules or application protection. Key factors include clean routing, controlled backend access, and an operational model for health checks and failover.
DDoS Protection at the Edge and Its Limitations in the Backend
DDoS protection at the edge reduces volumetric and network-based attack pressure before it reaches a company's public infrastructure. Scrubbing thus protects the entry to applications and APIs. However, it does not replace backend security, authentication, resource limits, or domain-specific checks against misuse.
WAF at the Edge: Rules, Limits, and Operational Models
A WAF at the edge inspects HTTP and HTTPS requests before they reach backends. It is suitable for protocol and request-specific patterns like injection, unauthorized methods, or suspicious request structures. However, the application remains responsible for business context, logic, and complex authorization. A crucial operational model controls both protection effectiveness and false alarm risk.
Health Checks as the Foundation of Stable Traffic Paths
Health Checks in load balancing assess not only whether a backend network target is reachable. Crucially, they determine if the service can actually process requests. The results influence pool states, failover, and traffic management. Thus, Health Checks become the foundation for reliable backend selection and stable public access paths.
Controlling Traffic Paths with TLS and Proxy Protocol
A stable traffic path doesn't end at TLS termination. The key is the coordinated interaction of TLS endpoint, routing, backend selection, health checks, and Proxy Protocol. The edge determines the public connection path; the application must decide how to process transmitted client information and which protocol parameters it accepts.
L7 Routing for APIs: Rules, Pools, and Backends
L7 routing distributes API requests not just by IP address or port, but based on application characteristics. Path, hostname, HTTP method, or headers can direct to different backend pools. Clear rules, defined priorities, and a clean boundary between edge routing and internal application logic are crucial.
Anycast and Backend Failover in Active-Active Operations
Active-active failover is not achieved through a single mechanism but through the interplay of Anycast, distributed edge PoPs, robust health checks, and dynamic backend selection. When a backend fails, the edge must detect the state and distribute new connections to available backends without relying on a central primary path.
Separating Network Routing and Application Routing
Network routing and application routing solve different problems. Anycast and Layer 4 determine how traffic reaches an edge entry and to which transport destination it proceeds. In contrast, Layer 7 decides based on hostnames, paths, or HTTP properties which service processes the request. These layers must be modeled separately to keep architecture, operations, and troubleshooting manageable.
Correctly Implementing Proxy Protocol in the Backend Pool
Proxy Protocol transmits connection information from a proxy or load balancing layer to the backend. This allows applications to evaluate the original client IP and other transport data. Prerequisites include a coordinated protocol, compatible listeners, and consistent configuration across the entire backend pool.
TLS Termination at the Edge: Designing Secure Routing
TLS Termination ends the external HTTPS connection at the edge, creating the technical handover point for application-specific routing. This enables host, path, and header rules. However, the architecture must clearly define which security and routing tasks the edge handles and what control remains with the backend.
Planning Backend Pools: Health Checks and Failover
Backend pools are not merely lists of target systems. Their composition determines which backends receive traffic, how failures are detected, and when failover is triggered. Meaningful health checks, clear pool boundaries, and a defined fallback path prevent the edge from distributing traffic to technically reachable but non-functional systems.
Anycast in Traffic Management: Routing to the Backend
Anycast Traffic Management starts with a globally reachable entry point but doesn't end at the nearest edge location. Anycast routing directs traffic to an edge instance; there, Layer-4 and Layer-7 rules determine backend pools, health status, and, if necessary, application routing. Only this separation creates a controllable path to the application.
L4 or L7: Traffic Management in the Edge Cloud
L4 and L7 load balancing address different tasks. Layer 4 routes connections based on IP, port, and transport protocol without evaluating application content. Layer 7 understands HTTP or HTTPS and enables routing based on hostname, path, or other request characteristics. The decision impacts TLS processing, backend pools, and operational effort.
Failover Across Multiple Providers with the Edge Cloud
Provider-independent failover separates public traffic entry from the compute infrastructure. The edge handles Anycast, DNS, protection, TLS, and health checks, while backends or Kubernetes clusters are operated with different providers. Backend cloaking prevents failover architectures from being unnecessarily exposed by publicly accessible origin services.
Testing Failover: Runbooks, States, and Rollback Paths
Failover is only reliable when failure, switchover, and return are reproducibly tested. A good failover runbook describes expected health check states, routing and DNS behavior, observation points, and a controlled rollback path. The key is not the configured rule, but the demonstrable operational behavior.
Failover Response Paths Between Edge, DNS, and Backend
Failover is not a single switch function but a chain of detection, decision, forwarding, and stabilization. Edge routing typically reacts closer to the ongoing traffic, while DNS failover is delayed by TTLs, resolver, and client caches. Existing connections follow different rules than new requests.
Failure Domains in Edge Design for Public Services
Failover is only resilient if backup paths do not depend on the same failure domain as the primary path. Therefore, backend, cluster, provider, network, and edge must be evaluated separately. A multi-PoP architecture with its own Autonomous System and active-active operation expands the design space for high availability but does not replace a thorough dependency analysis.
Active/Passive or Active-Active: Choosing the Right Failover
Active-passive failover is not inherently simpler, nor is active-active automatically superior. Key factors include switch-over time, data consistency, maintenance requirements, and the application's ability to support parallel processing. The Edge Cloud distributes public traffic regardless of the backend model used and must reliably handle health checks, routing, and failover.
Active-Active Failover: Load Distribution and Consistency
Active-active failover distributes production traffic simultaneously across multiple backends, making individual failures often transparent to users and clients. The trade-off is additional effort: sessions, data changes, and side effects must be designed to be consistent or deliberately fault-tolerant across the involved instances.
Backend Pools in Failover: States, Routing, and Recovery
Backend pools are not a static directory of target systems but an operational model for load distribution, state assessment, and controlled recovery. Failover starts with health checks but only ends when fallback, consistency, and renewed resilience of the primary pool are verified. Without defined state transitions, returning to regular operations can create new failures.
Backend Health Checks as a Foundation for Robust Failover
Backend Health Checks provide the signals that an edge platform uses to distinguish between reachable and unreachable targets. Their significance depends on the checkpoint: network connection, process state, and actually usable service are different failure domains. Robust failover is achieved through appropriate check signals and controlled recovery.
DNS-based Failover: TTL, Caching, and Downtime
DNS-based failover distributes requests to accessible targets but cannot redirect existing connections and does not take effect immediately everywhere due to caching. TTL, recursive resolvers, operating systems, and applications influence the switchover time. Anycast DNS and Multi-Provider DNS enhance controllability and resilience but do not completely eliminate this uncertainty.
Routing-Based Failover for APIs and Web Applications
Routing-based failover decides at the edge which accessible backend pool receives a request or connection. Unlike DNS failover, the client does not need to resolve a new target name first. This shortens the response path, makes health statuses immediately usable, and separates public access from the actual compute infrastructure.
Digital Sovereignty Through Separate Edge Responsibility
Digital sovereignty is not achieved by avoiding cloud or platform providers, but through controllable architectural boundaries. By separating public access, routing, and security functions from the compute infrastructure, Kubernetes clusters can be operated more independently, providers can be switched, and security decisions can be enforced centrally. The ayedo Edge Cloud supports this model in front of own or external clusters.
Active-Active Architecture for Highly Available Platforms
An active-active architecture distributes edge functions across multiple PoPs, instead of maintaining a site as a passive backup. This makes failover and maintenance part of ongoing operational processes. For internal platform services, this means the public access, protection functions, and routing must be resilient themselves—regardless of where the backends are operated.
Backend Cloaking as a Platform Standard for Services
Backend Cloaking separates the public service endpoint from the actual backend addresses. As a platform standard, it reduces the visible attack surface, facilitates network segmentation, and decouples service publication from internal infrastructure details. The ayedo Edge Cloud implements this separation at the edge—even for Kubernetes clusters outside of ayedo Managed Kubernetes.
Provider-Independent Edge Architecture in Platform Operations
A provider-independent edge is not achieved merely by using multiple cloud providers. The key is who controls public accessibility, routing, protection, and failover. An independent network, autonomous system, and a centrally operated edge platform decouple these functions from individual compute or Kubernetes providers. This makes migration capability and operational responsibility architecturally manageable.
An Edge Layer for Heterogeneous Kubernetes Clusters
Heterogeneous Kubernetes clusters increase flexibility but also distribute routing, TLS, security, and failover across multiple implementations. A unified edge layer decouples the public ingress from cluster technologies and compute providers. The ayedo Edge Cloud performs these functions provider-independently, enabling consistent backend cloaking across multi-cluster architectures.
Boundaries of Responsibility Between Platform and Application
A resilient operational model for the edge separates core protection and network functions from application-specific configuration. The platform team is responsible for DNS, TLS, DDoS Protection, and technical accessibility. The application team provides business requirements, WAF rules, and robust health check endpoints. Shared responsibility prevents blind spots in accountability.
Self-Service for DNS and Traffic at the Application Entry Point
Self-service DNS should not mean that application teams manage DNS zones, routing, and security decisions entirely on their own. An internal platform should offer standardized building blocks, fixed policies, and traceable approvals. This way, services are published faster while operations, security, and network responsibilities remain centrally manageable.
Kubernetes and Edge Cloud as a Unified Platform Boundary
A unified deployment of multiple Kubernetes clusters doesn't start with Ingress resources, but with a clear platform boundary. Kubernetes manages workloads and internal services; the provider-independent edge handles public traffic, protection, TLS, routing, and failover. This creates a unified Kubernetes Edge Integration for managed and external clusters.
Standardized Load Balancing in Developer Platforms
Standardized load balancing separates central network and security decisions from team-specific service parameters. Layer-4 and Layer-7 load balancing can be integrated into internal platforms when policies, defaults, and responsibilities are clearly defined. The ayedo Edge Cloud provides a provider-independent edge layer for applications and APIs.
Edge Functions as a Product of the Internal Platform
An internal developer platform should not treat edge functions as individual infrastructure tasks. TLS termination, DNS, load balancing, and backend health checks are provided as standardized platform services with clear interfaces, responsibilities, and operational models. This creates a reusable platform product for different application teams and runtime environments.