workloads and node pools but does not administer the cluster’s critical infrastructure.

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 exclusive 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 multi-service orchestration, advanced networking interactions 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 between three concepts that are often confused: what the certification guarantees, what it leaves out, and the points to check before entrusting health data to a provider.

HDS Certification and HDS Compliance: Two Distinct Concepts

Certification is a status granted to the hosting provider following an audit. Compliance, however, is an obligation that remains shared between the hosting provider and its client. Confusing the two creates a false sense of security: the belief that outsourcing to a certified provider is sufficient to cover all of an organisation’s own obligations.

What the Certified Hosting Provider Is Responsible For

Certification is issued by an accredited body following an audit covering the six activities defined in the HDS framework. It attests that the hosting provider maintains a defined level of security for hosting, operating and backing up personal health data.

What Remains the Client’s Responsibility

Using a certified hosting provider does not make the client itself certified. The certification remains that of the hosting provider; the client is brought into compliance only with regard to the hosting component. Its application-level obligations and its obligations under the GDPR remain its own. The framework also imposes a specific requirement: hosting health data requires a dedicated agreement between the client and the hosting provider, formalising the allocation of responsibilities.

What the Certification Attests to, and What It Does Not Cover

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

The HDS framework distinguishes between six activities, ranging from the provision of physical sites to outsourced backup, as well as the administration and operation of the information system. An offering may be certified for only part of this scope, often limited to the infrastructure layers. In such cases, administration and operation or backup remain outside the certified scope, and the resulting gap becomes a compliance burden for the client. Checking the exact scope of the certification, activity by activity, is therefore a prerequisite, not a detail.

The Boundary Between Hosting Security and Legal Sovereignty

The certification attests to the technical and organisational security of the hosting service. It says nothing about the legal issue of who may be legally compelled to disclose the data. These are two separate matters. A hosting provider may meet the security requirements of the framework while remaining subject to non-European legislation. The French Court of Accounts states this unambiguously: at this stage, the HDS framework does not include the sovereignty requirements specific to the SecNumCloud qualification, particularly ownership control 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 framework was tightened in early 2026. Decree No. 2026-209 of 24 March 2026, published in the French Official Journal on 26 March and adopted pursuant to Article 32 of the SREN Act of 21 May 2024, incorporates into the French Public Health Code obligations that had previously existed only in the certification framework. Its new Article R. 1111-9-1 establishes the principle that health data must be stored exclusively within the territory of a Member State of the European Union or a state party to the Agreement on the European Economic Area (EEA). A transfer to a third country, including in the form of remote access, remains possible, but only under the conditions set out in the GDPR: an adequacy decision by the European Commission or, failing that, appropriate safeguards.

The decree also strengthens the hosting agreement and the information that must be provided to the client. The hosting provider must specify remote access from third countries, non-European legislation that may require the disclosure of data within the meaning of Article 48 of the GDPR, mitigation measures and residual risks. It also introduces a transparency obligation that did not previously exist: the publication and ongoing maintenance of a map of transfers outside the EEA, remote access and the risks of unauthorised access by third countries.

However, these structural provisions will only enter into force six months after publication, at the end of September 2026; the other amendments have applied since the day following the publication of the decree.

What HDS Certification Does Not Address

The extraterritorial risk itself. The regulations require the hosting provider to provide information, not to guarantee immunity. A hosting provider may be HDS certified, store data in France and still be within the reach of non-European legislation when its parent company is subject to that legislation. Microsoft Ireland illustrates this situation: the entity holds HDS certification and stores data in France, but cannot obtain the SecNumCloud qualification because it belongs to a group subject to US law. Storing data within national territory is necessary, but it is not sufficient to eliminate legal exposure.

Legal Immunity and Sovereignty: Two Distinct Requirements

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

One nuance should be noted. The qualification provides legal immunity, but it may coexist with technological dependency: some qualified offerings rely on US components operated under licence. Sovereignty cannot therefore be inferred from a single certification or qualification; it also depends on the provider’s ownership structure and the origin of its technology.

This recommendation applies to the most sensitive processing operations. Outside these cases, using a non-sovereign HDS hosting provider remains permitted: the CNIL states that no penalty has been imposed solely on the grounds that a non-sovereign hosting provider was used. The appropriate approach is not to decide on principle, but to assess the risk according to the sensitivity of the data being processed.

