The European managed services map for sysadmins: which service runs which layer of your web stack

This is the reference map the rest of our series on European Cloud Architectures: Running Scalable Web Apps on Sovereign Infrastructure links back to. If you run web application infrastructure and you’re moving a stack onto European providers, you need to know one thing quickly: for each layer of your stack, which provider gives you a managed service, and where you’re expected to run it yourself.

That’s what this article does. It walks the stack layer by layer – compute, managed PostgreSQL and MySQL, object storage, cache, queue, Kubernetes, load balancing, DNS and CDN – and maps each one to the concrete service at OVHcloud, Scaleway, Hetzner, IONOS, Exoscale, STACKIT and Open Telekom Cloud. For every layer it also names the open source component you’d run yourself when a provider has no managed option, plus the maturity and limits worth knowing before you commit.

Two things to keep in mind as you read. First, service names and coverage change; treat this as a starting point and confirm current availability in the provider’s own docs before you architect around it. Second, “managed” means different things at different providers. At some it’s a full lifecycle service with backups, patching and failover included. At others it’s a one-click install you still operate. We flag that difference where it matters, because it decides how much of the runbook lands on your team.

How to read this map

The providers here split roughly into three groups, and knowing which group you’re in changes your expectations.

• Full-portfolio public clouds – OVHcloud, Scaleway, IONOS, STACKIT and Open Telekom Cloud. These give you managed services across most layers: databases, object storage, Kubernetes, load balancers, sometimes cache and queue. You provision them like you would on a hyperscaler.
• Infrastructure-focused providers – Hetzner. Excellent compute, network, load balancer and S3-compatible object storage, but the data, cache and queue layers are yours to run. You get raw building blocks at a very low price and you bring the operational knowledge.
• Kubernetes-and-data specialists – Exoscale. A clean managed Kubernetes and managed database offering with S3-compatible storage, strong on the layers most web apps actually need.

Throughout, the open source equivalent matters as much as the managed one. If you standardise on MinIO for object storage, PostgreSQL with Patroni for databases, and PowerDNS for health-checked DNS, you can run the same stack on any of these providers – or across two of them – without rewriting your platform. That portability is the point of a sovereign-first strategy: you’re not locked to one vendor’s proprietary services.

Compute

Every provider here does compute well, so this is the least differentiated layer. What differs is the failure-domain model, and that’s what you should check first.

• OVHcloud – Public Cloud Instances, plus Bare Metal and dedicated servers. Public Cloud regions are mostly single-datacenter; OVHcloud has been rolling out true 3-AZ regions (starting in the Paris region) for workloads that need in-region redundancy.
• Scaleway – Instances (including cost-effective Stardust and DEV ranges up through production GP instances) and Elastic Metal bare metal. Multiple Availability Zones in the Paris region (fr-par-1/2/3) let you spread nodes across real failure domains.
• Hetzner – Cloud servers (shared and dedicated vCPU) plus dedicated root servers. Locations in Germany and Finland, with network zones grouping them. There’s no formal multi-AZ construct inside a location, so plan redundancy across locations yourself.
• IONOS – Compute Engine VMs with flexible CPU/RAM sizing, plus dedicated cores. Data centers across Europe you assign resources into.
• Exoscale – Compute instances across several European zones (Germany, Austria, Switzerland, Bulgaria). Each zone is an independent failure domain, which makes multi-zone design straightforward.
• STACKIT – Compute instances (IaaS) in EU data centers operated by the Schwarz Group. Availability zones within regions for redundant placement.
• Open Telekom Cloud – Elastic Cloud Server (ECS) and Bare Metal Server (BMS), built on the OpenStack-based Open Telekom Cloud platform with multiple AZs per region.

Open source equivalent: the compute layer is the substrate, so the “open source” question here is really your provisioning tooling. Standardise on Terraform or OpenTofu with the provider’s own provider plugin, and cloud-init for instance bootstrap. Every provider on this list has a Terraform provider, which is what keeps your infrastructure code portable.

Maturity and limits: the trap is assuming “region” means “multiple failure domains.” At several providers a region is one building. If you need to survive a datacenter event in-region, confirm the provider offers real AZs there (OVHcloud 3-AZ, Scaleway fr-par, Exoscale multi-zone, Open Telekom Cloud AZs) – otherwise your redundancy has to span regions, which changes your latency and data-replication design.

