For a new integration, OpenID Connect is the preferred choice when the application supports it; SAML 2.0 remains suitable for existing software or products that only support that protocol. Next, configure the OIDC redirect URIs or SAML assertion consumer service endpoints, then connect the application to the realm’s endpoints.

For IT departments, SSO addresses an everyday need: providing access to an entire application portfolio through a single login, with centralised security controls. Keycloak, an open-source identity and access management (IAM) solution, meets this need by centralising authentication.

Keycloak as a central identity provider

Keycloak sits between applications and their users. Users authenticate with Keycloak and, while their SSO session remains valid, can access connected applications without re-entering their credentials. Each application trusts the authentication information provided by Keycloak to establish its own session. This is how an identity provider (IdP) works.

Centralising login offers a tangible security benefit: according to the ENISA Threat Landscape 2025 report, the annual report published by the European Union Agency for Cybersecurity, phishing accounts for approximately 60% of the initial intrusion methods observed in the incidents studied. With Keycloak, multifactor authentication (MFA) policies can be enforced at the shared login point for connected applications. However, not all forms of MFA provide the same protection against phishing: passkeys and WebAuthn are phishing-resistant by design because the authentication key is bound to the domain for which it was created.

Each application maintains its own session. In a full OIDC integration, the application checks the session status with Keycloak and can therefore respond when that session ends. Some applications, however, only verify the JWT’s signature and validity period locally. In this case, a token that is still valid may continue to be accepted after the Keycloak session has ended. This is JWT-based authentication rather than full OIDC session management.

Keycloak supports OpenID Connect (OIDC) and SAML 2.0. Modern applications and existing software can therefore share the same single sign-on within a single realm.

Configure SSO with Keycloak, step by step

The Clever Cloud Keycloak documentation covers service access, realm management, IP address filtering, deployments in Secured Multi Instances mode, and metrics monitoring. For settings specific to OIDC and SAML clients, also refer to the Keycloak administration documentation.

To see the deployment process and interface in practice, watch the video demonstration on our Keycloak as a Service page.

OIDC or SAML 2.0 for SSO: which should you choose?

PoFor new development, choose OpenID Connect when the application supports it. Retain SAML 2.0 for applications whose integration already relies on that protocol or that do not support OIDC:

• OpenID Connect authenticates users of modern web and mobile applications; OAuth 2.0 and its access tokens control access to APIs.
• SAML 2.0 supports existing applications and enterprise software that do not offer OIDC integration.

Keycloak supports both protocols within a single realm. OIDC and SAML applications can therefore share the same single sign-on.

Configure SSO on a managed Keycloak instance

Configuring SSO is only part of the work: a Keycloak server then needs ongoing maintenance, updates, monitoring, and backups. A managed service takes on this operational workload.

Keycloak as a Service, Clever Cloud’s offering operated with the expertise of Please Open It, deploys a managed Keycloak instance hosted in France in just a few clicks. Teams retain control over all settings (realms, clients, and protocols) while Clever Cloud handles infrastructure operations, including ongoing updates, integrated monitoring, and regular backups. When the service is deployed in clustered Secured Multi-Instances mode, multiple nodes distribute the load and improve service continuity. Separately from this architecture, the 99.99% SLA, 24/7 on-call telephone support, and guaranteed response and resolution times are provided through the Premium offering for eligible services. Realm import and export make it easier to migrate an existing instance. Finally, to protect an application without built-in authentication, an authentication proxy such as OAuth2-Proxy adds a login step before users reach the application, without changing its code.

«Keycloak is a Red Hat product, but Red Hat does not provide an open-source LTS version of Keycloak, and security fixes are not backported. Staying on the latest version is therefore essential, and deploying Keycloak as a Service on Clever Cloud makes this much easier. A single realm, separate from master, is often sufficient; multiple realms are only justified when user populations are entirely independent, with no shared applications or with separate deployments. Keycloak also decouples the addition of authentication factors from applications, making it possible to offer the latest authentication factors across all integrated applications. »

— Loïc Mercier des Rochettes, Co-founder and CTO at Please Open It

Evaluating an IAM solution? Our checklist, 11 questions to ask before choosing an identity management solution, brings together the criteria to assess before making a commitment.

FAQ

Does Keycloak support SSO?

Yes. Keycloak is an open-source identity management solution that acts as a central identity provider: applications delegate login to it, and users authenticate only once. It supports OpenID Connect and SAML 2.0.

Should you use OIDC or SAML for SSO with Keycloak?

Both are suitable. OpenID Connect is designed for modern web applications, mobile applications, and APIs; SAML 2.0 remains the established standard for existing enterprise applications. Keycloak handles both protocols in parallel.

How do you connect an application to Keycloak?

Create a client in the relevant realm, then configure it according to the protocol used by the application. For OpenID Connect, this includes configuring its redirect URLs and providing the client ID, the realm’s discovery URL, and a secret only if the application can securely store it. For SAML 2.0, configure the application’s entity ID, its Assertion Consumer Service URL, and the metadata exchange with Keycloak.

Do you need to host Keycloak yourself to implement SSO?

No. A self-hosted Keycloak deployment requires you to manage installation, updates, security, and availability. A managed offering, such as Clever Cloud’s Keycloak as a Service, handles these operations; teams remain responsible for clients, users, permissions, and authentication policies.

Can you secure an existing application without changing its code?

Yes. An authentication proxy such as OAuth2-Proxy, connected to Keycloak, can require users to log in before forwarding requests to the application, without changing its code. This approach is particularly suitable for back-office applications and internal tools without built-in authentication, provided the application cannot be accessed directly by bypassing the proxy. Any application-specific authorisation rules still need to be defined.

When these exchanges require the ports of different services to be publicly exposed, the attack surface increases and the network configuration becomes more cumbersome to maintain. Creating a private network between applications directly addresses this problem without requiring you to deploy or manage VPN infrastructure.

This approach allows cloud services to communicate directly with one another, over any port, without exposing the ports required for these exchanges to the Internet. Data travels over an encrypted overlay network that is independent of the physical network. On Clever Cloud, Network Groups provide this functionality: they establish WireGuard tunnels between resources, with no low-level network configuration.

Why exposing your services to the Internet is a problem

When application components communicate over public ports, each exposed service becomes a potential entry point. This has three practical consequences:

• Larger attack surface: every public access point must be secured, monitored, and maintained.
• Unnecessary exposure of technical ports: some protocols require dedicated ports for internal communications, even though they are not intended to be publicly accessible. A private network lets you use them without creating new entry points from the Internet.
• Reliance on external tunnels: connecting services distributed across several zones usually requires you to configure and manage an additional network layer, often a VPN.

Connecting services within a private network allows their internal traffic to flow without exposing the ports used for these communications. However, this does not disable any public access that is already configured. If only an API gateway should provide access to the backends from the Internet, you must also block their public endpoints.

How a private network between applications works

The approach is based on an overlay network: a logical network layer built on top of the existing physical network. Resources have private connectivity to one another, and their communications are encrypted by default. Because the overlay is independent of the underlying physical network, it can connect resources distributed across multiple zones or datacenters.

Consider an application comprising a public API, several backend services, and a database: only the API is exposed to the Internet. The internal services and database communicate with one another over the private network, using the ports they require.