Assessing a Hosting Provider’s Actual Compliance

Certificate Validity and Accreditation

An expired certificate, a certificate undergoing renewal or one issued by a non-accredited body does not provide the expected assurance. Two straightforward checks should be carried out: is the certificate currently valid, and is the body that issued it accredited by COFRAC for the HDS framework? 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

Storing data in France is necessary, but it does not eliminate the risk on its own. Remote access for administration or operations from a third country reintroduces exposure, even when the data remains stored within France. The appropriate questions to ask the provider therefore cover both aspects: where is the data stored, and from which country and by which teams is the platform administered?

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 across the entire scope of the framework. Regarding extraterritorial exposure, our guarantee is not based on holding our own SecNumCloud qualification, but on our legal status: French ownership and registered office, no subsidiary in the United States, hosting and operations carried out in France, and a commitment not to transfer any health data outside the European Economic Area. This structure places the company exclusively under European law.

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. The certification remains that of the hosting provider. The client is brought into compliance only with regard to the hosting component; its application-level and GDPR obligations remain, as does the requirement to sign a dedicated hosting agreement.

HDS and SecNumCloud: What Is the Difference?

HDS certification is mandatory for hosting health data and attests to the security of that hosting. The SecNumCloud qualification, issued by the ANSSI, is voluntary and notably includes a criterion of immunity from non-European laws. To date, the HDS framework does not include the sovereignty requirements specific to SecNumCloud.

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 workload.

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 reference.

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 (large American retailer with more than 2,300 stores) manages its sites using K3s supervised 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 low scalability 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. Kubernetes organizes their global behavior. 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 historically existed at both stages. 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.

Kubernetes is not automatically the best answer for every application, a position explicitly acknowledged at  Clever Cloud, including in the context of the launch of  Clever Kubernetes Engine (CKE), a managed Kubernetes platform developed and operated by Clever Cloud.

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: It Is Not Always a Duel

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. And to fully delegate operations, a PaaS takes over, including for distributed architectures and high 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!

This transformation is taking place within a context of cost reduction, rationalization of existing infrastructures, and the pooling of IT resources.

In this constrained environment, the question is not only which provider or technology to choose, but which application execution model is best suited to the project at hand. PaaS (Platform as a Service) is one of the available options, provided its benefits, limitations, and applicable frameworks are clearly understood.

Challenges and issues specific to the public sector

Public organizations face structural constraints that directly influence their technical decisions. Budget pressure is constant, with explicit objectives to control or even reduce IT operating costs. Technical teams are often understaffed, with recruitment challenges for specialized roles such as system administrators, developers, cybersecurity experts, and cloud or DevOps engineers.

In addition, public organizations often rely on a heterogeneous and sometimes aging application landscape, built on technologies or environments that are no longer maintained or are difficult to evolve. Security, availability, and regulatory compliance requirements are high, while project timelines must remain aligned with the operational needs of administrations, local authorities, and public institutions.

How PaaS can address these challenges in the public sector

Using a cloud platform can address part of these challenges, without being a universal solution. One of its main benefits is the reduction of operational workload. In practice, this means that operating systems, application runtimes, deployment processes, restarts, and monitoring mechanisms are managed at the platform level. Technical teams no longer need to handle day-to-day infrastructure management and can focus on developing, improving, and maintaining applications.

From a security and update perspective, an application hosting solution also helps maintain technical environments more consistently up to date. In the public sector, where legacy management is a key concern, this reduces risks associated with obsolete systems, unmaintained dependencies, and delayed security patching. While this approach does not eliminate existing legacy systems, it helps structure their operation and supports gradual modernization without requiring a full overhaul of the information system.

In this context, a PaaS for public services can be a relevant lever, provided it is selected for clearly identified use cases.

Not all public projects fall under the same deployment framework

Public sector digital projects vary widely. An internal business application, a citizen-facing digital service, a data platform, or a research project do not involve the same constraints or levels of requirements.

Some contexts, particularly those related to defense or the processing of sensitive information, require enhanced guarantees in terms of security, control, and sovereignty. In such cases, specific qualification frameworks such as SecNumCloud may be required, limiting the available technical options. PaaS is therefore not suitable for all scenarios, and its use must be assessed based on data sensitivity and applicable regulatory requirements.