Managed PostgreSQL and MySQL

This is where the providers separate most clearly, because operating a highly available relational database is the layer teams most want to hand off.

• OVHcloud – Public Cloud Databases for PostgreSQL and MySQL (also MongoDB, and other engines). Managed backups, node scaling and read replicas, with high-availability node configurations.
• Scaleway – Managed Database for PostgreSQL and MySQL, with high-availability mode (primary plus standby), automated backups and read replicas. Also a Serverless SQL Database (PostgreSQL-compatible, scale-to-zero) for spiky workloads.
• Hetzner – no managed relational database. You run it yourself.
• IONOS – Database as a Service for PostgreSQL and MySQL (and MongoDB), with managed backups and replication.
• Exoscale – Managed Databases (DBaaS) for PostgreSQL and MySQL (plus Valkey/Redis, OpenSearch and Kafka), built on the Aiven platform. Managed HA, backups and version upgrades.
• STACKIT – PostgreSQL Flex and MariaDB/MySQL Flex managed database services, plus SQL Server options. Managed instances with backups within STACKIT’s sovereign platform.
• Open Telekom Cloud – Relational Database Service (RDS) for PostgreSQL, MySQL and SQL Server, with primary/standby HA and automated backups.

Open source equivalent: PostgreSQL with Patroni for automated failover, coordinated through etcd or Consul, fronted by HAProxy and PgBouncer for connection routing and pooling. This is the pattern you run on Hetzner, or anywhere you want full control of the database layer. It’s mature and well documented, but it’s real operational work: you own patching, backup verification, and – the part teams skip – actually testing failover.

Maturity and limits: read the fine print on what “high availability” includes. Check the RPO and RTO the provider commits to, whether failover is automatic or a support ticket, and how read replicas are billed. Two limits show up repeatedly: connection limits that push you toward a pooler like PgBouncer regardless of the managed service, and version support that lags upstream PostgreSQL by a release or two. And whether managed or self-run, test the failover before you depend on it. An untested failover is a guess, not a plan.

Object storage

Object storage is the most standardised layer in Europe, because almost everyone speaks the S3 API. That’s good news for portability – your application code and your backup tooling don’t care which provider is behind the endpoint.

• OVHcloud – Object Storage with an S3-compatible API (the newer S3 Standard class) alongside the older Swift interface. Also Cold Archive for cheap long-term storage.
• Scaleway – Object Storage, S3-compatible, with Standard, Infrequent Access and Glacier-style cold classes, plus lifecycle rules and versioning.
• Hetzner – Object Storage, S3-compatible, in the Germany and Finland locations. Straightforward and cheap; a genuine building block rather than a full feature-parity S3.
• IONOS – S3 Object Storage, S3-compatible, across European regions.
• Exoscale – Simple Object Storage (SOS), S3-compatible, available in each compute zone.
• STACKIT – Object Storage, S3-compatible, within the sovereign platform.
• Open Telekom Cloud – Object Storage Service (OBS), S3-compatible, with standard, warm and cold tiers.

Open source equivalent: MinIO, the S3-compatible object store you run on your own instances or Kubernetes. Useful when you want object storage co-located with an app in a region where the provider doesn’t offer it, or when you want a single storage API across a hybrid setup. Note MinIO’s licensing and feature changes over time, so pin the version and read the terms for your use.

Maturity and limits: “S3-compatible” is a spectrum. The core object operations work everywhere. Where compatibility frays is the edges – specific ACL semantics, object lock and legal hold, presigned URL quirks, some multipart behaviours, and event notifications. If your application depends on an advanced S3 feature, test that specific feature against the target provider rather than assuming full parity. Also confirm per-object and per-bucket size limits and egress pricing, which vary a lot.

Cache

Redis-style caching is where managed coverage gets patchy, and where the Redis licence change (and the Valkey fork that followed) matters for what you’ll actually be running.

• OVHcloud – Public Cloud Databases includes managed Redis, so you can provision a cache node as a managed service.
• Scaleway – no standalone managed Redis at the time of writing; run it yourself on Instances or in Kapsule. (Confirm current catalog, as this layer moves.)
• Hetzner – self-managed on Cloud servers.
• IONOS – self-managed; no dedicated managed Redis in the standard catalog.
• Exoscale – Managed Databases includes Valkey (the open source Redis fork), covering the cache use case as a managed service.
• STACKIT – Redis is offered as a managed service within the platform catalog.
• Open Telekom Cloud – Distributed Cache Service (DCS) for Redis, managed with HA options.