Creating a private network between applications on Clever Cloud

Network Groups provide this setup. Each resource attached to a Network Group receives a private IP address from a dedicated CIDR, as well as an internal domain name in the format "<memberID>.m.<ngID>.cc-ng.cloud". The resources can then connect directly to one another, over any port, with no network configuration required.

A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. Communications are encrypted using WireGuard, a protocol known for its simplicity and speed.

You can create and manage Network Groups from the Clever Cloud Console, Clever Tools (CLI), or the public API. For example, from the command line:

clever features enable ng
clever ng create monNG --link app_xxx,postgresql_xxx

Note: add-on compatibility depends on their generation. Add-ons deployed since 2024 are compatible; older ones may require a migration or restart. See the documentation for the current limitations.

When should you use a private network between applications?

Network Groups are not a standalone solution: they enable certain secure architectures rather than replace an existing product. Several use cases are common.

• Protect applications behind an API gateway: the backends remain unreachable from outside while still being accessible from the gateway.
• Deploy Keycloak for high availability: multiple Keycloak instances synchronise over the private network without being publicly exposed.
• Enable microservices to communicate: in a distributed architecture, services communicate continuously without opening public ports or configuring tunnels.
• Integrate external resources: connect a local machine or third-party server to your Clever Cloud applications over an encrypted channel.

Connect your services without the complexity of a VPN

With Network Groups, private connectivity becomes a platform capability rather than infrastructure that you have to build and maintain. You choose which resources need to communicate; Clever Cloud establishes the encrypted private network between them. This allows you to use the ports required for internal communications without exposing them publicly, whether your resources are in the same zone, distributed across several data centres or, where applicable, external to Clever Cloud.

FAQ

What is the difference between a VPN and a private network between applications?

The main difference is what you have to manage. With a traditional VPN, you generally need to deploy, configure, and maintain connectivity between the relevant machines or networks. With Network Groups, Clever Cloud manages this layer for you: you attach the resources to the group, and the platform establishes encrypted private connectivity using WireGuard.

Do you need to modify your application code to use Network Groups?

In most cases, no. You do not need to rewrite your application. The change is in the configuration, not the code: the calling application must target the destination service using its internal Network Group domain name (<memberID>.m.<ngID>.cc-ng.cloud) and the required port, usually through an environment variable. No specific library or application changes are required for the traffic to use the private network.

Does a private network between applications work with machines outside Clever Cloud?

Yes. A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. However, support for attaching an external peer is still being stabilised during the testing phase.

Does a private network make an application invisible from the Internet?

No, not by itself. Network Groups provide private access to resources, but they do not disconnect an application from the Internet. Restricting public exposure is handled by other platform mechanisms.

For an IT department, SAML 2.0 addresses a practical question: how can an employee be given access to dozens of applications with a single authentication process, while centralising authentication policies through an identity provider?

What is SAML 2.0?

This centralisation of authentication is precisely what SAML standardises. Version 2.0 of the standard was approved by OASIS (Organization for the Advancement of Structured Information Standards) in March 2005 at its highest level of ratification. It brought together three earlier initiatives: SAML 1.1, the Liberty Alliance ID-FF 1.2 profile and contributions from the Shibboleth project. It was also adopted as an international recommendation by the International Telecommunication Union (ITU-T X.1141).

Technically, the SAML protocol is based on assertions: XML security tokens that describe a user, the “principal", and their authentication. These assertions are exchanged between two roles:

• The Identity Provider (IdP), which authenticates the user.
• The Service Provider (SP), which is the application the user wants to access.

More than twenty years after its ratification, SAML 2.0 is not a legacy protocol. It remains widely deployed in businesses, the public sector and academia, where it continues to provide a foundation for identity federation.

How does SAML authentication work?

SAML authentication involves three parties: the user, the Identity Provider (IdP) and the Service Provider (SP). In the most common scenario, known as “SP-initiated” authentication, the exchange works as follows:

Trust between the IdP and the SP cannot be established automatically. It must be configured beforehand through an exchange of metadata, including certificates, endpoints and identifiers. This allows each party to verify the authenticity of the other party’s messages. The assertion’s cryptographic signature guarantees that it came from the expected identity provider and has not been altered.

Components of the SAML 2.0 standard

The SAML 2.0 standard consists of several complementary components:

• Assertions: the statements themselves, which can contain three types of information: authentication information, attributes such as a role, department or email address, and, less commonly, an authorisation decision.
• Protocols: the request and response messages used to carry assertions.
• Bindings: the methods used to transport these messages over the web, for example through an HTTP redirect or an HTTP POST request.
• Profiles: predefined combinations of components for a particular use case. The best-known example is the Web Browser SSO Profile.
• Metadata: the technical description exchanged between the IdP and SP to establish trust.

Although SAML can carry authorisation decisions, its main uses remain Single Sign-On and attribute exchange. Fine-grained authorisation is generally handled by other mechanisms.

SAML 2.0, OAuth 2.0 and OpenID Connect: what are the differences?

These three standards are often confused, even though they do not address the same question:

• SAML 2.0 deals with authentication and Single Sign-On. It is based on XML and is widely established in enterprise environments, cross-organisational federations and the public sector.
• OAuth 2.0 deals with authorisation. It delegates access to a resource (for example, “Can this application read my calendar?”) and does not handle authentication on its own.
• OpenID Connect (OIDC) adds an authentication layer to OAuth 2.0, allowing an application to establish a user’s identity, particularly through an ID token in JWT format. It is suitable for web and mobile applications, while API access relies on OAuth 2.0 access tokens.

In practice, SAML 2.0 and OpenID Connect coexist. SAML remains the standard for existing enterprise applications, while OpenID Connect is generally used for new developments. The choice between SAML, OAuth 2.0 and OpenID Connect depends on the type of application, its authentication requirements and how access to APIs must be delegated.

Implementing SAML 2.0 with Keycloak

The most common way to deploy SAML 2.0 without reimplementing the protocol is to use an Identity and Access Management (IAM) solution. Keycloak, a leading open-source solution in this field, can act as a SAML 2.0 identity provider. It also supports OpenID Connect, allowing legacy SAML applications and newer OIDC developments to share the same authentication service.

Clever Cloud offers Keycloak as a Service: a fully managed Keycloak service hosted in France and operated with the expertise of Please Open It, a partner specialising in Keycloak. This approach removes the burden of operating the identity server, including updates, availability and backups, from internal teams, while allowing them to retain control over SAML and OIDC settings.

« SAML 2.0 remains essential in enterprise environments because of its long history (2005) but also because of its network simplicity: everything passes through the user’s browser, with no direct connection required between the application and the identity server. In contrast, the modern OpenID Connect standard requires direct server-to-server communication to remain secure. OIDC’s ‘100% browser-based’ mode, the Implicit Flow, has now been abandoned because it is considered too vulnerable. »

— Mathieu Passenaud, Co-founder at Please Open It

FAQ

Is SAML 2.0 still used in 2026?

Yes. Ratified in 2005, SAML 2.0 remains widely deployed in businesses, the public sector and academia for Single Sign-On and identity federation. It coexists with OpenID Connect, which is often preferred for new web and mobile projects.

