This release is a milestone: the underlying machine is now ready for the product features we have been waiting to build on top of it. Rather than a list of patches, we've grouped the work into six themes; for each, we say two things — what shipped, and what it makes possible, for the people running their applications on the platform and for the operators who run Sōzu on their own infrastructure.

1. A from-scratch HTTP/2 multiplexer

Sōzu's HTTP/1 stack had already been rewritten around kawa, our pivot format: a single internal representation of the HTTP message, independent of its protocol version — the same idea as HAProxy's HTX. The HTTP/2 multiplexer is its natural extension: it adds session management and stream multiplexing on top of kawa.

It supports the full protocol matrix (H1↔H1, H1↔H2, H2↔H1, H2↔H2), with shared stream state, HPACK compression via loona-hpack, backend H2 connection pooling, RFC 9218 Extensible Priorities for stream prioritisation, and per-listener ALPN negotiation so each TLS connection lands on the right code path. Around 181 end-to-end tests and two cargo-fuzz targets keep the parser and the HPACK decoder honest — including regression guards that pin large-response integrity byte-for-byte across an H1-backend → H2-frontend path, the exact boundary where edge-triggered epoll readiness bugs hide.

For Clever Cloud customers, the practical impact is simple: every application served by the platform now speaks HTTP/2 by default, on the frontend — no opt-in, no code change, no configuration. Enabling HTTP/2 all the way to the backend stays a per-cluster choice — a cluster, in Sōzu's model, is one of your applications; turned on end-to-end, it unlocks gRPC across the whole chain. Page loads finish in fewer TCP connections; browsers can coalesce requests across hostnames that share a certificate (we honour RFC 7540 §9.1.1 SAN coalescing, so when the certificate, authority and connection conditions line up, Firefox and Chrome can reuse a single connection across your cdn.example.com and assets.example.com instead of opening parallel ones). It is, in the best sense, a quiet platform upgrade.

It is also the structural prerequisite for what comes after — HTTP/3 over QUIC and stronger streaming foundations at the edge. The mux rewrite is the part of the roadmap that had to land first.

2. Security as a baseline, not a toggle

The second half of the H2 rewrite is the part nobody asks for until it's missing: flood and DoS hardening. Sōzu 2.0 ships built-in mitigations for CVE-2023-44487 (Rapid Reset), CVE-2024-27316 (CONTINUATION flood), CVE-2025-8671 (MadeYouReset), and the PING / SETTINGS / empty-DATA flood family from CVE-2019-9512/CVE-2019-9515/CVE-2019-9518. Each mitigation surfaces a dedicated counter — twelve metrics under h2.flood.violation.* — so a SIEM can window the trip rate without parsing logs. Seventeen HPACK rejection reasons are surfaced the same way; that is the first operator-visible signal for request-smuggling probes against the H2 stack.

The rest of the security work fans out across the proxy: a per-(cluster, source-IP) connection cap with 429 Too Many Requests; opt-in eviction of the oldest sessions when the accept queue saturates; hardening across the command channel, the HTTP/1 parser, the pattern-trie router (closing a routing-bypass through unanchored regex) and the wildcard matcher; audit-log sanitisation against Trojan-Source and SIEM column-smuggling; and a TLS certificate hot-rotation that never drops the working certificate on failure, even if the new one is malformed. Four dependency advisories cleared in the same window.

Every privileged mutation now lands in a structured audit log: each control-plane action is recorded as a Command(verb=…, actor_uid=…, actor_user=…, result=…) line — who did what, from where, and whether it succeeded. Two dedicated sinks ship it out: audit_logs_target for the human-readable stream, and audit_logs_json_target for one stable-schema JSON object per line, so the trail tails straight into a SIEM (Wazuh, Elastic, Loki, Splunk) without a bespoke parser — in a shape designed for PCI-DSS 10.5.

The product framing is straightforward: our job is to operate the platform and shield your applications as soon as we can. When the next H/2 vulnerability in this class lands at 9pm on a Friday, it does not have to translate into a patch-and-redeploy weekend across thousands of applications — attacks of this class are largely absorbed or mitigated at the proxy, surfaced as a counter on a dashboard, while applications keep serving traffic. Trust-by-default is not a marketing claim; it is the cumulative effect of dozens of small, defensive fixes shipped at the layer where the security boundary actually lives.

3. Visibility on every layer

The largest single user-facing addition in 2.0 is sozu top — an operator TUI (behind the tui Cargo feature) that gives you a live btop/htop-style view across seven panes: Overview, Clusters, Backends, Listeners, H2, Certificates, Events. Colour-blind-safe palette, customisable themes — the essentials fit in a terminal, no external dashboard required.

Underneath the TUI, the metric surface itself was rewritten. The mux exposes per-frame-type counters and a breakdown by RFC 9113 error code, TLS handshake telemetry, per-status HTTP counters, and new worker lifecycle gauges. The access log gains TLS and forwarding fields (version, cipher, SNI, ALPN, XFF chain), x_request_id propagation end-to-end, and client and server RTT — enough to follow a request from one hop to the next.

A new command, SetMetricDetail, lets an operator raise metric cardinality on demand via a time-bounded lease that expires: production stays low-cardinality by default, and deep inspection becomes a one-off decision rather than a config rewrite.

For Clever Cloud, this is the foundation of the next chapter of customer-facing observability — per-application latency percentiles, per-cluster availability, TLS handshake breakdowns, request IDs you can follow across hops. The metrics now exist at the proxy. The next step is to surface them in the Clever Cloud console where they belong, alongside the build and deploy views — so you do not need an external APM to understand the traffic your application actually sees.

4. Traffic policies that you can finally toggle