Open source equivalent: Valkey or Redis, run on a dedicated instance or as a StatefulSet in Kubernetes, with Sentinel for failover or Cluster mode for sharding. For most web apps the cache is rebuildable, so a single well-sized node with a warm-up path on restart is often enough – don’t over-engineer HA for data you can regenerate.

Maturity and limits: decide early whether your cache is disposable or authoritative. If it holds sessions or anything you can’t lose, you need real persistence and failover, managed or not. Check which engine and version a provider’s “Redis” actually is (Redis vs Valkey), since the licence split means they’re diverging.

Queue and messaging

Managed message queues are the thinnest layer across European providers. Plan to run this one yourself in most cases.

• OVHcloud – Public Cloud Databases offers managed Kafka, which covers streaming and event pipelines. No managed AMQP broker.
• Scaleway – Messaging and Queuing with SQS/SNS-compatible queues and topics, plus NATS. A genuine managed queue option, API-compatible with common patterns.
• Hetzner – self-managed.
• IONOS – self-managed.
• Exoscale – Managed Databases includes Kafka for streaming; run RabbitMQ yourself if you need AMQP.
• STACKIT – Kafka-style event streaming is available in the catalog; confirm current messaging options for your pattern.
• Open Telekom Cloud – Distributed Message Service (DMS) and a managed Kafka offering.

Open source equivalent: RabbitMQ for classic task queues and work distribution, Apache Kafka (or Redpanda) for event streaming and log-style pipelines, and NATS when you want something lightweight. For simpler jobs, a Redis- or Postgres-backed queue (via your framework’s job library) avoids standing up a broker at all.

Maturity and limits: match the tool to the pattern. Kafka is for high-throughput streaming and replayable logs, not for a handful of background jobs – running it for a small app is a lot of operational weight for little gain. If a provider only offers Kafka and you need simple AMQP semantics, running RabbitMQ yourself is usually the lighter path.

Kubernetes

Managed Kubernetes is broadly available and mature across the full-portfolio providers, and it’s often the cleanest way to run the layers a provider doesn’t manage for you (cache, queue, MinIO) alongside your apps.

• OVHcloud – Managed Kubernetes Service (MKS). Free control plane, you pay for worker nodes; the cloud controller integrates Public Cloud Load Balancers automatically.
• Scaleway – Kubernetes Kapsule (on Instances) and Kosmos (multi-cloud/hybrid node pools). Managed control plane with autoscaling node pools.
• Hetzner – no managed Kubernetes. Teams commonly run k3s or kubeadm on Cloud servers, wired to the Hetzner Cloud Controller Manager and CSI driver so Load Balancers and Volumes provision natively.
• IONOS – Managed Kubernetes, fully automated cluster setup with integrated persistent storage.
• Exoscale – Scalable Kubernetes Service (SKS). Managed control plane, node pools, and native integration with the Exoscale NLB.
• STACKIT – Kubernetes Engine (SKE), managed control plane and node pools on the sovereign platform.
• Open Telekom Cloud – Cloud Container Engine (CCE), managed Kubernetes with AZ-aware node pools.

Open source equivalent: k3s for a lightweight, production-capable cluster you assemble yourself, or kubeadm for a vanilla upstream cluster. Pair either with the provider’s Cloud Controller Manager and CSI/CCM drivers so that Kubernetes Service objects of type LoadBalancer and PersistentVolumeClaims map to real provider resources. On Hetzner this pairing is the standard way to get a managed-like experience without a managed service.

Maturity and limits: the control plane is the easy part; the integration is where clusters differ. Confirm the provider ships a working CCM (for LoadBalancer services) and CSI driver (for persistent volumes), how upgrades are handled (rolling node pool replacement vs in-place), and how the cluster spreads across AZs. A cluster whose nodes all sit in one failure domain gives you the operational shape of Kubernetes without the availability.

Load balancing

Load balancers are widely available, but the detail that bites is the boundary: most provider load balancers work within a region or network zone and don’t stretch across regions.