What is the difference between SAML and SSO?

SSO, or Single Sign-On, is a principle: users authenticate once to access multiple applications. SAML is one of the protocols that can implement this principle across domains. OpenID Connect is another.

Does SAML handle authentication or authorisation?

It can handle both, but it is mainly used for Single Sign-On and attribute exchange. The protocol can carry authorisation decisions, although this capability is rarely used in practice.

Should I choose SAML 2.0 or OpenID Connect?

The choice primarily depends on the protocol supported by the application. SAML 2.0 is suitable for services designed to use SAML federation, while OpenID Connect is generally appropriate for authenticating users in web and mobile applications. OAuth 2.0 access tokens are used to control access to APIs. Both approaches can coexist behind the same identity provider, such as Keycloak.

Does Keycloak support SAML 2.0?

Yes. Keycloak can act as a SAML 2.0 identity provider and also supports OpenID Connect, allowing both protocols to be used together.

What Is a French Managed Kubernetes Service?

A French Kubernetes service is a managed Kubernetes service provided by a French company. Depending on the offering, the infrastructure may be located in France or elsewhere in Europe and may run on a public cloud, a private cloud or dedicated machines.

Why Choose a French Kubernetes Provider?

Greater Digital Sovereignty

Entrusting orchestration to AWS, Google Cloud or Azure exposes organisations to a proprietary ecosystem and a non-European legal framework. Choosing a domestic provider reduces this dependency and supports a broader digital sovereignty strategy that goes beyond technical portability alone.

Clear Infrastructure Location and Responsibility

Knowing exactly where the control plane and worker nodes are running—and who is responsible for operating them—has become a key selection criterion for regulated industries and public-sector buyers alike.

Easier European Compliance

Infrastructure operated in Europe can simplify certain compliance processes relating to data location and transfers outside the European Union.

Local Support and Contract Management

Having a provider in the same time zone, billing in euros and documentation available in French can shorten resolution times and streamline contractual relationships.

French Managed Kubernetes Providers

The descriptions below reflect the offerings available at the time of writing. These services evolve rapidly, so always check the provider’s official website before making a decision.

OVHcloud Managed Kubernetes Service (MKS)

OVHcloud offers MKS, its managed Kubernetes service for the public cloud, in two tiers. MKS Free provides a free managed control plane. MKS Standard, launched in September 2025, adds a 99.99% SLA, with a control plane distributed across a three-availability-zone region (initially Paris, followed by Milan) dedicated etcd storage of up to 8 GB, and a choice of CNI plugins, including Cilium. The service integrates with the OVHcloud Public Cloud ecosystem.

Scaleway Kubernetes Kapsule

Kapsule is a CNCF-certified managed Kubernetes service for the public cloud. Its shared control plane is free, with a dedicated control plane available as an option for mission-critical workloads, while autoscaling is supported natively. The service integrates with Scaleway’s services and emphasises digital sovereignty and GDPR compliance for the European market.

Clever Kubernetes Engine (CKE)

CKE is Clever Cloud’s managed Kubernetes service. It runs on infrastructure located in France, with no dependency on a foreign hyperscaler. Each cluster runs on its own virtual machines, with no infrastructure shared between customers. The control-plane architecture can be configured according to the selected topology, ranging from an all-in-one bundle to one VM per component. The experience remains true to standard Kubernetes, with no lock-in mechanisms or need to rewrite manifests. Cluster state is stored in Materia etcd, an implementation of the etcd protocol developed in France and built on FoundationDB. CKE integrates with managed databases, S3-compatible object storage, IAM, observability services and private networking through Network Groups. The product is currently in public beta.

Comparing French Managed Kubernetes Services

French Kubernetes offerings are based on different architectures and operating models. The most useful comparison criteria are infrastructure location, hosting model, availability guarantees, level of integration with cloud services and compatibility with the standard Kubernetes ecosystem.

None of these offerings is inherently superior to the others. The right choice depends on the required operating model and the level of assurance expected.

French Kubernetes vs AWS EKS, Google GKE and Azure AKS

AWS EKS, Google GKE and Azure AKS remain the most comprehensive managed Kubernetes services in terms of their wider service portfolios and global reach. In return, they increase dependency on their respective ecosystems. A French offering addresses the same orchestration requirements while keeping the control plane and data subject to European law.

French providers host their infrastructure in France or elsewhere in Europe, under European law and with locally operated integrations. Hyperscalers offer a broader service portfolio and global reach, at the cost of greater dependency on their ecosystems.

The general criteria for selecting a managed cluster (irrespective of the national dimension) also warrant careful consideration. These include version policies, autoscaling, storage and the responsibility model.

Key takeaways

The best French Kubernetes service ultimately depends on your specific context. Some organisations will prioritise a generally available offering backed by strong contractual guarantees, while others will seek close integration with their cloud platform or existing environment. OVHcloud, Scaleway and Clever Cloud currently offer different approaches to managed Kubernetes. The choice primarily depends on operational, governance and compliance requirements, as well as the expected level of maturity.

FAQ

Are There Any French Managed Kubernetes Providers?

Yes. Several French companies offer managed Kubernetes services, including OVHcloud with Managed Kubernetes Service, Scaleway with Kubernetes Kapsule and Clever Cloud with Clever Kubernetes Engine. These solutions differ in their infrastructure models, level of managed service and integration with each provider’s cloud ecosystem.

What Is the Difference Between French and European Kubernetes?

A French Kubernetes service is provided by a French company, while a European Kubernetes service is provided by a company established in the European Union. In both cases, it is important to examine the infrastructure’s actual location, the entity that operates the service and the law applicable to the data.

Does a French Provider Guarantee Digital Sovereignty?

No. A provider’s nationality alone is not enough to guarantee sovereignty. Sovereignty also depends on the infrastructure operator, any subcontractors involved in the hosting chain and the legal frameworks to which they are subject.

Can You Use Helm and Terraform with a French Kubernetes Service?

Yes, provided that the service uses a standard Kubernetes implementation. The services offered by OVHcloud, Scaleway and Clever Cloud remain compatible with widely used ecosystem tools such as kubectl, Helm and Terraform, as well as GitOps practices.

How Do French Kubernetes Services Compare with AWS EKS?

AWS EKS benefits from an extensive portfolio of cloud services and a global presence. French offerings generally emphasise operations carried out in Europe, local support and integration with locally operated infrastructure. The right choice depends on each project’s technical, regulatory and organisational constraints.

What Is the Difference Between Managed and Self-Hosted Kubernetes?

The main difference lies in operational responsibility. With managed Kubernetes, the provider operates the control plane and handles part of the platform’s maintenance. With self-hosted Kubernetes, the organisation remains responsible for installing, updating, monitoring and securing the cluster, as well as ensuring its availability. Managed Kubernetes reduces the operational burden, while self-hosting provides greater control over the infrastructure.

Can You Migrate from One Kubernetes Provider to Another?

Yes, provided that a standard Kubernetes implementation is used. YAML manifests, Helm charts and deployment tools generally remain portable from one provider to another. However, certain provider-specific dependencies, such as storage, networking and managed services, may require adaptations.

Which French Kubernetes Service Is Best for an SME?