Existing public frameworks for deploying PaaS

Contrary to common belief, public sector organizations already have operational frameworks to access compliant cloud and application hosting services.

For administrations and public institutions, using UGAP provides access to a national purchasing body with pooled and legally secure contracts.

At a regional level, initiatives such as La Fabrique IA Territoriale, led by GIGALIS, offer local authorities and institutions in the Pays de la Loire region a structured framework to access digital and cloud services, with a focus on mutualization and support.

In the healthcare sector, hospitals can rely on Resah, which references solutions tailored to the specific requirements of healthcare environments.

These frameworks do not define technical use cases but provide concrete access points to services compliant with public procurement regulations.

When PaaS is particularly relevant

A managed cloud model is especially well suited when the goal is to build a new application without the need to handle system administration. It is also relevant for modernizing or refactoring existing applications, where the main objective is to simplify operations while improving reliability and security.

For application projects requiring fast deployment cycles, better cost predictability, and reduced administrative overhead, a cloud offering for public sector organizations can be a consistent choice, provided the functional and regulatory scope is clearly defined.

Key considerations before making this choice

Before choosing a PaaS, several factors must be carefully evaluated: the actual scope of platform responsibility, reversibility conditions, data location and protection, and alignment between data sensitivity and the guarantees provided. These elements determine whether the model is appropriate and sustainable over time.

Are you working on an application project within a public service and wondering whether a PaaS model is relevant in your context?

Identifying the right contractual framework helps save time and ensures compliance with public sector digital projects.

Or access Clever Cloud directly via public platforms:
UGAP for administrations and public institutions, La Fabrique IA Territoriale for organizations in the Pays de la Loire region, and Resah for healthcare institutions.

At the same time, in its  summary published earlier this year, the cybersecurity body CERT-FR, operated by the French National Cybersecurity Agency (ANSSI), reports that 218 cyber incidents were handled in 2024 involving local authorities. In its 2024 activity report,
ANSSI also describes the cyber threat as “systemic” for the public and social sectors.

In this context, choosing a secure cloud solution for public administrations has become a central concern for CIOs, CISOs, and digital project managers.

The objective is not simply to select a high-performance infrastructure, but to ensure that the chosen cloud solution meets the legal, regulatory, technical, and operational requirements specific to the public sector.

Understanding what cloud security means in the public sector

The data handled by public administrations — personal data, health data, financial information, and sensitive data related to public infrastructures — are subject to strict regulatory frameworks, notably enforced by the CNIL and the GDPR. In addition, the public sector is expected to rely on recognised security certifications, such as ISO/IEC 27001, HDS for health data, and, for the most critical environments, SecNumCloud.

These requirements demonstrate that a secure cloud goes far beyond firewalls or encryption alone. It requires a comprehensive, structured, and auditable approach to security.

Digital sovereignty: a criterion that has become essential

For a public administration, it is essential to know where data is hosted and under which jurisdiction it falls, in order to comply with the GDPR and to properly govern any potential data transfers outside the European Union.

A sovereign cloud implies not only that data is hosted within the European Union, but also that it is not subject to extraterritorial legislation, such as the US Cloud Act (2018), which allows a foreign government to request access to data stored by a provider under its jurisdiction.

Digital sovereignty also contributes to the resilience of information systems. By limiting technical, contractual, or legal dependencies on a single provider, public administrations retain the ability to react quickly when constraints arise—for example, by changing providers or relocating a service when regulatory, operational, or strategic conditions require it. This margin of manoeuvre is an important factor in maintaining control and ensuring the long-term sustainability of public digital services.

Sovereignty is therefore a key differentiating criterion when choosing between a European provider and a US-based provider.

Beyond compliance: essential technical requirements

To ensure a level of security appropriate for the public sector, a cloud solution must provide strong isolation between environments, systematic encryption of data in transit and at rest, host hardening, as well as continuous monitoring mechanisms (logs, metrics, alerts).

Identity and access management (IAM), multi-factor authentication, and the application of the principle of least privilege are part of a Zero Trust approach, now recommended by ANSSI to reduce the attack surface.

Security also relies on operational resilience: service continuity, recovery capabilities, high availability, and fault-tolerant architectures.

The role of automation in risk reduction

