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.

GraphQL on a key-value database almost sounds like a provocation. On one side, the simplest data model imaginable: a key, a value, and that’s it. On the other, a typed query language usually associated with APIs exposing fairly deep object graphs. At first glance, these two worlds did not seem to have much to say to one another.

And yet, this is exactly what Materia KV now offers. You can continue writing data with any Redis or Valkey client and read it back through a GraphQL endpoint. No synchronization layer, no replica to maintain, no secondary datastore to feed. Everything you write on one side becomes immediately queryable on the other, within the same cluster. It’s the same database, seen through two different doors.

Materia keeps finding its way

Before going any further, let’s briefly revisit where Materia KV comes from, because the product was not built overnight. Since entering public Alpha, Clever Cloud’s serverless key-value database has steadily evolved based on your feedback. TTL support was quickly added to handle key expiration ; shortly afterward, KV Explorer was added to the Console, along with the clever kv command in Clever Tools, allowing you to browse your data without installing any third-party software.

JSON commands (JSON.GET, JSON.SET, JSON.DEL) came next, followed by the move to Beta with Hash support, the Set type earlier this year, and more recently a batch of new hash, string, and TTL commands. And let’s not forget that such an add-on can be deployed through both the provider Terraform and the Clever Kubernetes Operator.

The common thread running through this whole story remains the same: compatibility. We never wanted to force you into a proprietary API, an exotic ORM, or a Clever Cloud-branded client. You interact with Materia KV using protocols you already know. Redis/Valkey support came first. The GraphQL layer brings a new dimension.

How does it work in practice?

You write through the Redis API, read through GraphQL, and both interfaces operate on the same keyspace using the same token. The password used by your redis-cli ($KV_TOKEN, also available as $REDIS_PASSWORD, based on Eclipse Biscuit) also serves as the GraphQL bearer token. Existing add-ons therefore require no changes.

Because Materia KV is a distributed cluster, the endpoint is a single URL shared by all add-ons: https://materiakv-graphql.eu-fr-1.services.clever-cloud.com/graphql.

The schema exposes a single root type, MateriaKvQuery, covering strings, hashes, and sets. Open the URL in your browser and you’ll find a GraphiQL playground where you can explore the entire schema, or retrieve the SDL using the introspection tool of your choice.

One detail before we go any further: for now, this is read-only. No mutations. In many cases, that is sufficient. Writing remains the job of Redis and Valkey clients, which already do it perfectly well, while GraphQL focuses on querying data.

Time for some hands-on examples. Throughout the following examples, we write using redis-cli and read using curl, assuming the add-on environment variables have been loaded:

# On récupère les variables d'environnement de l'add-on, vous pouvez aussi le faire via un fichier .env par exemple
source <(clever addon env ADDON_ID -F shell)
export KV_GRAPHQL_URL="https://materiakv-graphql.eu-fr-1.services.clever-cloud.com/graphql"

First, a string. We create a key with redis-cli, then read it back through GraphQL:

redis-cli -h $KV_HOST -p $KV_PORT --tls SET demo:greeting "Hello, Materia!"

curl -s "$KV_GRAPHQL_URL" \
  -H "Authorization: Bearer $KV_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"query($key:String!){ string(key:$key){ key value } }","variables":{"key":"demo:greeting"}}'

Which returns:

{ "data": { "string": { "key": "demo:greeting", "value": "Hello, Materia!" } } }

What was written on one side is immediately readable on the other, with no delay and no intermediary layer. Where GraphQL starts to pull ahead, is when your data becomes more complex. Take a hash, for example, which carries a structured record:

redis-cli -h $KV_HOST -p $KV_PORT --tls \
 HSET demo:user:alice name Alice role admin email alice@example.com active true

GraphQL can return it as a typed list of { name, value } pairs, eliminating the need to manually parse a flat response on the client side:

query ReadUser($key: String!) {
  hash(key: $key) {
    key
    fields { name value }
  }
}