The right choice depends on the project’s requirements. An SME may prefer an offering with a free control plane for its initial deployments or seek closer integration with a particular cloud ecosystem. In all cases, compatibility with standard Kubernetes makes it easier to move to another offering if requirements change.

The control plane consists of Kubernetes’ standard components: the API server, etcd (the datastore that stores the cluster’s state), the scheduler and the controller manager. If the control plane fails, workloads that are already running continue to operate, but the cluster can no longer be managed: no new deployments, no scaling, and no response to kubectl commands. Managed services remove responsibility for precisely this layer from engineering teams.

Why is Kubernetes difficult to operate yourself?

Kubernetes  is a container orchestration standard, not a turnkey product. Deploying a cluster without a managed layer means handling:

• version upgrades (the Kubernetes project actively supports the three most recent minor releases);
• internal TLS certificate rotation;
• high availability of the control plane across multiple nodes;
• backup and consistency of the etcd datastore;
• security patches, often under tight time constraints.

These tasks are repetitive, consume valuable engineering time, and are a frequent source of incidents when not performed correctly. Managed services are specifically designed to remove this operational burden from product teams.

Use cases: when managed Kubernetes delivers value

Kubernetes—whether managed or self-managed—becomes relevant in specific scenarios. It is not a systematic replacement for a PaaS: the two approaches address different needs.

Managed Kubernetes is well suited when:

• the architecture includes multiple interdependent services requiring fine-grained orchestration (rolling updates, resource management by namespace);
• workloads are already built for Kubernetes and delivered as Helm charts or YAML manifests;
• the team requires multi-cluster or hybrid environments (on-premises + cloud);
• operating the control plane represents a real and measurable cost for SRE or DevOps teams.

A PaaS remains a better fit when:

• the application deployment model (code push with platform-managed build and runtime) matches the way your team works;
• you want to focus on application code without managing orchestration primitives (networking, scheduling, node management);
• your applications do not require fine-grained control over workload placement or the cluster’s network topology.

Comparison table: self-managed Kubernetes vs managed Kubernetes vs PaaS

Note: here, vanilla refers to a standard Kubernetes experience, with no changes to native Kubernetes behaviour and no proprietary tooling imposed.

Common mistakes when choosing or adopting managed Kubernetes

Managed Kubernetes in Europe: which sovereignty criteria matter?

For organisations subject to the GDPR, sector-specific regulations (healthcare, public sector, defence) or data residency requirements, where the cluster is hosted is a compliance issue, not just a performance consideration.

Points to verify:

• physical location of the    datacenters (country and applicable jurisdiction);
• identity of the operator and the involvement of foreign subcontractors in the hosting chain;
• infrastructure certifications (SecNumCloud, ISO 27001, HDS, depending on the provider and the offering);
• potential access to data by non-European third parties, particularly under extraterritorial legislation.

A managed Kubernetes service operated in France by a French provider addresses these requirements without requiring additional user-side configuration. This is the approach taken by Clever Kubernetes Engine (CKE), operated end to end in France by Clever Cloud, with no foreign hyperscaler involved in the hosting chain.

Key takeaways

Managed Kubernetes is relevant when your organisation already relies on Kubernetes and maintaining the control plane represents a meaningful operational burden. It is not a universal solution: when a PaaS deployment model matches the way your team works, it often remains the most straightforward choice. For organisations with European sovereignty requirements, the choice of provider and hosting location is critical.

The key selection criteria are vanilla compatibility (no vendor lock-in), the release policy, a clear division of responsibilities between provider and user, and the overall cost model: list price plus internal engineering costs.

FAQ

What is managed Kubernetes?

A service in which the cloud provider manages the Kubernetes control plane (provisioning, updates and availability). The user manages workloads and node pools, but not the cluster’s critical infrastructure.

What is the difference between managed Kubernetes and a PaaS?

A PaaS handles the build, deployment and execution of what you deliver (source code or a container image) without requiring you to define the underlying orchestration. Managed Kubernetes retains the standard Kubernetes interface (kubectl, Helm and YAML manifests), allowing you to manage these primitives while delegating control plane operations to the provider. These are two distinct operational models that are complementary rather than interchangeable.

Does managed Kubernetes create a risk of vendor lock-in?

It depends on the implementation. A vanilla offering (with no changes to Kubernetes’ native behaviour and no proprietary tooling imposed) allows workloads to be migrated without rewriting them. By contrast, non-standard CRDs or provider-specific networking integrations can create dependency on a specific provider.

Who is responsible for what in a managed Kubernetes cluster?

The provider manages the control plane: updates, availability and patching. The user remains responsible for node pools (sizing and scaling), workloads, application security and RBAC policies.

How can I tell whether my organisation needs managed Kubernetes rather than a PaaS?

The key question is architectural complexity. If your applications require orchestration across multiple services or advanced networking capabilities, or are already designed for Kubernetes, managed Kubernetes is appropriate. If you are deploying relatively standard services, a PaaS will usually be faster and less expensive to operate.

Managed Kubernetes in France: what sovereign options are available?

In France, several providers offer managed Kubernetes on sovereign infrastructure, including Scaleway (Kubernetes Kapsule), OVHcloud (Managed Kubernetes Service) and Clever Cloud with CKE. Beyond location, the key differentiators are the actual level of sovereignty (operator, subcontractors involved in the hosting chain), vanilla compatibility and the shared responsibility model between provider and user.

This article distinguishes three things that are often confused: what certification guarantees, what it does not cover, and what to check before entrusting health data to a provider. It also presents the changes associated with version 2.1 of the standard, particularly those concerning contracts, remote access and exposure to third-country legislation.

HDS Certification and HDS Compliance: Two Distinct Concepts

Certification is a status granted to the hosting provider following an audit. Compliance is an obligation shared by the hosting provider and its client. Confusing the two creates a false sense of security: the belief that outsourcing to a certified provider is enough to fulfil all of one’s own obligations.

What the Certified Hosting Provider Is Responsible For

Certification is issued by an accredited body following an audit of the activities included in the requested scope. It confirms that the hosting provider meets the requirements applicable to the activities covered by its certificate. The HDS standard distinguishes six activities, but a certificate may cover only some of them.

What Remains the Client’s Responsibility

Using a certified hosting provider does not make the client certified. By using a certified provider, the client fulfils the obligation to engage a certified provider for the hosting activities concerned. Its application-related, contractual and GDPR obligations remain its own. The standard also imposes a specific requirement: hosting health data requires a dedicated contract between the client and the hosting provider, setting out, among other things, the scope of the services and the allocation of responsibilities.

What Certification Confirms, and What It Does Not Cover

The Scope of the Six Activities: Partial Certification Leaves Areas Uncovered

The HDS standard distinguishes six activities, ranging from providing physical sites to outsourced backup, including the administration and operation of the information system. An offering may be certified for only part of this scope, such as certain infrastructure layers. In that case, administration and operation or backup remain outside the certified scope, and addressing that gap becomes the client’s compliance responsibility. Checking the exact scope of certification, activity by activity, is therefore a prerequisite, not a minor detail.

The Boundary Between Hosting Security and Legal Sovereignty