Sōzu 2.0 reshapes the entire frontend-policy surface (#1231): typed HSTS (RFC 6797) configurable per listener and per frontend; URL rewrite (host, path, port) with regex capture propagation from the routing trie into rewrite templates; request- and response-header rewriting per frontend — add, set, or delete any header (an empty value deletes it, HAProxy del-header parity), with listener-scoped X-Real-IP injection and anti-spoof elision of client-supplied values on top; HTTP 301 / 302 / 308 redirects through a typed RedirectPolicy enum; and HTTP Basic authentication per frontend, with SHA-256-hashed credentials and a constant-time compare via the subtle crate (the credential boundary is hardened against timing side-channels — the audit caught it at review time).

This is the part of the release where the product opportunity is most visible. Today, doing a clean domain migration on a managed platform typically requires either a backend that knows how to redirect or a separately deployed redirect service; putting a staging URL behind a password typically requires an authentication add-on. In Sōzu 2.0, these become knobs at the proxy. The plumbing exists; what remains is to expose those knobs in the Clever Cloud console — as a checkbox on a domain, or a one-click toggle for preview environments. That is the no-code traffic-control surface we want to build next.

5. Operations as the customer benefit

A rewrite this deep only ships safely if the fleet keeps moving underneath it. Day-to-day operations got a lot of attention in 2.0.

sozu listener {http,https,tcp} update is a new field-masked patch verb that tunes non-bind-only listener settings on a running proxy without cycling sockets — H/2 flood thresholds, SNI binding, ALPN preference, idle timeouts, HSTS, custom answers. CVE mitigations can now be tightened under attack without cycling listener sockets. Active backend health checks run inside the existing mio event loop (no async runtime, no extra threads) with HTTP/1.1 and HTTP/2 probes, jittered intervals, and a fail-open path that routes through Normal-status backends whose retry policy allows it. systemd integration (closes #228) now does the right thing: Type=notify units, READY=1 only after the initial workers spawn and the saved state replays, STOPPING=1 on graceful shutdown, MAINPID=<new> across hot upgrades.

Releases themselves changed shape. Pushing a tag now produces ten pre-built tarballs (three Linux targets crossed with up to four crypto providers), signed keyless via sigstore (cosign + GitHub OIDC), with SLSA build provenance and a SOURCE.txt corresponding-source pointer satisfying AGPL §6 / LGPL §4 — closing the gap noted in #1089. ACME fullchain.pem files now load cleanly even when the client emitted the leaf at the start (Certbot, lego, acme.sh); a six-year-old worker-auto-restart binary race (#515) is fixed by pinning the original inode through /proc/self/fd. The LoadState IPC verb stays forward-compatible with sozu-command-lib 1.1.1 clients, so the ecosystem of integrations does not break on the upgrade.

At Clever Cloud's scale, the cost of an operational incident isn't a ticket — it is compounding latency for thousands of applications, and the engineers' time we owe to building the next thing. Sōzu 2.0 is the proxy that is quiet to operate, and that quietness is what customers experience as uptime. It's also what makes Sōzu credible as something you can run on your own infrastructure: signed binaries, hot reloads, ACME quirks ironed out, systemd integration done properly.

6. Crypto that's ready for tomorrow

The TLS stack got a quieter but equally important rework (#1191). Sōzu now supports four pluggable crypto providers for rustls — crypto-ring (the default), crypto-aws-lc-rs, crypto-openssl, and fips (which implies aws-lc-rs in FIPS mode). All four are exercised by CI, and the precedence chain fips > ring > aws-lc-rs > openssl resolves the active provider deterministically when several features are enabled together.

What we are most happy about, though, is the default groups_list: X25519MLKEM768 is now the first-preference key-exchange group where the provider supports it. That is the post-quantum hybrid being standardised through the IETF (draft-ietf-tls-ecdhe-mlkem) and already registered in the IANA TLS registry; what it means in practice is that an X25519-only client and a PQ-capable client both negotiate the most robust mutually supported exchange, with no operator action.

When the post-quantum migration becomes a regulatory requirement — on a timeline the industry is still debating — the groundwork on Clever Cloud will already be in place: every TLS 1.3 client that offers the hybrid negotiates it today, with no operator action. We made the choice quietly, and we made it the default.

From reverse proxy to programmable edge

Sōzu has always been an infrastructure load balancer: well beyond HTTP, it also balances raw TCP, with a zero-copy forwarding path via splice(2) on Linux for TCP listeners. With 2.0 it moves closer to an API gateway and becomes the substrate of a programmable edge — and "programmable" is the operative word. Each capability described above (HTTP/2 by default, anti-abuse controls, observability, traffic policies, crypto agility, operational quietness) is a knob. The next year of Clever Cloud's roadmap is about exposing those knobs as product features: through the console, through the API, through the workflows you already use to deploy your applications.

This is what we mean when we say Sōzu 2.0 is a first step of something greater. Two-point-zero is not the destination — it is the platform we now build on top of. Managed HTTP/2 everywhere is the first building block. The next is a console where you toggle HSTS, password-protect a preview environment, or redirect a migrated domain. The destination — a fully programmable edge with policy primitives you can compose — is what we are building toward over the coming release cycle.

Two more pieces are already on the bench. First, a UDP load-balancing layer — in the spirit of IPVS, but with Sōzu's hot-reload model — paired with TCP health checks that probe the liveness of the UDP backends; this cements the infrastructure-load-balancer role further. Second, HTTPS-reachable backends, which firm up upstream connectivity and open the road to the API gateway.

Sōzu is open source under AGPL-3.0 (the command library is LGPL-3.0). The 2.0 release binaries are signed via sigstore and ship SLSA provenance; if you operate your own edge, this release is yours to use, audit, and extend. The code, the issue tracker, and the conversations live at github.com/sozu-proxy/sozu.

Thank you to the contributors who made this release happen — and to everyone running Sōzu in production, whose feedback shapes where it goes next.

References

Standards and specifications

• RFC 6797 — HTTP Strict Transport Security (HSTS). https://datatracker.ietf.org/doc/html/rfc6797
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2). Now obsoleted by RFC 9113, but §9.1.1 on connection coalescing remains the citation reused by RFC 9113. https://datatracker.ietf.org/doc/html/rfc7540
• RFC 9113 — HTTP/2 (current). §5 streams, §6 frames, §6.8 GOAWAY, §7 error codes, §8.1 HTTP semantics. https://datatracker.ietf.org/doc/html/rfc9113
• RFC 9218 — Extensible Prioritization Scheme for HTTP. https://datatracker.ietf.org/doc/html/rfc9218
• draft-ietf-tls-ecdhe-mlkem — Hybrid key exchange in TLS 1.3: X25519MLKEM768 (IETF Internet-Draft, IANA-registered; the post-quantum hybrid Sōzu prefers by default). https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem

CVEs

• CVE-2019-9512 — HTTP/2 Ping Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9512
• CVE-2019-9515 — HTTP/2 Settings Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9515
• CVE-2019-9518 — HTTP/2 Empty Frames Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9518
• CVE-2021-42574 — Trojan Source (bidirectional override). https://nvd.nist.gov/vuln/detail/CVE-2021-42574
• CVE-2023-44487 — HTTP/2 Rapid Reset. https://nvd.nist.gov/vuln/detail/CVE-2023-44487
• CVE-2024-27316 — HTTP/2 CONTINUATION Flood. https://nvd.nist.gov/vuln/detail/CVE-2024-27316
• CVE-2025-8671 — MadeYouReset (HTTP/2). https://nvd.nist.gov/vuln/detail/CVE-2025-8671

Further reading

• Cloudflare Learning Center — What is HSTS?. Accessible primer on HSTS, the max-age / includeSubDomains / preload semantics, and the HSTS preload list policy. https://www.cloudflare.com/learning/ssl/what-is-hsts/
• Cloudflare — HTTP/2 Rapid Reset: deconstructing the record-breaking attack. The canonical write-up of the October 2023 coordinated disclosure, including attack mechanics and the 398 M rps peak captured live. https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• HAProxy Technologies — HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack (CVE-2023-44487). HAProxy's structural argument for why their stream lifecycle naturally absorbs Rapid Reset; a useful contrast against Sōzu's flood-counter approach. https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
• Cloudflare blog — Post-quantum series. Multi-year coverage by Bas Westerbaan and colleagues on PQ key exchange and hybrid groups; lineage of the X25519MLKEM768 hybrid Sōzu now negotiates by default. https://blog.cloudflare.com/tag/post-quantum/

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.

Several recent Linux kernel vulnerabilities have required a swift response from infrastructure operators.

Among them, Copy Fail and Dirty Frag drew attention because they involve local privilege escalation scenarios. Copy Fail is tracked as CVE-2026-31431.

Dirty Frag covers two distinct vulnerabilities, CVE-2026-43284 and CVE-2026-43500, tied to Linux kernel components.

At Clever Cloud, we treated these vulnerabilities as critical infrastructure matters. Our goal was twofold: quickly shrink the exposure window, then sustainably improve our kernel selection and deployment process.

This article reviews our approach, the decisions made, and the changes brought to our operations pipeline

Why these vulnerabilities called for a fast response

Copy Fail and Dirty Frag belong to the family of local privilege escalation vulnerabilities. In this type of scenario, an attacker must already be able to execute code locally, but can then attempt to gain higher privileges on the affected machine.

Dirty Frag rests on two Linux kernel flaws.

They notably affect modules related to ESP, used by IPsec, and to RxRPC. On a cloud platform, this type of vulnerability calls for a rapid analysis. The risk is not limited to a single isolated machine.

Scenarios tied to shared environments, containerized workloads, and isolation mechanisms must also be assessed.

What we verified

We analyzed the potential impact of these vulnerabilities on our environments. This step is not just about reading security advisories. It also involves verifying whether a theoretical scenario can become relevant in our operating context.

In the case of Copy Fail, the flaw came under embargo together with its patch. We published a new system image with the patch applied in the days that followed.

Our customers' applications were redeployed shortly after.

In the case of Dirty Frag, our internal analyses confirmed that these vulnerabilities had to be taken seriously. ESP modules are enabled in our kernels to support some specific customer needs. Fortunately, RxRPC-related modules are not present in our environment, as they serve no purpose for our usage.

We do not detail the technical steps of the exploitation here, since the purpose of this article is to inform our customers, not to publish a reproducible procedure.

This validation confirmed the operational decision: handle the matter immediately, reduce the exposed surface, then force the necessary redeployments.

Our operational response

Rolling out immediate measures

We first applied quick measures on the affected kernels. In the case of Dirty Frag, the publicly recommended measures focus in particular on the kernel components related to ESP and RxRPC.

On Clever Cloud's side, the goal was clear: reduce the identified exposed surfaces and shrink the exposure window without waiting for a standard maintenance cycle.

Redeploying the affected workloads

A kernel update only matters if the affected systems actually restart on a patched environment. We therefore launched a progressive redeployment of applications, then handled the cases that blocked this redeployment.

This phase matters. On a managed platform, the fix is not limited to producing an image or compiling a kernel. The execution chain must also actually use the expected version.

Improving the process along the way

We also took advantage of this sequence to replace a temporary mechanism with a cleaner integration into our orchestration pipeline.

Concretely, the kernel choice is now passed more explicitly through our internal pipeline, all the way to Supernova, our hypervisor agent. This evolution replaces the stiffer workaround put in place in the heat of the moment.

That is the central point of this intervention: fix fast, then make the fix more reliable for future operations.

What this changes for Clever Cloud customers

For customers, the expected effect is simple: reduce exposure without any manual action on their part whenever the platform can handle the redeployment.

Clever Cloud runs an architecture that relies in particular on isolation through virtualization. This approach is documented on our security pages and in our technical content on running containers inside virtual machines. It does not eliminate every risk, but it limits certain lateral movement scenarios compared to models where multiple workloads share the same execution environment directly.

We avoid, however, presenting this isolation as an absolute guarantee. A kernel vulnerability must always be taken seriously.

That is why we combined mitigation, redeployment, and improvement of our operations pipeline.

What we take away

This sequence confirms three principles.

First, a kernel vulnerability must be analyzed in its actual operating context. A public alert is not enough. We need to understand whether the conditions required for exploitation can exist on the platform.

Second, reaction speed matters. The Copy Fail and Dirty Frag vulnerabilities were disclosed publicly within a few days of each other, with analyses published by several players in the Linux and cloud ecosystem.

Finally, a useful security response must not only fix the problem of the moment. It must also improve the system that will handle the next incident.

That is what we did here: handled the vulnerabilities, shrank the exposure window, and strengthened our kernel management process.

Q&A

What is a local kernel vulnerability?

A local kernel vulnerability is a flaw that already requires execution capability on the affected machine. It can then allow gaining higher privileges, such as root, if the kernel is vulnerable.

Why do these flaws concern cloud platforms?

Cloud platforms run many workloads with isolation mechanisms. A kernel flaw can become critical if it allows crossing certain boundaries between processes, containers, or execution environments.

Are Dirty Frag and Copy Fail the same vulnerability?

No. Copy Fail is tracked as CVE-2026-31431. Dirty Frag covers CVE-2026-43284 and CVE-2026-43500. These vulnerabilities are close in impact, but they are distinct.

What action is required from Clever Cloud customers?

No general action is required from customers for environments handled by the platform. The automation brought by Clever Cloud allowed everything to be updated without action needed. Specific cases are tracked individually.

How Kubernetes Works: a Declarative Orchestrator

Most descriptions of Kubernetes list its components (pods, deployments, services) without explaining the central mechanism. The fundamental concept lies elsewhere: Kubernetes is first and foremost an orchestrator, and its core engine relies on a reconciliation loop.

You don't tell Kubernetes what to do. You tell it what you want your system to look like. This distinction, declarative versus imperative, changes everything.

In practice, you describe the desired state in manifest files, typically in YAML format: "I want 3 replicas of this image, exposed on port 80, with these environment variables." You submit this manifest to the Kubernetes API via kubectl. From that point on, Kubernetes continuously compares the actual state of the cluster (what is actually running) to the desired state (what you declared), and acts to bring them into alignment. If a node dies, its pods are rescheduled elsewhere. If you change from 3 to 10 replicas in the manifest, Kubernetes starts 7 more. If a container crashes, it gets restarted.

This reconciliation loop is the heart of everything Kubernetes does: self-healing, scaling, rolling updates, and rollbacks. To dive deeper into this mechanism and the other capabilities it enables, learn more about container orchestration.

Architecture in Brief: Control Plane, Nodes, Pods

A Kubernetes cluster is divided into two parts. The control plane is the brain: it makes global decisions, accepts API requests, schedules workloads, and monitors the state of the cluster. It relies on a few key components, including the API server (kube-apiserver), the scheduler (kube-scheduler), and the controller manager (kube-controller-manager), along with a distributed data store that holds the entire cluster state, traditionally etcd.

Nodes are the machines that actually run the workloads. On each node, an agent called kubelet receives instructions from the control plane and launches containers through a container runtime (containerd, CRI-O, etc.). The smallest deployable unit is not an individual container but a pod: one or more containers that share a network and storage. Higher-level objects (Deployment, Service, Ingress, ConfigMap, Secret) describe how pods should be managed, exposed, and configured.

This architecture is also the source of a common confusion with Docker, whose role is actually complementary to Kubernetes rather than competitive.

Why K8S Became the Orchestration Standard

According to the CNCF Annual Cloud Native Survey 2025, published in January 2026, 98% of surveyed organizations have adopted cloud native techniques, and 82% of container users deploy Kubernetes in production, up from 66% in 2023. The dominance is massive. But explaining it solely through technical qualities would be incomplete; it is also a story of ecosystem dynamics and aligned interests.

On the technical side, three properties explain adoption. First, the declarative model described above: it makes deployments reproducible, versionable in Git, and resilient to failures. Second, portability: the same manifest works on a development machine (Minikube, kind, k3d), on an on-premise cluster, and on any cloud. Third, extensibility: the Kubernetes API accepts Custom Resource Definitions (CRDs) and custom controllers (Operators), turning it into a platform for building platforms. This triggered a massive ecosystem dynamic.

On the strategic side, the story is less often told. By 2014, Google had more than a decade of experience managing containers at scale with its internal systems Borg and Omega, whose design principles were shared publicly through academic research papers (Omega in 2013, Borg in 2015). Rather than open-sourcing Borg itself, which remained tightly coupled to Google's proprietary infrastructure, the team created Kubernetes as a new project inspired by that experience, with a distinct implementation designed from the outset for external adoption. The project was released as open source in June 2014 and donated to the Cloud Native Computing Foundation in 2015. This neutrality, a project hosted by a Linux foundation rather than a cloud provider, proved decisive. No competitor could afford not to adopt it without being marginalized from the emerging cloud-native ecosystem. AWS, which initially pushed its own proprietary solution (ECS), announced EKS in late 2017 and launched it in general availability in June 2018. By then, the standard was sealed.

On the ecosystem side, the network effect did the rest: Helm for packaging applications, Prometheus for monitoring, Istio and Linkerd for service mesh, ArgoCD and Flux for GitOps, Trivy and Falco for security. Each additional tool reinforces the value of the standard. On the talent side, Kubernetes skills have become massively in-demand across DevOps and SRE roles, creating a virtuous cycle: more trained engineers, more adopting companies, more engineers getting trained.

In the CNCF 2025 report, the community now describes Kubernetes as "boring," using the term as the highest praise: a mature, predictable tool whose APIs no longer break with every release. That is exactly what you want from infrastructure that has become standard.

When Kubernetes Adds Value, and When Other Approaches Are a Better Fit

The fact that K8S is the standard doesn't mean it's the right answer to every problem. Choosing Kubernetes, a PaaS, or a combination of both depends on the technical and organizational context; at Clever Cloud, many teams use both in parallel for different workloads.

Kubernetes delivers real value in several contexts:

• strong portability requirements: multi-cloud, hybrid, or on-premise combined with cloud, where the Kubernetes manifest becomes a common denominator;
• distributed architectures that apply 12-factor app principles and the "cattle" approach (interchangeable, stateless instances) with sophisticated orchestration needs;
• strategic alignment with the CNCF ecosystem (Helm, Operators, ArgoCD, Istio, etc.) or client/partner prerequisites that impose the standard;
• need for a shared platform across large teams, with a dedicated platform engineering team or the willingness to outsource that responsibility to a managed service.

Conversely, in other contexts, a PaaS like Clever Cloud delivers the same outcomes as Kubernetes (industrialized deployments, autoscaling, resilience) without the operational complexity of the orchestrator. This is particularly true for standard application architectures (web + backend + database) where the effort of configuring and operating Kubernetes doesn't translate into tangible added value.

And for intermediate workloads (IoT, edge, development environments, small clusters), the differences between K3S and K8S are worth weighing before deciding: the lightweight distribution is often a better fit. The de facto standard is not a moral obligation. It is a powerful and costly tool to operate, and its use should be chosen based on the problems it solves, often as a complement to other approaches rather than a replacement.

The Limits of the Standard: Operational Debt

Running Kubernetes in production is not trivial. That's one of the reasons why many companies that adopt K8S opt for a managed service rather than a self-managed installation.

The sources of complexity are numerous: configuring access control correctly (RBAC), choosing and operating a network plugin (CNI), wiring up persistent storage (CSI), setting up observability, managing certificates, performing minor and major upgrades without downtime, hardening security, managing control plane backups. Each of these topics is a discipline in itself. The CNCF 2025 report shows that challenges have actually shifted from purely technical to organizational: 47% of organizations now cite "cultural changes with the development team" as their top obstacle, ahead of raw technical complexity.

At the heart of this debt sits a less-discussed component: etcd. It is the distributed key-value database that stores the complete state of the cluster. etcd is solid for moderately sized clusters, but becomes a bottleneck at scale. It's no coincidence that Google announced in late 2024 the replacement of etcd with Spanner for its managed GKE offering, retaining only the API compatibility layer. AWS, for its part, has built a "new generation" etcd architecture to handle scale. K3S, designed for lightweight environments, has pushed the logic further by offering several alternatives to etcd, including SQLite as the default. When the central component needs to be re-engineered to handle production use at scale, it's a telling sign.

This realization is what led us, at Clever Cloud, to rethink this component. Our Clever Kubernetes Engine replaces standard etcd with Materia etcd, our reimplementation of the etcd protocol built on top of Materia KV and FoundationDB, replicated across three Paris datacenters. This approach is also part of what makes Clever Cloud unique: a multi-tenant control plane that scales horizontally without degrading performance, benefits from FoundationDB’s continuous failure simulation model, and frees teams from managing thousands of fragile etcd instances.

But whether you choose CKE or another service, the principle remains the same: if you want Kubernetes in production without building a dedicated platform engineering team, a managed Kubernetes is almost always the right decision.

In Summary

Kubernetes became the standard for good technical reasons, but also thanks to an alignment of interests that drove the industry to converge around a neutral project governed by the CNCF. The core mechanism, the reconciliation loop and the declarative model, explains its robustness. The ecosystem that has built up around it explains its staying power.

That doesn't mean it should be adopted for everything. For many contexts, a PaaS or another approach is a better fit, and in practice, the two often coexist within the same architecture, each where it delivers the most value. For serious distributed architectures, it remains the tool of reference, provided you account for the operational debt it introduces and choose between running it yourself or relying on a managed service.

This is precisely the promise that Clever Kubernetes Engine, our managed Kubernetes, seeks to deliver: standard Kubernetes, operated in France on sovereign infrastructure, with a control plane redesigned to eliminate the friction of etcd at scale. And for teams that don't need Kubernetes, our PaaS remains the most direct path to production.

FAQ

Are K8S and Kubernetes the same thing?

Yes. K8S is an abbreviation: the letter K, followed by 8 (representing the eight letters in "ubernete"), followed by S. Both refer to the same container orchestration system.

What is the difference between Docker and Kubernetes?

Docker is a containerization engine: it packages an application with its dependencies into an image that runs as a container. Kubernetes is an orchestrator: it deploys, monitors, and scales those containers across a fleet of servers. This is one of the most commonly misunderstood distinctions in the ecosystem, even though the two tools serve different and complementary purposes.

Is Kubernetes free?

The software is open source and free under the Apache 2.0 license. But the infrastructure it runs on, the engineering time to maintain it, and the complementary tools (monitoring, backups, security) have a real cost. That's why many companies opt for a managed Kubernetes offering.

Do you always need Kubernetes for production deployments?

No. Kubernetes provides sophisticated orchestration, particularly suited to distributed architectures requiring portability, CNCF ecosystem alignment, or advanced orchestration. For many other contexts, a PaaS delivers the same outcomes (industrialized deployment, autoscaling, resilience) without the operational complexity. And in practice, the two approaches often coexist within the same architecture.

What is the difference between K3S and K8S?

K3S is a CNCF-certified Kubernetes distribution (not a fork), designed to be lightweight and suited for resource-constrained environments: edge, IoT, development machines, small clusters. It replaces some components with lighter alternatives and ships as a single binary. The differences between K3S and K8S come down to several specific architectural choices worth evaluating before making a decision.

How do I get started with Kubernetes?

The fastest way is to spin up a local cluster with Minikube, kind, or k3d, then deploy a simple application via a YAML manifest. For production, the reasonable choice for most teams is a managed Kubernetes offering.

This represents a major milestone that culminates three years of preparation and is part of our broader strategy to maintain complete control over our Paris region's network infrastructure.

Why We Made This Change

In Clever Cloud's early years, we delegated network responsibility to partners. This approach made sense: it allowed us to accelerate development, focus on cloud services, and avoid investing in expertise we hadn't yet mastered. But as our infrastructure grew, the limitations of this dependency became clear. We had no control over strategic decisions — how traffic was routed across the Internet, which paths our packets took, or how quickly we could respond to failures. Every modification, every incident required the involvement of a third party.

We decided to take this responsibility back. In doing so, we gained several concrete advantages. We optimize costs through direct management of our transit and peering relationships. We define our own routing policy instead of following an intermediary's constraints. We resolve incidents ourselves, without waiting for external providers. And we achieve complete control of our network stack — the same way we progressively took control of our servers and datacenters over the past few years.

But this transition isn't just about our operational independence. It brings immediate, tangible benefits for you. The most critical is resilience. Previously, all traffic was routed through a single provider. Any incident on their side impacted every service we offered. We now maintain four upstream providers across three datacenters in the Paris area. When one link fails — and it has happened over the past year — traffic automatically shifts to available alternatives without customer-impacting interruption. We can even withstand the simultaneous loss of multiple transit links.

Beyond redundancy, we gain control over routing itself. We now decide how your traffic reaches its destination. This allows us to optimize paths for lower latency and better performance, and to adjust those decisions based on your specific needs and our network topology. We respond to congestion, to changing conditions, and to your requirements in real time.

Finally, there is the question of operational responsibility. Network issues no longer require us to wait for an external provider to acknowledge and resolve them. Public network failures fall directly under our responsibility — we detect them, analyze them, and fix them ourselves. This directly reduces the time between problem and resolution, which means less downtime and better reliability for our customers.

Operating Your Own Network on the Internet

To operate as an independent network on the Internet, organizations must work with a Regional Internet Registry (RIR). RIRs are responsible for allocating and managing IP addresses and AS numbers within specific geographical regions.

There are five RIRs worldwide:

• RIPE NCC — Europe, Central Asia, and the Middle East
• ARIN — North America (United States, Canada, and the Caribbean)
• LACNIC — Latin America and the Caribbean
• APNIC — Asia-Pacific region
• AFRINIC — Africa

For Clever Cloud, since our infrastructure is primarily in Europe, we work with RIPE NCC (Réseaux Internet Publics Européens).

Allocated Address Space

As a member of a RIR, organizations receive allocations of both IPv4 and IPv6 address space. For RIPE NCC members, this typically includes a /24 block of IPv4 addresses (depending on the availability of such a block) and a /29 block of IPv6 addresses. These allocations are managed under your membership and can be used to operate your network globally.

Creating Our Autonomous System

The groundwork for this transition began several years ago. In 2019, we created our RIPE NCC account to become a LIR (Local Internet Registry). This gave us access to a /24 IPv4 block (91.208.207.0/24) and a /29 IPv6 block (2a0f:d0c0::/29).

Then, in 2022, we registered our Autonomous System Number (ASN) with the Regional Internet Registry for our region. Our AS number is AS213394. Here is the aut-num object:

> whois AS213394

aut-num:        AS213394
as-name:        CleverCloud
org:            ORG-CCS42-RIPE
import:         from AS29075 accept ANY
import:         from AS3257 accept ANY
import:         from AS3356 accept ANY
import:         from AS43424 accept ANY
export:         to AS29075 announce AS213394:AS-CLVRCLD
export:         to AS3257 announce AS213394:AS-CLVRCLD
export:         to AS3356 announce AS213394:AS-CLVRCLD
export:         to AS43424 announce AS213394:AS-CLVRCLD
admin-c:        QA171-RIPE
tech-c:         QA171-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         mnt-fr-clvrcldnet-1
created:        2022-11-28T08:24:23Z
last-modified:  2025-02-25T16:36:15Z
source:         RIPE

An Autonomous System Number (ASN) is a unique identifier for networks on the Internet. It's required to announce routes via BGP — the protocol that makes inter-network routing possible. Creating an AS early on allowed us to plan for this eventual transition and prepare the necessary infrastructure in advance.

Now that we have an ASN, we can start announcing our prefixes to other networks on the Internet using the BGP protocol.

The Role of the RIPE Database

The RIPE NCC maintains a public database of routing objects (like the aut-num object above). Among these objects are route objects, which specify which AS is authorized to announce a particular IP prefix. In practice, these entries are primarily used by network operators and transit providers to build routing policy and filters (IRR-based filtering) to accept or deny announcements from their peers. This is one way to try to prevent BGP hijacks. By applying those filters to the routes you receive from your peers, you can limit the propagation of a prefix that originates from the wrong ASN.

Let's say that Org A owns 192.0.2.0/24 and announces it to Transit X. Transit X applies a filter on routes learned from Org A to only accept the IP prefixes that Org A has in its RIR database. This way, if Org A starts announcing a prefix it doesn't own (let's say our public prefix, 91.208.207.0/24), then Transit X is supposed to reject that route. This helps prevent the bad route from being propagated and traffic from being forwarded to the wrong entity.

However, not all networks implement IRR filtering. Better mechanisms like ROA (Route Origin Authorization) exist to address this gap.

The BGP Protocol: How the Internet Routes Traffic

To understand how we announce our prefixes on the Internet, it's essential to understand BGP — the Border Gateway Protocol. BGP is the de facto standard routing protocol of the Internet. It allows networks (Autonomous Systems) to exchange information about which IP prefixes they own and how to reach them.

BGP works in both directions. When we announce to our peers and transit providers "we own 91.208.207.0/24", this announcement travels through the Internet from network to network. Each network that forwards our announcement prepends its own AS number to the AS_PATH — a list showing the sequence of networks a packet traverses to reach us. For example, OVHcloud (AS16276) sees the path [AS29075, AS213394]: traffic goes through one of our transit providers (AS29075), then reaches us (AS213394). Each network that forwards the announcement updates it this way, building a complete path. Here's an example using the OVHcloud Looking Glass service:

> show route for 91.208.207.0/24 all

91.208.207.0/24    via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
    Type: BGP unicast univ
    BGP.origin: IGP
    BGP.as_path: 29075 213394
    BGP.next_hop: 172.18.16.0
    BGP.med: 161
    BGP.local_pref: 40
    BGP.community: (0,0) (29075,18000) (65535,65281)
    BGP.23 [t]: 00 00 b8 6e
                   via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]

At the same time, we receive announcements from other networks about their prefixes and the paths to reach them. This builds the opposite view: when we need to send traffic outbound, we know which path to take to reach any given destination. Here's an example with one of OVHcloud prefixes:

> /routing/route/print detail where dst-address=5.39.0.0/17 and active

Ab   afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"

      bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igp

Here the network path OVHcloud uses to reach us is different from the one we use to reach them.

The Migration Process

Our IP prefixes were entirely managed by our historical provider. While we legally owned the addresses, we delegated the technical responsibility of announcing them to the Internet to this single provider. This meant:

• Our provider's AS (AS43424) was listed as the origin of our prefixes in the Internet routing tables
• All traffic destined for our services or outgoing to the Internet had to flow through their infrastructure

Clever Cloud Services
   |
   | all inbound/outbound traffic
   v
Historical Provider (AS43424)
   |
   | originates: 91.208.207.0/24 (origin AS43424)
   v
Internet

We now want our ASN to be the origin of the announcements. To migrate safely, we planned a three-step migration. The requirements were simple: we could not accept any customer-impacting interruption.

Migrating a prefix between ASNs

To migrate a prefix from one AS to another, we needed to modify its route object in the RIPE database. The procedure was straightforward but required careful timing.

First, we created a second route object in the RIPE database for our 91.208.207.0/24 prefix. Now both ASNs were registered as authorized to announce the same prefix — both our historical provider's AS and our own AS (213394).

These routing objects are publicly queryable via the whois command or through the RIPE web interface. For example, running whois -h whois.ripe.net -T route 91.208.207.0/24 returns both registered objects:

❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
descr:          CleverCloud subnet
origin:         AS213394
created:        2025-01-15T10:29:14Z
last-modified:  2025-01-15T10:29:14Z
source:         RIPE

% Information related to '91.208.207.0/24AS43424'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
mnt-by:         MAGICRETAIL-MNT
descr:          CleverCloud subnet
origin:         AS43424
created:        2020-02-13T09:06:33Z
last-modified:  2020-02-13T09:06:48Z
source:         RIPE

Once this second route object was registered and propagated across the Internet (i.e., network operators pulled an up-to-date version of the RIPE database to build their routing filters), our new transit providers could see that our ASN was authorized to announce this prefix. At that point, we could begin announcing the prefix through our own infrastructure.

If we didn't create that route object, our route announcement might have been rejected and we could have been flagged as BGP hijackers.

Announcing Through Our Historical Provider

Once the second route object was propagated, we performed the first step during the night of January 16, 2025: we began announcing the prefix ourselves via BGP to our historical provider. This was still using the same transit path, but now with Clever Cloud AS213394 originating the announcements instead of our historical provider. Our historical provider continued to relay the prefix, but now received it from us rather than announcing it directly.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   v
Historical Provider (AS43424)
   |
   | re-announces: 91.208.207.0/24 (origin AS213394)
   v
Internet

This first phase served as validation — if any issues arose, we could quickly revert without impacting other transit paths.

Announcing Through Our Own Transits

A few days later, during the night of January 21, 2025, we took the final step: we began announcing the prefix through our own dedicated transit connections.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   |
   +---+---+---+
   |   |   |   |
   v   v   v   v
  T1  T2  T3  HP
(Transit providers + historical provider)
   |   |   |   |
   +---+---+---+
   |
   v
Internet

We now announce our prefixes directly to four upstream providers (three transit providers, T1/T2/T3, plus our historical provider HP). Traffic flows across all paths, and we have full control over routing decisions and redundancy.

Throughout both phases, we observed no customer-impacting interruption. The BGP protocol's built-in redundancy and the gradual nature of the transition ensured that traffic flowed smoothly regardless of which path was preferred at any given moment.

Complete Internet Routing Visibility

As part of Phase 2, our three primary transit providers began sending us a "full view" of the Internet's routing table. This is the complete set of all publicly announced IPv4 and IPv6 prefixes — roughly ~1 million IPv4 routes and ~220,000 IPv6 routes.

A full view gives us unprecedented visibility into how the Internet is structured and allows us to make sophisticated routing decisions. Rather than relying on a single provider's perspective, we now see all available paths to reach any destination on the Internet.

With this information, we are able to:

• Choose optimal paths for our outbound traffic based on our network topology and preferences
• Implement traffic engineering to direct flows through specific transit providers
• Respond dynamically to network conditions and congestion
• Balance load across our four transit connections based on real-time routing data

This fine-grained control over our routing policy is a direct result of operating our own AS and managing our own announcements — exactly the kind of operational independence we sought when we began this transition.

One Year Later

Nearly a year into operating our own network announcements, the transition has proven successful. We have experienced no major incidents, and our infrastructure has proven resilient. When minor issues have occurred — such as packet loss through a specific transit provider or the temporary loss of a transit link — traffic has automatically rebalanced across our remaining connections. We have been able to detect and respond to these issues directly, without waiting for a third-party provider to take action. Our customers experienced no customer-impacting interruption. This ability to own our problems and resolve them quickly is perhaps the greatest benefit we've gained.

What's Next

This transition is far from finished. We have several roadmap items ahead of us:

• Increased network capacity to handle growing traffic demands
• BGP peering with other networks to optimize traffic locally without paying for transit
• ROA (Route Origin Authorization) deployment to cryptographically sign our route announcements and prevent unauthorized parties from hijacking our prefixes
• RPKI (Resource Public Key Infrastructure) validation to ensure the legitimacy of announcements we receive from other networks and protect against prefix hijacking attacks
• IPv6 expansion, both inbound (accepting IPv6 traffic) and outbound (sending IPv6 traffic) — a transition we will roll out in phases

Conclusion

In early 2025, Clever Cloud completed its transition to fully independent network operations. We now announce our own IP prefixes through four upstream providers, giving us full authority over how traffic flows in and out of our infrastructure.

For our customers, this translates to better reliability and faster problem resolution in our Paris region. When network issues occur, we handle them directly — and our multi-provider redundancy ensures traffic keeps flowing even when incidents occur.

This milestone is just the beginning. We're already working on BGP peering to optimize local traffic, ROA signing and RPKI validation to strengthen routing security, and IPv6 expansion to fully embrace dual-stack connectivity. We're building a network as robust and self-sufficient as the rest of our infrastructure — and we're excited about what comes next.

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.

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!

Nantes, France — Clever Cloud, a European cloud provider, announces the public beta launch of Clever Kubernetes Engine (CKE) on April 27, 2026, in the afternoon. The product will be previewed at Devoxx starting April 22, where attendees will be able to test it directly at the Clever Cloud booth.

Built for production and scalability

Kubernetes has become the standard for container orchestration. Clever Cloud spent two years developing a managed, sovereign version designed to integrate naturally into the Clever Cloud ecosystem and operate with the same simplicity as the platform's other services. CKE is built to handle real production workloads, with high scalability and predictable behavior at scale.

To achieve this, Clever Cloud developed Materia etcd, a reimplementation of Kubernetes' internal consistency layer built on FoundationDB. This foundational work — invisible to the end user — is what guarantees CKE's robustness and stability in production, notably through native auto-scaling and auto-healing capabilities.

CKE integrates natively with existing Clever Cloud services — Cellar object storage (S3-compatible), managed databases, IAM as a Service, Network Groups — and remains accessible via standard industry tools: kubectl, Helm, or GitOps.

Sovereign by design

Hosted and operated in Europe by Clever Cloud on its public cloud, CKE offers organizations a concrete alternative to the Kubernetes offerings of major American platforms, without compromising on performance or legal data control. CKE can also be deployed on the customer's own on-premises infrastructure.

Access details

The public beta is open to all Clever Cloud customers from April 27, 2026, via feature activation performed by the user. Notably, some customers have already had access through a private test for over six months, allowing the product to be refined before this general release.

"Clever Cloud has long developed alternatives to Kubernetes. Our customers expressed a clear need for this technology, and we decided to build it alongside them, with the level of technical excellence and sovereignty that defines our platform." — Quentin Adam, CEO of Clever Cloud

Learn more

BSL is not an open-source license as defined by the Open Source Initiative: it restricts commercial use deemed competitive with HashiCorp's offerings. Overnight, thousands of organizations that had built their infrastructure around Terraform found themselves in uncomfortable legal uncertainty.

The response was swift. Less than a month after the announcement, a manifesto calling for a return to an open-source license had gathered 33,000 GitHub stars and the support of nearly 140 companies. HashiCorp did not budge. The fork was published in September 2023, brought into the Linux Foundation, and renamed OpenTofu. Since January 2024, it has been in stable production. Since April 2025, it has been part of the Cloud Native Computing Foundation (CNCF).

Our Terraform provider is fully compatible with OpenTofu. No changes to your configurations are needed to use it.

What is OpenTofu?

OpenTofu is an open-source infrastructure as code (IaC) tool, forked from the last MPL 2.0-licensed version of Terraform (1.5.x), distributed under that same Mozilla Public License 2.0. It lets you describe, provision, and manage cloud infrastructure through declarative configuration files written in HashiCorp Configuration Language.

It is developed under the governance of the Linux Foundation, with a Technical Steering Committee made up of representatives from multiple organizations — Gruntwork, Spacelift, Harness, Env0, Scalr — so that no single company can control its direction. That governance model is precisely what convinced many teams to make the switch: a guarantee that the tool will remain truly open source, regardless of how its contributors evolve commercially.

In practice, OpenTofu works with the same .tf files, the same providers, the same modules, and the same CLI workflow as Terraform — init, plan, apply, destroy. For the vast majority of teams, migrating comes down to replacing the binary.

What's the actual difference with Terraform?

The main difference is the license, and everything it implies in the long run.

Terraform is now distributed under the BSL, which restricts commercial uses that could be considered competitive with HashiCorp — a deliberately vague notion that HashiCorp (now a subsidiary of IBM) may interpret differently in the future. OpenTofu is distributed under MPL 2.0, a true open-source license with no commercial restrictions.

Beyond the license, the two projects have started to diverge technically since the fork. The most notable differences to date:<ul> <li><strong>State encryption:</strong> OpenTofu natively supports client-side encryption of state files — a feature long requested by the community that Terraform has still not implemented.

• Governance: OpenTofu is steered by a multi-organization technical committee within the Linux Foundation. Terraform is controlled by IBM via HashiCorp, with a roadmap driven by commercial priorities.
• Compatibility: OpenTofu maintains syntactic and functional compatibility with Terraform. Existing providers, modules, and configurations work without modification for the vast majority of use cases.
• The .tofu extension: OpenTofu supports this extension alongside .tf, allowing module authors to provide OpenTofu-specific variants while remaining compatible with Terraform.
• Terraform Actions: HashiCorp introduced "actions" in Terraform 1.9+, a feature that lets you trigger custom behaviors during resource lifecycle events. OpenTofu does not yet support them — this is the inherent trade-off of any fork: new proprietary Terraform features are not automatically available, and their implementation in OpenTofu depends on the technical committee's priorities.

Why teams are migrating to OpenTofu

Three reasons come up consistently.

Legal risk. The BSL prohibits using Terraform in products that could compete with HashiCorp's commercial offerings. For teams building internal platforms, cloud products, or managed services, this uncertainty is a real operational risk — especially since the definition of "competitive" belongs to HashiCorp and can evolve. On top of that, there is a less visible but equally significant reality: in the Terraform registry, open-source providers get no special visibility. Getting an "official" badge requires negotiating directly with HashiCorp — and paying for it. In the OpenTofu registry, all providers are on equal footing, regardless of the size or resources of their maintainers.

Strategic autonomy over tooling. Your infrastructure as code is the foundation of everything else. Depending on a tool controlled by a US company subject to the Cloud Act means introducing an additional dependency that many organizations would rather avoid. OpenTofu, under Linux Foundation / CNCF governance, offers continuity independent of any commercial actor.

Features Terraform doesn't ship. Native state file encryption is the most frequently cited example: requested by the community for years, implemented within months by OpenTofu. It is also a signal about how quickly community-driven governance can respond to real needs, compared to a roadmap driven by commercial interests.

Migrating from Terraform to OpenTofu

For the vast majority of teams, migration takes a matter of minutes. All you need to do is make sure the state is clean, install OpenTofu, and replace terraform with tofu in your commands.

# Make sure your state is clean before migrating terraform plan 

# → "No changes. Your infrastructure matches the configuration."

 # Install OpenTofu on macOS brew install opentofu 

# Install OpenTofu on Linux 

curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh 

# Resume your normal workflow 

tofu init 

tofu plan

tofu apply

Existing .tf files do not need to be modified. The OpenTofu registry mirrors all providers available on the Terraform Registry — including the Clever Cloud provider.

OpenTofu on Clever Cloud: nothing to change

Our official provider (CleverCloud/clevercloud, currently version 1.10) works identically with both Terraform and OpenTofu. The provider source, HCL syntax, and all available resources are exactly the same. A minimal example to deploy a Node.js application with a PostgreSQL database:

terraform {

  required_providers {

    clevercloud = {

      source  = "CleverCloud/clevercloud"

      version = "~> 1.10"

    }

  }

}

provider "clevercloud" {organisation}

resource "clevercloud_node" "app" {

  name       = "mon-app-node"

  region     = "par"

  min_flavor = "XS"

  max_flavor = "M"

}

resource "clevercloud_postgresql" "db" {

  name   = "ma-base-postgres"

  region = "par"

  plan   = "dev"

}

tofu init

tofu plan

tofu apply

The OpenTofu + Clever Cloud combination is a fully sovereign IaC stack: open-source tooling under Linux Foundation / CNCF governance, infrastructure hosted in our own data centers in France, outside the reach of the US Cloud Act. It is the choice increasingly made by teams who want full control over their entire toolchain — not just their data.

The Clever Cloud provider is available on the Terraform Registry and fully open source on GitHub.

Q&A

Is OpenTofu compatible with my existing Terraform configurations?

For the vast majority of use cases, yes. OpenTofu maintains syntactic and functional compatibility with Terraform. Existing .tf files, providers, and modules work without modification. Testing in a non-production environment before switching critical workloads is recommended.

Is OpenTofu production-ready? 

Yes. The first stable version was released in January 2024. The project has since surpassed 10 million downloads and is used in production by organizations of all sizes, including Fortune 500 companies. Its integration into the CNCF in April 2025 reinforced its credibility for enterprise environments.

What is the open-source alternative to Terraform? 

OpenTofu is the primary open-source alternative to Terraform. Distributed under MPL 2.0, maintained by the Linux Foundation, and a CNCF member, it is the direct continuation of Terraform in its original open-source state.

Is the Clever Cloud Terraform provider compatible with OpenTofu? 

Yes, with no configuration changes required. Our official provider (CleverCloud/clevercloud) works identically with both Terraform and OpenTofu.

How does OpenTofu work? 

In the same way as Terraform: you describe the target state of your infrastructure in HCL, OpenTofu computes the necessary changes (tofu plan) and applies them (tofu apply). It manages dependencies between resources, the state, and the full lifecycle of each resource. This is also where IBM's acquisition of HashiCorp introduces additional uncertainty: projects built around Terraform, such as CDK for Terraform, could be deprioritized or discontinued based on IBM's commercial decisions. With OpenTofu, the roadmap is public, discussed through open RFCs, and does not depend on decisions made behind closed doors by a single actor.

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.