The same logic applies to a set, that collection of unique, unordered values that both protocols expose as a first-class object:

redis-cli -h $KV_HOST -p $KV_PORT --tls SADD demo:group:admins alice bob carol

It can then be queried using:

query ReadGroup($key: String!) {
  getSetMembers(key: $key) { key members }
}

Complex queries: where GraphQL shines

But here’s the part that, on its own, justifies the existence of this compatibility layer: GraphQL doesn’t just expose your sets, it knows how to combine them. Finding members present in two groups at the same time becomes a single query, without using SINTER, without precomputed indexes, and without performing the merge client-side.

redis-cli -h $KV_HOST -p $KV_PORT --tls SADD demo:group:admins alice bob carol
redis-cli -h $KV_HOST -p $KV_PORT --tls SADD demo:group:active alice carol dave

With keys = ["demo:group:admins", "demo:group:active"], you obtain: ["alice", "carol"]. The setUnion and setDifference fields follow the same principle: who is both admin and active, who is either one, who is an admin but not active. The computation remains on the cluster; only the result is returned:

query AdminsAndActive($keys: [String!]!) {
  setIntersection(keys: $keys)
}

TTL, seen from two angles

A detail for those who appreciate well-chosen formats. Redis thinks in relative TTLs, expressed in seconds; GraphQL, on the other hand, returns the absolute expiration timestamp through the expireAt field, typed as a DateTime scalar (RFC 3339). Two representations of the same truth, each in the unit that makes sense for its protocol.

redis-cli -h $KV_HOST -p $KV_PORT --tls SET demo:session:xyz auth-token-42 EX 300

The GraphQL query will then be:

query ReadSession($key: String!) {
  string(key: $key) { key value expireAt }
}

As for JSON documents, Materia KV stores them on top of strings while keeping Redis’ JSON API. GraphQL returns the serialized document as is: you parse it client-side, and every field makes the round trip without loss.

Test it end to end

To see the two layers working in concert, we have published an interactive demo, deployable on Clever Cloud, with the source code available on GitHub.

Written with Bun and its native APIs (Bun.serve, Bun.RedisClient), without any framework or superfluous library, it walks through six scenarios — string, hash, set, intersection, TTL, JSON. You click, and it shows you side by side the Redis commands being sent and the GraphQL query that reads the result back, with variables, raw responses, and response times.

Deploying it takes just a few commands:

git clone https://github.com/CleverCloud/kv-graphql-example
cd kv-graphql-example

clever create -t node -a kv-graphql-example
clever addon create kv kv-graphql-example --link kv-graphql-example 
clever env set KV_GRAPHQL_URL "https://materiakv-graphql.eu-fr-1.services.clever-cloud.com/graphql"

clever deploy
clever open

What’s next?

This first GraphQL implementation lets you test this approach and share your feedback with us. It is not an end in itself: mutations are among the options on the table, and as usual with Materia KV, your use cases will decide the order of priorities. So feel free to put it through its paces and tell us what you think is missing.

To dig deeper, everything is there: the GraphQL layer documentation, the changelog announcement, and the full example. And for those waiting to benefit from Materia’s resilience with clients from the DynamoDB ecosystem, this is underway through a dedicated product. It is currently being tested by customers using it for specific needs and will be opened more broadly a little later this year.

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

So we built our own orchestrator. It runs on micro-VMs and gives us a clean kernel boundary between workloads, with no shared kernel between tenants. That is what runs tens of thousands of applications in production on our PaaS today, and for most projects it is still the shortest path from a commit to production.

When Docker arrived, some workloads fit better as a container image than as one of our native runtimes. So we added a Docker runtime to the platform, where it made sense. Not to replace our approach, but to broaden it.

Then Kubernetes established itself as the de facto standard for container orchestration. Its ecosystem (Helm, operators, GitOps, and so on) became unavoidable for many teams.

We could have kept saying that, in many cases, Kubernetes is not the best path to production. That is still true. But it was no longer enough. That is why we are launching CKE, our Clever Kubernetes Engine, available in public beta starting today.