Certification confirms compliance with the standard’s technical and organisational requirements, which also impose transparency obligations concerning certain legal risks. It does not, however, guarantee that a hosting provider or one of its subcontractors cannot be legally compelled to disclose data. A provider may meet the standard’s security requirements while remaining subject to non-European legislation. The French Court of Auditors states this unambiguously: at present, the HDS standard does not include the sovereignty requirements specific to SecNumCloud qualification, particularly those concerning ownership and protection against extraterritorial legislation. An HDS-certified hosting provider is therefore not automatically immune from these laws.

HDS Certification and Extraterritorial Laws (Cloud Act, FISA)

What HDS Regulations Actually Require

The regulatory framework became stricter in early 2026. Decree No. 2026-209 of 24 March 2026, published in the Journal officiel on 26 March and implementing Article 32 of the SREN Act of 21 May 2024, incorporated into the French Public Health Code obligations that had previously appeared only in the certification standard. Its new Article R. 1111-9-1 establishes the principle that health data must be stored exclusively within a member state of the European Union or a state party to the European Economic Area (EEA) Agreement. A transfer to a third country, including through remote access, remains possible, but subject to the conditions of the GDPR: a European Commission adequacy decision or, failing that, appropriate safeguards.

The decree also strengthens the hosting contract and the information that must be provided to the client. In particular, the hosting provider must specify any remote access from third countries, non-European laws that may require data disclosure within the meaning of Article 48 of the GDPR, the mitigation measures in place and the residual risks. It also creates a transparency obligation: to publish and keep up to date a map of transfers outside the EEA, remote access and risks of unauthorised access by third countries.

These provisions entered into force on 26 September 2026; the decree’s other amendments have applied since 27 March 2026.

HDS v2.1: what changes compared with version 2 of the standard

The decree thus establishes the new regulatory framework. Version 2.1 of the HDS standard, presented by the French Digital Health Agency, aims to align the certification scheme with that framework. This targeted update specifies, in particular, how obligations relating to transfers, remote access and third-country legislation must be documented in contracts and checked during audits.

Specifically, when a hosting provider is not subject to any third-country legislation that could compel it to transfer personal health data, this must be stated in its existing and future contracts. When a transfer to a country outside the EEA takes place, the contract must specify, in particular, the reason for the transfer, the data concerned, the destination country and the applicable safeguards. Remote access from a country outside the EEA is also considered a transfer.

Version 2.1 also provides that third-party archiving providers authorised by the French state to archive personal health data digitally must be HDS-certified for that activity.

Version 2.1 takes effect three months after its publication. No additional audit is required for hosting providers that are already certified: their compliance is checked during their first surveillance or renewal audit conducted under the new standard. From the date it takes effect, initial audits are also conducted under version 2.1.

Clever Cloud is currently HDS v2-certified for all six activities and is applying the announced version 2.1 requirements in advance. Compliance with those requirements will be checked during its next surveillance audit.

What HDS Certification Does Not Guarantee

HDS certification does not eliminate extraterritorial risk. The regulations require the hosting provider to inform its client, but they do not guarantee the absence of exposure. The Health Data Hub illustrates this distinction: the CNIL notes that the platform chose Microsoft Ireland to host data that must be stored in data centres in France. It nevertheless observes that this provider belongs to a group whose parent company is established in the United States, creating a legal possibility of disclosure requests from US authorities. Storing data in France is therefore not, in itself, enough to remove legal exposure.

Legal Immunity and Sovereignty: Two Distinct Requirements

For the most sensitive data (large health databases, data concerning minors and data relating to criminal offences), the CNIL recommends using either a hosting provider subject exclusively to European law or a provider with SecNumCloud qualification, which includes a criterion of immunity from non-European laws.

One distinction is worth making. The qualification provides legal immunity, but it can coexist with technological dependence: some qualified offerings may rely on non-European technologies. Sovereignty therefore cannot be inferred from a single label; it also depends on the provider’s ownership structure and the origin of its technology.

This recommendation concerns the most sensitive processing activities and does not, in itself, amount to a general ban on using an HDS-certified hosting provider exposed to third-country legislation. The appropriate approach is to assess the risk in light of the sensitivity of the data being processed.

Checking a Hosting Provider’s Actual Compliance

Certificate Validity and Accreditation

An expired certificate is no longer valid, even if a renewal process is under way. Two straightforward checks are needed: is the certificate still valid, and is the body that issued it accredited by COFRAC or an equivalent European body for HDS certification? A hosting provider’s status can also be checked in the official register of certified hosting providers maintained by the French Digital Health Agency.

Location of Storage and Operations

A lack of portability creates technical dependence that may prevent future compliance, for example if a migration to a sovereign solution becomes necessary. As for transparency, the map of transfers outside the EEA required by the regulations provides a direct point of verification: its absence is a warning sign.

These points can be checked systematically using our checklist of ten points to verify concerning the sovereignty of an HDS hosting provider.

Reversibility and Transparency of Transfers

A lack of reversibility creates a technical dependency that may prevent future compliance, for example if a migration to a sovereign solution becomes necessary. In terms of transparency, the map of transfers outside the EEA made mandatory by the regulations provides a direct control point: its absence is a warning sign.

These points can be assessed systematically using our ten-point assessment framework for evaluating the sovereignty of an HDS hosting provider.

Clever Cloud’s Position

Clever Cloud is HDS-certified for all six activities under the standard. On extraterritorial exposure, our guarantee is based on our legal and operational structure rather than an offering that already has SecNumCloud qualification: our registered office is in France, our capital is European, we have no subsidiary in the United States, HDS hosting and operations are carried out in France, and we commit not to transfer any health data outside the EEA. This structure places Clever Cloud’s HDS activities under European jurisdiction and outside the scope of extraterritorial laws such as the CLOUD Act or FISA.

FAQ

Does HDS Certification Provide Protection Against the Cloud Act?

No. The certification attests to the security of health data hosting. It is not intended to provide immunity from extraterritorial laws. Depending on its ownership structure, a certified hosting provider may remain subject to non-European legislation.

Can an HDS-Certified Hosting Provider Be Subject to US Law?

Yes, when its parent company is subject to US law. An entity may hold HDS certification and store data in France while remaining within the reach of the Cloud Act or FISA.

Must health data be stored in France?

No. The French HDS framework and Decree No. 2026-209 of 24 March 2026 require storage exclusively within the European Economic Area (the EU plus Norway, Iceland and Liechtenstein) rather than on French territory specifically. The rule is codified in Article R. 1111-9-1 of the French Public Health Code. Remote access from a third country remains possible, but only under the conditions set out in Chapter V of the GDPR (adequacy decision or appropriate safeguards), and it must be disclosed to the customer in the hosting agreement. Hosting located in France is therefore a contractual commitment made by the provider, not a regulatory requirement.

Does Using a Certified Provider Make Me “HDS Compliant”?

No. Certification belongs to the hosting provider. By using a certified provider, the client fulfils the obligation to entrust the relevant hosting activities to a certified hosting provider, within the scope covered by the certificate and the contract. Its application-related, contractual and GDPR obligations remain its responsibility.

HDS and SecNumCloud: What Is the Difference?