• OVHcloud – Public Cloud Load Balancer (L4/L7), integrated with MKS via the cloud controller. Also Load Balancer for dedicated/bare metal setups.
• Scaleway – Load Balancers (L4/L7) with health checks, plus a multi-region option for spreading a single frontend across regions.
• Hetzner – Cloud Load Balancer (L4/L7) with health checks and targets by label; scoped to a network zone.
• IONOS – Network Load Balancer and Application Load Balancer.
• Exoscale – Network Load Balancer (NLB), integrated with SKS.
• STACKIT – managed Load Balancer service within the platform.
• Open Telekom Cloud – Elastic Load Balancer (ELB), AZ-aware within a region.

Open source equivalent: HAProxy or Nginx as your own L4/L7 balancer, or an ingress controller (ingress-nginx, HAProxy, Traefik) inside Kubernetes. For per-region edge and caching you can put Varnish or Nginx in front. Running your own balancer gives you consistent config across providers, at the cost of managing its own availability.

Maturity and limits: the single most common design mistake here is expecting a provider load balancer to fail traffic over to another region. It won’t – its health checks and target pool live inside one region or network zone. Cross-region failover is a higher-layer job, which is what the next section is for.

DNS and CDN

DNS is where your cross-region and cross-provider failover actually happens, and it’s the layer people most often misjudge because of TTL behaviour.

• OVHcloud – managed DNS zones as a registrar and DNS host, plus a CDN option for web assets.
• Scaleway – Domains and DNS (managed zones), with Edge Services for caching/CDN in front of Object Storage and Load Balancers.
• Hetzner – Hetzner DNS (managed zones, free) with an API. No first-party CDN.
• IONOS – managed DNS as part of its domains and cloud offering.
• Exoscale – managed DNS with an API. No first-party CDN.
• STACKIT – DNS service within the platform.
• Open Telekom Cloud – Domain Name Service (DNS) and a Content Delivery Network offering.

Native CDN coverage is uneven, and for many European-first stacks the practical answer is a European-headquartered CDN and edge/WAF provider in front of your origin, or your own edge tier. Confirm where a provider’s CDN pops actually are before assuming European coverage.

Open source equivalent: PowerDNS for authoritative DNS with health-checked, weighted responses when you want to run failover logic yourself. For the edge and cache tier, Varnish or Nginx per region gives you a CDN-like layer you control. For a WAF at the edge, ModSecurity or Coraza with the OWASP Core Rule Set is the standard open source pattern, deployable in front of Nginx or your ingress.

Maturity and limits: DNS failover is not instant. When you fail over by changing a record, clients keep using the old answer until their cached TTL expires, and some resolvers ignore low TTLs. Set TTLs deliberately (short – 30 to 60 seconds – on records you plan to fail over), understand that “short” still means a window of stale routing, and use health-checked DNS rather than manual edits during an incident. Treat DNS as the coordination layer for cross-region failover, and rehearse it, because this is exactly the failover teams forget to test until it’s live.

The map at a glance

Reading across the providers, a few patterns hold. Compute, object storage, Kubernetes and load balancing are well covered almost everywhere. Managed relational databases are strong at OVHcloud, Scaleway, IONOS, Exoscale, STACKIT and Open Telekom Cloud, and absent at Hetzner. Cache and queue are the thin layers: reliably managed at Open Telekom Cloud, partly covered elsewhere (OVHcloud and Exoscale via their database platforms, Scaleway for queuing), and self-run at Hetzner and IONOS.

That shapes a simple rule for choosing. If you want the most handed-off experience across every layer, the full-portfolio clouds – OVHcloud, Scaleway, Open Telekom Cloud, STACKIT, IONOS – give you the fewest services to operate yourself. If you want the lowest cost and maximum control and you have the operational skill to run databases, cache and queue, Hetzner plus a disciplined open source stack is a strong, genuinely sovereign platform. Exoscale sits neatly in between for teams centred on Kubernetes and managed data.

The through-line is that Europe now has a real, complete set of building blocks for the whole web stack, and the open source equivalents – MinIO, PostgreSQL with Patroni, Valkey, RabbitMQ and Kafka, k3s, HAProxy, PowerDNS, Coraza – keep you portable across all of them. You can commit to a European-first architecture without giving up the operational patterns you already trust.

The rest of this series takes each of these layers and shows the actual provisioning, configuration and runbooks – starting from this map. If you want a second pair of hands designing or operating a stack like this on European infrastructure, that’s the work our cloud systems administrators do every day: planning the architecture, migrating the systems, and running them once they’re live, automating whatever can be automated along the way.