Automation is often seen as a convenience for developers; in the public sector, it is above all a lever for reducing human-related risks.

Automated deployments, automatic scalability, and self-healing mechanisms help limit operational errors, which account for a significant proportion of security incidents.

By reducing the number of manual operations, organisations lower the risk of misconfiguration and improve the overall availability of services.

Total cost of ownership and governance

Choosing a secure cloud is not just a matter of comparing list prices.

Public sector organisations must take into account the notion of total cost of ownership (TCO):

• Infrastructure costs,
• Internal staffing costs,
• Operational complexity,
• Maintenance,
• Time spent handling incidents,
• Effort required to migrate a service or ensure its reversibility.

A platform that automates most operational tasks and enables reproducible environments can significantly reduce internal workload, and therefore the overall cost.

How to objectively assess market solutions

To evaluate a cloud solution intended for the public sector, it is essential to rely on factual criteria: the level of sovereignty, available certifications, technical capabilities, reversibility, the availability of private cloud or on-premise options, the existence of air-gapped environments, the quality of support, and compatibility with existing tools.

The most common mistakes include choosing a provider out of habit, focusing solely on price, or confusing data localisation with legal sovereignty.

Another recurring mistake is overestimating the complexity of migration. In many cases, a test or a Proof of Concept is sufficient to validate feasibility.

A simple method for choosing the right cloud solution

The most effective approach consists in:

This approach provides a balanced view of security, compliance, performance, and sustainability.

What Clever Cloud brings to these challenges

Clever Cloud is a European hosting provider certified ISO/IEC 27001:2022 and HDS, offering public cloud, private cloud, on-premise and air-gapped environments. For highly regulated requirements, a zone already qualified SecNumCloud is available on request through our partnership with Cloud Temple. This makes it possible to meet “trusted cloud” requirements while benefiting from the Clever Cloud platform.

The platform follows a security-by-design approach based on environment isolation, system hardening, strong authentication, and built-in observability.

Automated deployments, automatic scaling (auto-scaling), and self-healing mechanisms reduce operational effort and limit human error.

Data remains hosted in Europe, and data portability is ensured, with no proprietary lock-in.

Support is human-led and provided from France.

Finally, for public organisations that rely on pooled public procurement frameworks, it is worth noting that Clever Cloud is listed on the “Nuage Public” (UGAP) framework. Public administrations can therefore subscribe to our services within an already validated public purchasing framework, simplifying administrative procedures and accelerating service deployment.

Towards a secure, sovereign, and sustainable public cloud

For a public administration, choosing a secure cloud solution means finding the right balance between sovereignty, compliance, technical security, productivity, and cost control.

By relying on clear criteria and official reference frameworks (ANSSI, ISO, GDPR, HDS), it becomes possible to select a solution genuinely suited to the needs of the public sector—one that can ensure both service continuity and the protection of citizens’ data.

Would you like to evaluate a sovereign and automated cloud platform?

Contact us

In addition to cloud credits, the selected startups benefit from personalised onboarding with our engineers, coaching, access to workshops and masterclasses, as well as visibility across our media channels and events.

The objective is clear: to enable them to focus on their core business while relying on a reliable, automated and sovereign cloud infrastructure.

The new startups of the 3rd UP cohort

This year, seven innovative young companies are joining the UP program. They cover a wide range of sectors – e-commerce, finance, health, energy and data – with one thing in common: using technology to tackle concrete challenges.

Chaynon: fighting against refund fraud

Chaynon offers a decision-support tool for marketplaces and e-merchants to combat refund fraud. Their solution detects suspicious behaviours, helping to reduce losses linked to abuse while protecting merchants’ margins.

Klafuti: automating accounting data

Klafuti has designed a SaaS platform for accounting professionals (accountancy firms, chartered accountants, etc.) that automates the extraction, transformation and integration of accounting data. This approach simplifies the day-to-day work of experts and frees up time for strategic advisory.

Wattflow : optimising energy in professional buildings

Wattflow orchestrates the heating, ventilation and air conditioning systems of office and commercial buildings by communicating directly with the machines. The result: up to 40% savings on energy and associated costs, along with improved comfort for occupants. By directly connecting to technical equipment, Wattflow combines energy efficiency with enhanced user experience.

thaink²: simplifying Data & AI projects