HDS certification governs the security and conditions of health data hosting. SecNumCloud qualification, issued by ANSSI, adds technical, operational and legal requirements, including criteria for protection against non-European law and rules concerning ownership and control. At present, HDS does not provide the same level of assurance on these points.

Article updated on 30 October 2026.

The remaining questions are when such an operation becomes necessary, how it is carried out, and which pitfalls should be anticipated.

What is an HDS migration?

An HDS migration is more than a simple infrastructure change: it involves transferring personal healthcare data whose hosting is regulated by law. The objective can be summed up in a single sentence: change hosting providers without leaving the compliance framework, either during or after the migration.

HDS certification itself remains the responsibility of the hosting provider under the HDS framework and its six regulated activities. Migrating does not invalidate this compliance; the objective is to preserve it throughout the transition from one hosting environment to another.

When should you consider an HDS migration?

Three situations justify switching the hosting environment for healthcare data.

Hosting that is not HDS certified

In France, entrusting healthcare data to a hosting provider requires that provider to hold HDS certification (Article L.1111-8 of the French Public Health Code). An e-health application deployed on non-certified infrastructure therefore falls outside this regulatory framework, regardless of its technical quality. Migrating to a certified hosting provider addresses the hosting requirement, although it does not by itself fulfil the publisher’s other obligations, whether application-related or under the GDPR.

Hosting that is not sovereign or is subject to extraterritorial legislation

Certification and legal sovereignty are not the same thing. A hosting provider may be HDS certified while still being subject to non-European legislation that could require the disclosure of data, such as the Cloud Act or FISA. For the most sensitive healthcare data, the CNIL recommends enhanced protection against access requests from third-country authorities, including hosting operated exclusively under European law. The distinction between HDS compliance and sovereignty deserves separate consideration; in the context of a migration, it mainly becomes a hosting provider selection criterion.

Operational overhead on self-managed infrastructure

Infrastructure may be compliant while still being managed in-house, typically on bare metal. In this case, internal teams remain responsible for server configuration, monitoring, upgrades, and reversibility. As the platform grows, this operational burden becomes increasingly significant. It often leads software vendors that are already HDS compliant to adopt a managed platform, reducing operational workload without compromising compliance.

Key considerations for an HDS migration

Five recurring pitfalls deserve particular attention. Each one should prompt a question to your future hosting provider.

How do you choose an HDS hosting provider for your migration?

Five criteria make the difference:

• Certification covering all six activities defined by the HDS framework, not just the infrastructure layer.
• A valid certificate issued by an accredited certification body.
• Genuine sovereignty: headquarters and ownership based in France, no subsidiary subject to non-European law, and hosting infrastructure located in France.
• A fully managed platform that takes care of encryption, monitoring, backups, and updates instead of leaving these responsibilities to the customer.
• Documented reversibility, ensuring an exit strategy without technical lock-in.

The last criterion deserves particular attention: a platform that operates an HDS cloud end to end relieves customers of the operational layers where most compliance gaps tend to arise.

Case study: the Madietenligne migration

Clever Cloud supports several e-health providers. The migration of Madietenligne, a platform dedicated to dietitians, provides a documented example: it moved from self-managed bare-metal infrastructure to Clever Cloud’s sovereign PaaS while remaining within the HDS framework. This case illustrates a migration driven by the need to reduce operational overhead rather than to move from a non-compliant to a compliant environment: the HDS framework was already being met before the migration.

Key highlights:

• Test and production environments migrated in less than fifteen days.
• 500 GB of data transferred and synchronized.
• Platform used by more than 2,500 dietitians.
• Zero-downtime deployments, with support responding within the same business day.
• HDS compliance maintained, encryption at rest enabled, and migration away from Azure for file storage, removing a dependency on a provider subject to U.S. law.

Key takeaways from an HDS migration

A well-executed HDS migration answers three questions, in order: why migrate, how to migrate, and how to verify compliance. The process is manageable, service interruption is limited to the DNS switch, and compliance can be verified at every stage.

To assess your current situation or prepare your migration project,

FAQ

How long does an HDS migration take?

The duration depends on the data volume, the architecture, and the number of environments involved. As a reference point, one documented project covering both test and production environments was completed in less than fifteen days. This figure applies only to that specific case and should not be taken as representative of every migration.

Does an HDS migration cause service downtime?

As long as the legacy and the new hosting environments coexist, the service remains available. The only possible interruption occurs during the DNS switch; when properly prepared, it is imperceptible to users.

Is a new contract required for an HDS migration?

Yes. Hosting healthcare data requires a dedicated agreement with the hosting provider under the HDS framework. It must be signed before the production environment goes live.

After the migration, what remains my responsibility to stay HDS compliant?

HDS certification remains the responsibility of the hosting provider. The software publisher remains responsible for application compliance and GDPR compliance. The migration brings the hosting component into compliance, but it does not cover all regulatory obligations.

Can I migrate from a non-sovereign hosting provider such as Azure or AWS?

Yes. One purpose of an HDS migration may be to remove a dependency on a hosting provider subject to non-European legislation, for example by moving away from file storage operated by a non-European provider.

In short: K3s is a CNCF-certified Kubernetes distribution optimized for constrained environments (edge, IoT, labs). K8s refers to the original Kubernetes project, designed for large-scale production clusters. The choice depends on your available resources, deployment context and operational requirements.

K8s: Standard Kubernetes for Enterprise Environments

K8s is the abbreviation of Kubernetes, with the “8” representing the eight letters between the “K” and the “s”. It is the original open-source project maintained by the Cloud Native Computing Foundation (CNCF) and initially developed by Google.

Kubernetes is designed for large-scale production environments: multi-node clusters, high availability, integration with public clouds (AWS, GCP, Azure), or on-premises datacenters. Its control plane includes several separate components: API server, scheduler, controller manager, etcd, deployed independently, which provides maximum flexibility but requires significant operational expertise.

Typical requirements for a production control plane node: at least 2 vCPUs and 2 GB of RAM for Kubernetes components alone, excluding etcd and application workloads.

K3s: A CNCF-Certified Kubernetes Distribution, Not a Fork

K3s is a certified Kubernetes distribution, not an unofficial lightweight version or a fork. Created by Rancher Labs, it was donated to the CNCF in June 2020 and passes the same Sonobuoy conformance tests as all certified distributions. Any valid Kubernetes manifest works on K3s.

Its main goal is to drastically reduce the resources required to run Kubernetes in constrained environments (edge, IoT, CI/CD, labs) without giving up API compatibility.

What K3s Changes Compared to K8s

• A single binary under 70 MB (supporting x86, ARM64, ARMv7, and S390X), including the containerd runtime, Flannel CNI, a Traefik ingress controller, and a Klipper load balancer.
• SQLite as the default datastore in single-node mode instead of etcd. In high-availability configurations (minimum three server nodes), K3s can use embedded etcd or an external datastore (MySQL, PostgreSQL, external etcd).
• Alpha and beta components removed to reduce the attack surface and memory footprint.

Important point: K3s does not remove etcd; it makes it optional. In single-node mode, SQLite is sufficient. In high availability, embedded or external etcd is supported - although the latter is not officially supported by the K3s team.

Resource Footprint