As many know, we resisted for years the idea of offering Kubernetes as just another checkbox in the Console. Not because Kubernetes is useless, but because it has too often become a default answer to problems the PaaS solves more simply: deploying an application, scaling it, monitoring it, isolating it, connecting it to a database, managing its environment variables, its logs and its lifecycle. And we still believe that.

But Kubernetes has become the common language of a large part of the cloud-native ecosystem. Helm, operators, GitOps, already-containerized workloads, internal platforms and existing toolchains are part of the daily reality of many teams. And our reason for being is to make life easier for technical teams.

The question was no longer "should we do Kubernetes?", but "can we do Kubernetes without giving up what makes Clever Cloud?"

Not a quickly repackaged Kubernetes

The fastest way to ship managed Kubernetes is to wrap an upstream distribution behind an admin console, add a provisioning API, and bill the cluster by the hour. It is a valid strategy if you want to ship fast. It is not the one we wanted.

For CKE, we had three requirements that cannot be solved by simply bolting Kubernetes on top of the rest of the platform.

The first is sovereignty. CKE is operated in Europe, on our infrastructure and that of our partners, and can also be deployed on the on-premises infrastructure of customers who need it. No dependency on US hyperscalers, no grey areas around data jurisdiction, no vague promises about where the infrastructure actually runs.

The second is integration with the rest of Clever Cloud. We did not want to create a Kubernetes silo sitting alongside the PaaS, the managed databases, the object storage and the private network. We wanted a Kubernetes that fits inside the same platform, with the same Console, the same tooling, the same billing, the same governance rules and the same managed services.

The third is operational predictability. Kubernetes is a complex distributed system, and its behaviour under load depends heavily on its foundations. We did not want to operate a product whose underlying layer would remain a black box or a default-accepted limitation. That is what led us to work on something few providers touch: Kubernetes' internal consistency layer.

Under the hood: Materia etcd on FoundationDB

In Kubernetes, etcd is the component that stores cluster state: manifests, resources, secrets, node state. It is the source of truth for the entire orchestrator.

It is also one of the most sensitive components in the system.

etcd works very well within the scope it was designed for. But its limits at scale are well known: store size, latencies under heavy write load, behaviour during network partitions, backup and restore operations, the need for compaction and fine-grained monitoring. When Kubernetes becomes a critical foundation, etcd becomes an operational concern in its own right.

We did not want to build CKE on top of a brick we would then treat as a fragile black box.

So we took the problem back to its root: keep the contract Kubernetes expects, but replace the internal consistency layer with an implementation backed by FoundationDB. We call it Materia etcd.

FoundationDB gives us distributed ACID transactions, a robust consistency model, and a deterministic simulation testing approach that fits very well with how we build critical infrastructure.

For end users, this work is invisible. That is precisely the point. Under the hood, this foundation lets us build CKE with the auto-scaling, auto-healing and operational predictability we expect from a Clever Cloud service.

We will come back to Materia etcd in more detail soon, because the topic deserves a dedicated article.

Standard Kubernetes on the developer side

All this work on the underlying layer has a simple goal: on the user side, CKE has to be standard Kubernetes.

Your manifests work without modification. Your Helm charts install normally. Your Argo CD or your Flux plugs in like on any other cluster. Your Kubernetes operators run without surprises.

CKE does not try to reinvent the developer interface of Kubernetes. That would be counterproductive. If you already have a Kubernetes deployment chain, the goal is for it to run on CKE with as little friction as possible.

The difference happens elsewhere: in how this Kubernetes integrates with the rest of the Clever Cloud platform.

Kubernetes when you need it, the PaaS when it is enough

CKE does not replace our PaaS. It complements it.

For many applications, the PaaS remains the best choice: less operations, less configuration, less YAML, less maintenance surface. If your application fits naturally in a Clever Cloud runtime, the PaaS is often still the simplest and most robust path.

But there are cases where Kubernetes is the right tool.