thaink² Analytics is the Data & AI platform that simplifies your projects end to end. A no-code SaaS, intuitive and designed by experts. No more unstable data pipelines or ML/AI models stuck at the POC stage. The goal: to make AI operational and accessible to all companies, without technical complexity.

LiteoMED: a digital ecosystem for oncology

LiteoMED provides a comprehensive platform dedicated to oncologists. It combines precision medicine with a patient-centred approach, allowing practitioners to save time while improving care delivery and patient follow-up.

Kocliko: reducing energy costs and carbon in collective housing

Kocliko deploys a unique deeptech solution for intelligent control of collective heating, combining AI, certified sensors and a digital twin to sustainably reduce consumption, emissions and tenants’ charges.

Cloud Data Engine: securing distributed data exchanges

Cloud Data Engine specialises in the operational management of data spaces and the automation of compliance for decentralised data ecosystems (dataspaces, catalogues, marketplaces, etc.).

Why join the UP program?

The program is designed as a real springboard for startups. By joining UP, they gain access to high-level technical support, mentoring sessions, and increased visibility within our network and among our partners.

At Clever Cloud, we believe the cloud should be an accelerator, not a barrier, in the entrepreneurial journey. That’s why we invest in these promising young companies and give them the means to grow faster.

Are you a startup looking to join the UP program?

Apply now to be part of the next cohort!

An unprecedented initiative led by Gigalis

Created in 2000 by the Pays de la Loire Regional Council, Gigalis has established itself as a key player in public digital services. Transformed into a Public Interest Group (GIP) in January 2025, it now supports regional authorities and institutions with sovereign services in connectivity, cybersecurity, cloud, and the pooling of digital procurement. It is within this dynamic that, on September 1st, the Fabrique IA Territoriale was officially launched — a unique initiative in France bringing together public actors and private companies to address the challenges of artificial intelligence and open source.

Three complementary lots to structure the AI ecosystem

The framework agreement designed by Gigalis has been divided into three lots, covering the entire lifecycle of AI projects.

1. The first focuses on consulting and raising awareness around artificial intelligence, and was awarded to a group of national and regional players including Linagora, Onepoint, Pyxis support, Synchrone et Wavestone.
2. The second, dedicated to community integration, brings together Atos, DRI, Metapolis, Beewant, Reel IT, Cross Data, PARTHEMA, DATA INCEPTIO.AI et Valeuriad.
3. Finally, the third lot, centered on infrastructure, hosting, deployment, and operations using open source technologies, was awarded to Clever Cloud, Linagora, DRI, Siium et Reel IT.

This organization ensures strong complementarity and makes it possible to provide public sector actors with a coherent, sovereign, and tailored offering that fully meets their needs.

Clever Cloud’s expertise for Lot 3

Clever Cloud’s participation in the Fabrique IA Territoriale is fully aligned with our mission: providing a European, secure cloud that frees public organizations from technical constraints. In practice, our approach relies on proven open source technologies, integrated into an automated infrastructure to ensure interoperability, performance, and security. At the same time, we guarantee high availability, continuous monitoring, and measurable commitments through transparent quality indicators.

Beyond the technical aspects, our contribution also consists in transferring knowledge to gradually make beneficiaries autonomous. This transfer of expertise lies at the heart of our approach: supporting, securing, and sustaining digital projects without creating dependency on external providers.

A commitment to digital sovereignty in the region

The Fabrique IA Territoriale is more than just a framework agreement: it embodies a collective vision of trusted digital services, designed for local territories. By joining this initiative, Clever Cloud strengthens its commitment to offering a credible European alternative to major international providers. This approach enables local authorities to benefit from modern, resilient infrastructures while supporting the regional digital ecosystem.

For Clever Cloud, this participation illustrates the convergence between our values and those promoted by Gigalis: sovereignty, cooperation, and sustainability. We believe that an ethical and responsible digital environment must be built on open, secure, and accessible solutions for all public sector actors.

Conclusion and outlook

Our role within the Fabrique IA Territoriale reaffirms our determination to support the digital transformation of public services, giving them the means to manage their projects with efficiency and transparency. Alongside committed partners, we put automation, security, and sovereignty at the service of collective intelligence and local innovation.

To learn more about how Clever Cloud can support your public sector or territorial projects:

Contact us