K3s can run with as little as 512 MB of RAM on an agent node. According to the official documentation (updated May 2026), a server node (control plane) requires 2 GB of RAM and 2 CPU cores, excluding application workloads. A load-tested profile is available in the K3s resource profiling guide. It is worth noting that tests on hardware with 1 GB of total RAM showed instability across K3s, k0s, and MicroK8s when deploying real application workloads (even a lightweight Kubernetes cluster still consumes non-negligible control-plane resources).

Key Technical Differences

Datastore

Runtime and packaging

K8s no longer provides a default runtime since the removal of dockershim (v1.24, 2022). Starting with Kubernetes 1.24, you must install a CRI-compatible runtime (containerd or CRI-O). K3s embeds containerd directly into its binary.

Control Plane Architecture

In K8s, control plane components (API server, scheduler, controller manager) are separate processes. In K3s, they are merged into a single binary, which reduces overhead but limits some advanced isolation configurations.

Scalability

K3s is suitable for moderately sized clusters. In high-availability configurations (3 server nodes, 4 vCPU / 8 GB RAM), the official documentation indicates a capacity of around 1,200 agents. For very large clusters (several thousand nodes), K8s remains the standard choice.

K3s vs K8s Comparison Table

Use Cases: Which One Should You Choose?

Choose K3s if:

• You deploy on constrained hardware (Raspberry Pi, industrial appliances, edge servers with limited RAM).
• You manage remote IoT or edge clusters, potentially in disconnected environments.
• You need a development or CI cluster that starts quickly, including on modest hardware.
• You want an operational cluster with minimal initial configuration.

Choose K8s (or an enterprise distribution) if:

• You orchestrate hundreds or thousands of production nodes.
• Your workloads require advanced cloud-native integrations (storage, load balancers, IAM) provided by hyperscalers.
• You need alpha or beta API components unavailable in K3s.
• Your organization has a dedicated SRE team operating clusters.

Hybrid Use Cases: K3s and K8s Together

K3s and K8s are not mutually exclusive. Several hybrid architectures are documented in production:

Fleet Management with Rancher

Edge K3s clusters are managed from a central control plane running on K8s or RKE2. The Home Depot, a major US retailer with more than 2,300 stores, manages its sites using K3s clusters administered through Rancher.

K3s for Dev and Staging, K8s for Production

API compatibility guarantees that manifests and Helm charts tested on K3s work in production on an enterprise cluster. This parity reduces surprises when promoting environments.

CI/CD

Test pipelines run on K3s (low cost, fast startup) while production environments use managed K8s clusters.

Managed Kubernetes: A Third Path

Neither K3s nor K8s solves the question of daily operations: updates, certificates, control plane monitoring, or failure management. This is precisely what managed Kubernetes solutions cover.

Hyperscalers (EKS, GKE, AKS) provide this management within their own clouds. But managed solutions also exist outside these ecosystems, especially for organizations that want to retain control over their data and choose sovereign Kubernetes, or even French-operated Kubernetes.

Clever Kubernetes Engine (CKE) is Clever Cloud’s managed Kubernetes service, designed for teams already using Kubernetes and wanting to delegate control plane management (updates, high availability, monitoring) without being constrained to a single hyperscaler. CKE explicitly targets teams that are not fully covered by the traditional  PaaS model (multi-runtime use cases, non-twelve-factor workloads, or the need for granular resource control).

FAQ

Is K3s a Kubernetes fork?

No. K3s is a CNCF-certified Kubernetes distribution. It passes Sonobuoy conformance tests and supports the same APIs as K8s. It is not maintained separately from Kubernetes: it follows upstream Kubernetes releases.

Can K3s Be Used in Production?

Yes, with some nuances. K3s is documented for production workloads in constrained environments (edge, IoT). For large-scale clusters or critical workloads with high SLA requirements, K8s (or an enterprise distribution such as RKE2) is more appropriate.

Does K3s Support Helm?

Yes. K3s includes an integrated Helm controller and is compatible with any valid Helm chart.

What Is the Difference Between K3s and K3d?

K3d is a tool that runs K3s inside Docker containers. It further simplifies the creation of local K3s clusters for development, but it is not intended for production use.

Does K3s Run on ARM?

Yes. ARM64 and ARMv7 are natively supported, which explains its popularity on Raspberry Pi devices and industrial appliances.

Managed Kubernetes vs Self-Hosted K3s: Which One Should You Choose?

Self-hosted K3s gives you full control but makes you responsible for operations (updates, security, high availability). Managed Kubernetes delegates this responsibility to an operator, at the cost of dependency on that provider. The choice depends on your operational resources and control requirements.

The Kubernetes vs Docker question deserves a precise answer, because the two technologies do not solve the same problem.

Docker is mainly used to build and run containers. Kubernetes is used to orchestrate those containers once the infrastructure becomes more complex. The two technologies are therefore often complementary, even though they are frequently, and incorrectly, presented as opposites.

Understanding this distinction helps clarify when Docker alone is enough, when Kubernetes becomes relevant, and why not every application actually needs a Kubernetes cluster.

Docker: Standardizing Application Execution

Docker popularized modern containerization. Its goal is simple: make applications run the same way regardless of the environment in which they are executed.

Before Docker, it was common for an application to work perfectly on a developer’s machine but fail once deployed to a server. Differences in system versions, missing dependencies, or inconsistent configurations made deployments significantly more difficult.

Docker largely solved this problem by packaging an application and its dependencies into an isolated container. In practice, the container includes the application itself, its libraries, dependencies, and some system components required for execution.

The environment becomes portable and reproducible. A Docker image can run on any compatible machine with predictable behavior. This standardization explains Docker’s massive adoption across CI/CD pipelines, development environments, and modern architectures.

Docker Is Not Just About “Running Containers”

In many teams, Docker has become an everyday tool. A developer can locally run a Node.js API, a PostgreSQL database, Redis, or an Nginx service without manually installing each component on their machine. Everything runs inside isolated containers.

This approach greatly simplifies local development, testing, demo environments, continuous integration, and application deployments.

For relatively simple applications, Docker alone may be sufficient. This is especially true when a team manages only a few services, operates a limited infrastructure, has limited scaling requirements or needs little operational automation. In such situations, adding Kubernetes may actually introduce unnecessary complexity.

Where Docker Reaches Its Limits

Docker works extremely well for running containers. However, it does not automatically solve large-scale orchestration challenges.

As the number of services grows, several questions quickly emerge:

• How do you distribute containers across multiple servers?
• How do you automatically restart a failed service?
• How do you perform updates without downtime?
• How do you automatically absorb traffic spikes?
• How do you monitor dozens or hundreds of distributed workloads?

Docker was not designed to handle this level of operational complexity on its own. That is precisely the role of container orchestration, where Kubernetes has become the most widely adopted standard.

Kubernetes: Automating Container Operations

Kubernetes is a container orchestrator. Its goal is not to replace Docker for image creation or containerization logic. Kubernetes operates at a higher level: infrastructure automation and operations management.

It can automatically deploy applications, distribute workloads across multiple machines, restart failed containers, manage high availability, perform auto-scaling, and orchestrate distributed architectures.

In other words, Docker runs containers, while Kubernetes coordinates them across a cluster. That distinction is essential.