You may need to install :

• An operator;
• Reuse existing manifests;
• Standardize a GitOps chain;
• Deploy a workload already distributed as a Helm chart;
• Run an internal platform built around the Kubernetes API;
• Or simply meet the habits of a team that already works with Kubernetes day to day.

In those cases, the problem is not Kubernetes itself. The problem is Kubernetes isolated from the rest of your system.

That is where CKE changes things. You can keep a Node.js API on the PaaS, a static frontend on Cellar, a managed PostgreSQL database, and run on CKE only the component, the operator or the workload that really needs Kubernetes.

All within the same Clever Cloud environment.

Native integration with the Clever Cloud ecosystem

CKE was designed to integrate with the services you already use on Clever Cloud.

• Cellar, our S3-compatible object storage, can be used from your Kubernetes workloads.
• Managed databases (PostgreSQL, MySQL, MongoDB, Redis, Materia) attach to your cluster the same way they do to any other Clever Cloud application.
• IAM as a Service lets you manage authentication and permissions on the cluster and on the teams that access it.
• Network Groups lets you connect your CKE cluster to your existing Clever Cloud PaaS applications, in the same private network.

The Network Groups integration is probably the one that changes day-to-day work the most.

Kubernetes is often introduced into organizations as a new island: new console, new network, new secrets, new access rules, new billing, a new way to connect services together.

With CKE, the goal is the opposite. Kubernetes becomes one more brick in the Clever Cloud architecture, not a parallel world.

So you can build a hybrid architecture without workarounds: part on the PaaS, part on CKE, managed databases, object storage, private networking, and shared governance.

Enabling CKE and deploying a first application

For this demo, we will stick to the bare minimum: enable the feature, create a cluster, fetch a kubeconfig, add a node group, and deploy a first application with a LoadBalancer service.

On the prerequisites side, you will need Clever Tools version 4.3 or later, and kubectl installed locally.

Since the public beta opened on April 27, the Kubernetes feature can be enabled by any Clever Cloud customer, with a single command:

clever features enable k8s

You can then create a cluster. Give it a name, point to your organization, and the --watch option lets you follow the deployment progress:

clever k8s create my-cluster --org <your-org-id> --watch

Creation takes about a minute. At any time, you can list the clusters in your organization with clever k8s list.

Once the cluster is ready, fetch its kubeconfig and write it directly as your default local configuration:

clever k8s get-kubeconfig my-cluster --org <your-org-id> > ~/.kube/config

From there, it is standard Kubernetes. kubectl talks to the cluster, and your usual tooling follows. You can start by checking that everything is in place:

kubectl get nodes

At this stage, the list is empty: the cluster is created but has no compute capacity. This is a good moment to introduce the first CKE-specific API resource: the NodeGroup. A node group is a set of Kubernetes nodes with the same profile (same flavor, same region), managed as a unit. You describe it like any other Kubernetes resource, in a YAML file:

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: example-nodegroup
spec:
  flavor: M
  nodeCount: 2

And you apply it with kubectl:

kubectl create -f example-nodegroup.yaml

Sixty to ninety seconds later, the nodes join the cluster:

kubectl get nodegroups
NAME                DESIREDNODECOUNT   CURRENTNODECOUNT   FLAVOR   STATUS   AGE
example-nodegroup   2                  2                  M        Synced   2m

kubectl get nodes
NAME                      STATUS   ROLES    AGE   VERSION
example-nodegroup-node0   Ready       2m    v1.35.0
example-nodegroup-node1   Ready       2m    v1.35.0

To resize the node group, you stay within the Kubernetes API:

kubectl scale nodegroup example-nodegroup --replicas=4

With a cluster that now has compute capacity, you can deploy a first application. To keep things simple, an nginx exposed through a LoadBalancer service, which will automatically provision a load balancer on the Clever Cloud side:

kubectl create deployment nginx --image=nginx:alpine --replicas=2 
kubectl expose deployment/nginx --type=LoadBalancer --port 80 
kubectl get service nginx