A Practical Example: Docker Alone vs Kubernetes

Consider a modern e-commerce platform. Initially, the application may remain relatively simple: a backend, a frontend, and a database. Docker is often enough to run this stack.

But over time, the architecture evolves: multiple microservices appear, some components need to scale independently, message queues are introduced, several environments must remain synchronized, availability becomes critical.

At that point, manually managing every container quickly becomes difficult. Kubernetes introduces automation mechanisms such as automatic workload recovery, load distribution, service replication, rolling deployments, and automatic reconciliation of the desired cluster state.

This is why Kubernetes has become the de facto standard for cloud-native orchestration.

Kubernetes vs Docker: Does One Replace the Other?

This is one of the most common questions, and the answer is clear: Kubernetes does not replace Docker.

For many years, Kubernetes used Docker as its container runtime. That is no longer the default behavior. Starting with version 1.20 (December 2020), Kubernetes deprecated direct Docker support through the “dockershim” component. This support was fully removed in Kubernetes 1.24, released in May 2022.

Since then, Kubernetes has relied on CRI-compatible runtimes (Container Runtime Interface) such as containerd or CRI-O.

This change has little impact on developers in day-to-day workflows. Docker-built images comply with the OCI (Open Container Initiative) standard and remain fully compatible with Kubernetes. The image format itself did not change: only the runtime layer inside Kubernetes clusters evolved.

In practice, Docker and Kubernetes still work together in many environments. Docker is used to build and test images locally. Kubernetes deploys and orchestrates them in production.

The confusion often comes from the fact that Docker was historically used at both stages of the container lifecycle. That is no longer true on the Kubernetes runtime side, but Docker remains heavily used for builds and development.

The Kubernetes vs Docker distinction is therefore not about replacement, but about roles: each technology operates at a different stage of the containerized application lifecycle.

When to Use Docker Without Kubernetes

Docker alone remains highly relevant in many situations. It is often the right choice for simple projects, internal applications, development environments, prototypes, small web platforms, or infrastructures with limited operational requirements.

In these scenarios, Kubernetes may represent significant operational overhead compared to the actual needs. In some cases, a lightweight distribution such as K3S may also be more appropriate than a full Kubernetes cluster.

Clever Cloud explicitly recognises that Kubernetes is not the best choice for every application, including in the positioning of  Clever Kubernetes Engine (CKE), its managed Kubernetes platform.

When Kubernetes Actually Becomes Useful

Kubernetes becomes valuable when an architecture requires advanced orchestration capabilities. This is especially true when multiple services must be coordinated, when deployments become frequent, when resilience becomes critical, when workloads fluctuate significantly, when teams already use GitOps practices, or when infrastructure becomes distributed or hybrid.

Some organizations also use Kubernetes to standardize deployments across multiple environments or cloud providers. In this context, choosing a managed Kubernetes platform often becomes central to reducing operational burden.

This is precisely the type of use case behind solutions such as CKE, designed to remain compatible with standard Kubernetes ecosystem tools while integrating with the broader Clever Cloud platform. 

Kubernetes or PaaS: They Are Not Always Competing Approaches

Another common misconception is that Kubernetes necessarily replaces a PaaS (Platform as a Service). In practice, many applications run perfectly well on a traditional PaaS with less operational overhead and less complexity.

Even within the context of CKE, the positioning is explicit: Kubernetes does not replace the PaaS. The two address different operational models, not different levels of complexity: the PaaS takes care of operations, Kubernetes gives you control over them. Both run serious production workloads. The goal is therefore not to move every application onto Kubernetes, but to use it when it provides real technical or operational value.

Docker vs Kubernetes: Key Differences to Remember

Docker and Kubernetes Are Not Competing Technologies

The Kubernetes vs Docker question is not really about choosing one over the other: each addresses a different need at a different stage of the application lifecycle.

Docker simplified the creation and execution of containerized applications. Kubernetes automated their operation at scale.

Not every application needs Kubernetes. In many cases, Docker alone is enough. When teams want to delegate application operations entirely, a PaaS can manage them, including for distributed architectures and applications with demanding resilience requirements. Kubernetes, for its part, becomes relevant when you need explicit control over orchestration, integration with the CNCF ecosystem, or multi-cloud portability on open standards. It is a choice of operational model and team needs, not a level of application complexity.

The real challenge is therefore not choosing "Docker or Kubernetes," but recognizing the point at which your orchestration needs make Kubernetes genuinely worthwhile.

FAQ

Are Docker and Kubernetes competitors?

No. Docker and Kubernetes address different needs. Docker is mainly used to build and run containers, while Kubernetes orchestrates them at scale.

Does Kubernetes replace Docker?

No. Since Kubernetes version 1.24 (May 2022), Docker is no longer used as the cluster’s internal runtime. Kubernetes now relies on CRI-compatible runtimes such as containerd or CRI-O. However, Docker images, which comply with the OCI standard, remain fully compatible with Kubernetes.

Why Has Kubernetes Become a Standard?

Kubernetes became the dominant standard thanks to its declarative model, portability across environments, and the cloud-native ecosystem built around the CNCF, where it has been a graduated project since 2016. Its ecosystem includes tools such as Helm, Prometheus, and Argo CD.

What Is the Difference Between K3S and Standard Kubernetes?

K3S is a lightweight Kubernetes distribution designed for edge environments, IoT, development, or small clusters, with lower resource consumption than standard Kubernetes.

Is Managed Kubernetes Better?

In many organizations, yes. Managed Kubernetes reduces the operational burden associated with the control plane, updates, security, and cluster resilience. This is the approach taken by  Clever Kubernetes Engine (CKE).

In this context, the question is no longer whether to migrate, but how to structure what already exists, maintain control over day-to-day operations, and retain ownership of environments and data.

On Tuesday 28 April at 11:30 AM, Clever Cloud and Cycloid are hosting a webinar to address these challenges.

Two complementary perspectives on a shared challenge

We are offering a cross-functional discussion to provide concrete insight into these topics.

Cycloid covers the structuring and governance of environments through a unified internal developer platform and portal. Clever Cloud addresses managed operations, operational maintenance (MCO) and operational sovereignty.

Join Florent Perreux (Chief Sales Officer @ Clever Cloud), Steven Le Roux (CTO @ Clever Cloud), Alexandre Blin (Business Director SEMEA @ Cycloid) and Olivier de Turckheim (Solution Architect @ Cycloid) to understand how to align governance and operations without adding complexity.

Agenda

🔹 Why cloud modernisation goes beyond migration;plus à une migration;

🔹 Structuring and governance challenges in multi-cloud environments;

🔹 Operational challenges related to operations and maintenance;

🔹 How to align governance and operations without multiplying complexity;

🔹 A live Q&A session to ask your questions directly.

Why attend?

✅ Understand the root causes of complexity in cloud projects;

✅ Identify the levers to structure your usage and reduce vendor dependency;

✅ Gain a clearer understanding of operational and sovereignty challenges;

✅ Benefit from concrete real-world experience;

✅ Engage directly with experts.

Register now

🗓️ Tuesday 28 April 2026

⏰ 11:30 AM – 12:00 PM

💻 Online webinar on Livestorm

Facing these challenges? Join us on 28 April!