A few seconds later, the service exposes a public address. This is exactly the responsive behaviour we mentioned about the private testing phase: provisioning a node group, scaling it or exposing a service requires no waiting and no manual configuration.

From here, it is Kubernetes like anywhere else. You can add persistent storage through the Clever Cloud CSI, install the Clever Kubernetes Operator to provision a managed database from your manifests, or plug in your usual GitOps chain. The cluster supports Kubernetes versions 1.34, 1.35 and 1.36, with 1.35 as the default. Everything is detailed in the CKE documentation.

What we saw during private testing and at Devoxx, and what is next

CKE is now in public beta, but some of our customers have had private access for several months. That phase was very useful to expose the product to real-world usage before opening it more widely.

The feedback has been very positive. The cluster behaves as expected, and the operations that come up most often in a Kubernetes team's daily life, such as adding a node or setting up a load balancer, are fast and predictable. That is exactly the behaviour we were aiming for when we invested so much time into the internal consistency layer.

At Devoxx France, we presented CKE on the Clever Cloud booth for three days. The conversations confirmed two things we were already observing.

First, teams are not just looking for a Kubernetes cluster. They are looking for a Kubernetes that integrates cleanly with their platform, their network, their databases, their security constraints and their existing practices.

Second, and probably the most striking feedback, developers are not looking to put everything on Kubernetes. Many want to keep their classic applications on our PaaS, where it is the most efficient, and deploy on Kubernetes only the components that really warrant it, because of their complexity, their distributed architecture, or the constraints of the ecosystem they fit into.

This is exactly the kind of hybrid architecture CKE is designed to enable.

It is also why, ahead of the launch, we built the Clever Kubernetes Operator. It allows a workload running in a Kubernetes cluster, whether hosted with us or elsewhere, to provision and consume our managed services directly from the Kubernetes API: PostgreSQL, MySQL, MongoDB, Redis, Cellar or Materia.

For your teams, it is a kubectl apply that creates a managed database. For CKE, it is the natural tool to bridge Kubernetes workloads and the rest of the Clever Cloud platform.

The beta is open to all Clever Cloud customers. You can enable it right now, deploy your first workloads, and tell us what is missing, what surprises you or what you would like to see come next.

The discussion is open on our GitHub community, and the documentation is available here.

CKE does not replace our PaaS. It complements it.

For many applications, the PaaS remains the simplest path from a commit to production. But when you need Kubernetes, for an operator, a Helm chart, a GitOps chain, an already-standardized workload or an internal platform, you can now do it inside the Clever Cloud environment, with our infrastructure choices, our network, our managed services and our sovereignty requirements.

That is the kind of Kubernetes we wanted to build.

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

Somewhat paradoxically, the biggest change of the past few months is also the least visible from the outside: the strengthening of our “Clever Cloud Everywhere” approach.

An open cloud platform that adapts anywhere, to your needs

Because we are more than a PaaS provider with our own infrastructures,we offer our customers the ability to deploy their applications and services with our partners (Cloud Temple, Ionos, OVHcloud, Scaleway, etc.), or even on their own servers, for use cases ranging from edge deployments (local machines) to fully air-gapped environments (disconnected from the Internet).

So, you don’t have to adapt to the constraints of our cloud, the opposite is true. In 2025, a growing number of customers asked us for fine-grained adjustments to fit their needs, which we are always happy to provide. As a result, if you want your own Clever Cloud, that’s entirely possible: we can supply partner hardware or install our platform on infrastructure you already have. This is precisely how we operate outside of Paris.

Moreover, after opening a zone in London and establishing partnerships in West Africa and Kazakhstan, we have also announced our new Moroccan subsidiary. At the same time, we continue to strengthen our local presence, through our integration into the Fabrique IA Territoriale in Pays de la Loire, our support for startups via the UP Program, and our partnership with the German company SpiNNcloud to build a European computing platform for AI.

Kubernetes at Clever Cloud

Another major milestone reached by our teams is the launch of Clever Kubernetes Engine (CKE), our managed Kubernetes offering. It is currently available to a limited number of customers who are actively using it, and can already be accessed through our API, Clever Tools, and the Console. It will be opened more broadly in the coming weeks.

Two new points of presence in Paris

This expansion of our services goes hand in hand with an expansion of our infrastructure, as we move from 3 to 5 datacenters in the Paris region. We have begun our deployment both in Vélizy with our partner Etix and by strengthening our partnership with TeleHouse through a presence at TH3 (Magny).

This will enable us to meet our customers’ growing needs while preparing the introduction of new services, such as our forthcoming Infrastructure-as-a-Service (IaaS) offering, which you should hear more about next year.

Are you Clever Cloud certified?

2025 was also the year we launched our first certification program, which had been highly requested by several of our customers and partners. This first step was accompanied by the continued strengthening of our sales team over the past few months.

A second, intermediate-level course is arriving very soon. This will allow us to better support you on a daily basis and take the time to address your needs, while multiplying workshops and training sessions—both in person, via webinars and through live streams on YouTube and Twitch. Next step: Clever Cloud ambassadors!

Continuous improvement of our offering

Naturally, we have continued to improve our long-standing PaaS solution by releasing new images and features every week. Integration has become faster as well, with updates such as Node.js 24 and Java 25 now supported, along with improved compatibility for pnpm and Yarn alongside Bun. .NET 10 and PHP 8.5 are next in line.

We are also gradually shortening update cycles for several database services. As a result, PostgreSQL 18 is already available, and Redis 8.4 as well as Elasticsearch 9 are on the way.

In addition, we have kept strengthening the managed services we offer across the platform, including Keycloak, Matomo, Metabase, and Otoroshi. All of them are now available in their latest versions, with the ability to manage updates at creation time and from the Console dashboard, as well as to enable advanced features when needed.

Thus, we introduced Secure Multi Instances in Keycloak a few months ago, leveraging our Network Groups. These groups can also be enabled in a single click within the Otoroshi API Gateway to connect multiple applications. Otoroshi now also supports loading third-party plugins and configuring domains at creation time.

Other services continue to evolve as well. For example, Materia KV is now available in beta and will keep improving ahead of its planned general availability early next year. Similarly, Apache Pulsar will reach the same milestone soon, with updated pricing to accompany the release.

Our offering is also becoming increasingly accessible through a tool we significantly strengthened this year to support some of our customers’ needs: our provider Terraform. After reaching version 1.0 this summer, it is now available as version 1.7.1,providing a wide range of capabilities. Feel free to try it out and share your feedback and suggestions.

Clever Tools and Console evolve, the revolution in 2026

Clever Tools can now be executed via npx, support the new drains, and have gained numerous features over the past months. We began a major redesign with version 4.0, released last September. And this work will continue throughout 2026.

In the Console, we recently rolled out our new interface for access logs, with add-on logs coming next. We will progressively extend the new dashboards to all our services, then integrate Network Groups and introduce a native management interface for our object storage solution, Cellar.

But the most significant shift has been the deeper redesign of the Console itself. This work comes alongside new APIs aimed at modernising the platform and the services it provides, with the same goal as always: making developers’ lives easier.

Such progress are supported by foundational work carried out quietly throughout the year: the complete overhaul of our JavaScript client. Easier to use, more complete, type-safe, and managing API Tokens, it will serve as the basis for several upcoming initiatives we will announce soon.

Want to know more? Join us at ACCES!

As you can see, 2025 has been a year full of updates and significant changes for Clever Cloud and our team. And 2026 is set to follow the same trajectory. To see what’s coming next, feel free to join us at the Amazing Clever Cloud Enterprise Summit (ACCES) taking place on Thursday, 11 December 2025 during FOST (formerly apidays), which will take place from 9 to 11 December. We will host a pavilion with several of our clients and partners to showcase what we are preparing for the months ahead — from Clever IA to Materia TS to our KMS.