Early on, we recognised that building a coherent and extensible cloud platform did not require creating every component ourselves. It required connecting the right technologies, operators and expertise within an open ecosystem.

At the heart of our strategy are three foundational pillars: customer centricity, innovation through collaboration, and mutual growth. These principles guide how we work with partners, support our users, and continuously enhance our platform.

1. Customer Centricity

Our first and foremost commitment is to our users. Every partnership we forge is evaluated through the lens of customer value. Does it address a real need? Does it simplify processes? Does it contribute to a better experience for developers and teams?

When our users expressed the need for enhanced observability capabilities, we didn’t just take note, we acted. For example, our partnership with Elastic brought Elasticsearch into our ecosystem in a way that is fully integrated, production-ready, designed to work seamlessly from day one. This made Clever Cloud one of the very few global players able to offer Elasticsearch Platinum. It's a clear example of how we listen, respond, and collaborate to create tangible impact.

Customer centricity is more than listening; it’s about co-developing practical, scalable solutions that simplify everyday operations. Our goal is to ensure that the services we provide and the partnerships we cultivate consistently reduce complexity, enhance reliability, and support developers through every stage of their application lifecycle.

2. Innovation Through Collaboration

True progress occurs when diverse minds come together to tackle complex challenges. At Clever Cloud, we view collaboration not as a convenience, but as a catalyst for innovation. We work alongside a wide range of partners, from open-source communities and research institutions such as Institut Mines-Télécom to industry consortia, to explore new ideas and build forward-looking technologies.

We actively contribute to open-source projects like Eclipse Biscuit, Sōzu, and Exherbo Linux, which are integral to our cloud stack. Our contributions help drive development in areas critical to both our infrastructure and the broader ecosystem.

In parallel, we engage with European and national initiatives such as ReNESENS, Hyper Open X, and CollabNext, helping to shape standards, foster knowledge exchange, and build next-generation technologies. We also partner with academic and research institutions, encouraging experimentation and long-term thinking that benefits everyone in the tech ecosystem, from students, professors and research labs to leading edge innovation engineering teams and industrialization.

In this context, our commitment to innovation through collaboration is also a key enabler of the Strategic Digital Autonomy approach: we believe in cultivating autonomy by fostering interoperability, reversibility, and transparency through open standards and open-source technologies. This reinforces our partners’ and customers’ ability to adapt, evolve, and remain competitive.

3. Mutual Growth

We believe that strong partnerships should be mutually rewarding. That’s why we strive to create opportunities that help both Clever Cloud and our partners grow together.

Our marketplace reflects this philosophy. It brings together Clever Cloud’s core services with powerful tools and technologies from partners like Elastic, Azimutt, MailPace, and open-source projects such as Keycloak, Metabase, Otoroshi among many others.

We embrace two distinct types of relationships for the Marketplace: first-party add-ons, which are co-created with partners and fully managed by Clever Cloud as part of our platform; and third-party add-ons, where Clever Cloud acts as a distribution channel while the partner independently manages and supports their service; 

In addition to this, we also develop strategic partnerships, where we collaborate with trusted providers to integrate their solutions into our portfolio, ensuring our customers have access to a broad, reliable toolkit for their infrastructure needs.

This ecosystem allows our customers to access a rich, integrated suite of services in a unified environment, while giving our partners valuable visibility and access to our user base.

Mutual growth also means ensuring that Clever Cloud and its ecosystem work seamlessly with other bare metal and IaaS cloud service providers, expanding the flexibility, performance, and scalability options available to our users. As such, in addition to its own infrastructure, Clever Cloud is also available on a range of leading European sovereign cloud service providers, including OVHcloud, Scaleway, Cloud Temple and 3DS OUTSCALE’s SecNumCloud services.

In the same way in Africa and Asia, we collaborate with local actors to foster digital sovereignty and cloud adoption by supporting infrastructure strengthening and local talent development, co-developing solutions that embrace open innovation and technology reversibility. 

We extend this mutual growth commitment through our UP startup program, which supports emerging companies with technical resources, mentorship, and market insights. It is designed not just to provide credits, but to deliver meaningful guidance and opportunities for growth.

A Shared Vision for the Cloud

These three pillars, customer centricity, innovation through collaboration, and mutual growth, are not separate initiatives. They are deeply interconnected values that shape how we build, grow, and engage with our ecosystem.

At Clever Cloud, we’re not just talking about partnerships: we’re taking the initiative to build them. We’re actively engaging with database, developer tools, security, user-facing SaaS providers, and other technology vendors. Whether you’ve already been approached or not, this is an open invitation to join forces, know that we’re still ready to build together with one clear message: our goal is to complement existing catalogs, not to do everything alone.

Our mindset is all about revenue sharing, not about one party financing the other. We’re in this as equals, aiming to co-create value and drive real impact. This isn’t a ‘wait-and-see’ mindset. It’s a deliberate, open, and proactive stance, and we’re looking for partners who share it.

Ultimately, these partnerships are not just about growth, they’re about delivering real, tangible benefits to cloud users. By combining complementary expertise, we broaden what customers can deploy, reduce integration work and accelerate access to production-ready technologies. The result is a more coherent and reliable experience for developers, startups and enterprises.

If this approach resonates with you, get in touch. Let’s build something meaningful together.

We lead the project and are its principal contributor (github.com/sozu-proxy/sozu). With Sōzu 2.0, we explained how the proxy moved from "reverse proxy" toward "programmable edge": a new HTTP/2 multiplexer, stronger security defaults, a larger observability surface, traffic policies, operational hardening, and crypto agility.

Sōzu 2.0.2 came a few days later with a smaller but revealing release. It added defence-in-depth against the HTTP/2 bomb class and fixed the timestamp foundation needed to reconstruct trustworthy OpenTelemetry spans from access logs. That release showed how we want to operate the edge: when a protocol-level attack class appears, the proxy should absorb as much of it as possible; when observability is subtly wrong, the foundation should be fixed before product features are built on top.

Sōzu 2.1.0 is the next step in that same story. One of the pieces we described as "on the bench" for 2.0 has landed: first-class UDP load balancer support.

This is not just one more protocol checkbox. Sōzu already handled HTTP, HTTPS, and TCP. With 2.1.0, UDP becomes part of the same model: the same hot-reconfigurable control plane, the same operator-facing posture, the same metrics discipline, and the same open-source release process. That widens Sōzu from a web edge into a broader infrastructure load balancer, able to front datagram services such as DNS, syslog, NTP, and generic UDP workloads without forcing operators to put a second load balancer in front of it.

For Clever Cloud, this matters because platform networking is broader than HTTP. Managed Kubernetes and PaaS both need a clean story for direct transport traffic. For operators running Sōzu themselves, it means one component can cover more of the L4/L7 surface while preserving the design properties that made Sōzu useful in the first place.

Why UDP still matters

Most user-facing traffic on the web goes through HTTP, and it is tempting to treat everything else as a special case. Real platforms do not get that luxury.

DNS is UDP by default. Syslog often runs over UDP. NTP is UDP. Many internal and infrastructure protocols use datagrams because they are simple, latency-sensitive, or request/response shaped enough that a full TCP connection is unnecessary. Kubernetes platforms and PaaS products also need to expose direct transport services cleanly, not only web applications that terminate at HTTP.

Before Sōzu 2.1.0, an operator wanting a single edge for HTTP, TCP, and UDP usually had to compose multiple systems. Sōzu could handle the HTTP and TCP side, while a separate component handled UDP. That split carries operational cost: two models of health checking, two ways to observe traffic, two release cycles, two failure surfaces, two sets of configuration, and two places where routing state can drift.

The point of first-class UDP in Sōzu is convergence. A UDP listener now sits beside tcp, http, and https listeners. UDP frontends and backends are part of the same command, configuration, and state machinery. Operators get UDP-specific metrics at the proxy instead of treating datagram traffic as something happening off to the side.

The customer-facing benefit is not that every application suddenly needs UDP. It is that the platform can converge more traffic classes under one operational model: hot reconfiguration, health awareness, metrics, release discipline, and a single edge component that can evolve toward product features rather than remaining a pile of protocol-specific exceptions.

What is available in Sōzu 2.1.0

Sōzu 2.1.0 adds a new protocol = "udp" listener type alongside the existing HTTP, HTTPS, and TCP listeners. It is opt-in. Existing configurations do not become UDP-aware by accident, and existing sozu-command-lib consumers can move from 2.0.2 to 2.1.0 without rewriting their integrations.

The central idea is to model UDP traffic as virtual flows. UDP itself has no connection, no stream, and no accept loop. A datagram arrives on one socket. There is no kernel-created per-client socket like there is with TCP. Sōzu therefore reconstructs the useful part of a connection in userland: a flow keyed by the client source address, optionally including the source port when that is the right affinity model for the workload.

Once Sōzu has a flow, it can make the same class of decisions a load balancer has to make for any transport:

• which backend owns this client;
• how long this flow should stay alive;
• what happens when a backend becomes unhealthy;
• how overload should be shed;
• what metrics and logs should be emitted.

The release adds two flow-affine algorithms for UDP. The recommended default is HRW, also known as rendezvous hashing. HRW has a property that matters a lot for hot-reconfigurable systems: when the backend set changes, it minimizes movement without requiring a precomputed lookup table. Sōzu also ships Maglev as an opt-in algorithm for larger backend sets or higher packet rates where an O(1) table lookup is more attractive.

Sōzu can also send PROXY protocol v2 information to UDP backends. This carries the real client address to the backend, so the backend does not have to treat the proxy as the only visible peer. By default, Sōzu sends it on the first datagram of a flow, with an opt-in mode to send it on every datagram when the backend needs that context repeatedly.

Health checking is part of the UDP design rather than an afterthought. A UDP backend can be checked through a companion TCP probe, which is the common practical liveness signal for services where bare UDP does not provide a reliable "connected" state. Sōzu can also use an application-level UDP probe when that is meaningful. The checks support rise/fall hysteresis and fail-open semantics, so a transient or global health-check failure does not automatically black-hole traffic.

Finally, UDP gets its own metric surface: datagrams in and out, bytes in and out, active flows, created, evicted, or shed flows, dropped datagrams by reason, backend health, and flow duration. This follows the same principle as the 2.0 observability work: a feature is not production-grade until operators can see what it is doing.

UDP is easy to add badly

The hard part of UDP load balancing is not receiving a datagram and sending it somewhere else. The hard part is deciding what state exists around that datagram.

TCP gives a proxy a connection lifecycle. HTTP gives it requests, responses, headers, and status codes. UDP gives it packets. Packets can arrive out of order. They can disappear. A client can stop sending without closing anything, because there is nothing to close. A backend can become unhealthy while a virtual flow still points to it. A reconfiguration can arrive while flows are active. A listener can reach its flow cap. A timeout can fire just after the flow was refreshed. These are not exotic cases. They are the normal shape of datagram traffic under load.

That is why the Sōzu 2.1.0 UDP work is as much about testability as it is about features.

The UDP core is structured around a sans-io split. The pure core owns the flow table, admission decisions, timers, teardown policy, and load-balancing requests. The impure shell owns sockets, the buffer pool, health checks, syscalls, and metrics emission. The core has no socket, no wall-clock read on the datapath, no random source hidden inside it. Time and seeds are injected.

That shape matters because it makes the core deterministically simulatable. The same seed drives the same sequence. The same virtual clock jumps to the same instants. The same reconfiguration storm happens at the same step. A failure can print a seed and be replayed exactly.

Sōzu 2.1.0 ships a FoundationDB/VOPR-style deterministic simulation harness for the UDP core. The default sweep runs 256 seeds, each driving a randomized adversarial workload through client datagrams, backend replies, stale backend resolutions, reconfiguration bursts, flow-cap changes, clock jumps, drains, and mass teardown. After each action, the harness drains the core outputs and checks model invariants.

On top of that, the release includes an assertion-density sweep inspired by TigerBeetle's TigerStyle. Across the proxy, command plane, and supervisor, Sōzu now carries roughly 1100 debug_assert! checks and multiple invariant sweeps. These assertions are compiled out of release builds, but they are live in tests, fuzzing, end-to-end runs, simulations, and developer builds. They turn a silent state drift into a loud, local failure.

Those numbers are useful because they are not volume metrics. Lines of code do not prove reliability. A 256-seed simulation sweep and dense invariants do tell you something: the code is being driven through adversarial state transitions, and the data structures are continuously asked to prove that they still make sense.

For a proxy, that distinction matters. A wrong counter is not just a counter. It may mean a flow is leaked. A stale timer is not just a timer. It may mean a backend keeps receiving traffic after the state says otherwise. A silent mismatch between a routing table and a slab is not just an internal inconsistency. It is the kind of thing that becomes a production symptom several layers away from the bug.

Deterministic simulation as a direction

The UDP simulator is also a signal about where we want Sōzu engineering to go next.

FoundationDB made deterministic simulation famous in infrastructure software: run the system inside a simulated world, inject failures, explore thousands of schedules, and make every failure reproducible from a seed. TigerBeetle pushes a complementary discipline: state your invariants directly in the code, assert both the positive and the negative space, and make illegal state impossible to ignore during testing.

Sōzu 2.1.0 applies those ideas to the UDP core. The next architectural effort is to make more of Sōzu fit this shape: more sans-io components, more injected clocks and deterministic boundaries, more layers that can be simulated across the relevant parts of the OSI stack before they are exposed as production behavior.

This is also why Moonpool matters to Clever Cloud. Moonpool, developed by PierreZ, is the deterministic-simulation engine we use at Clever Cloud for this direction in Rust. Version 0.7.0 has now landed publicly on crates.io, including moonpool and moonpool-sim. Sōzu's UDP harness is currently an in-tree synchronous simulator shaped around the pure UDP core, but the broader direction is the same: deterministic workloads, virtual time, reproducible seeds, and networked systems that can be made to fail before production gets the chance.

The primary benefit is reliability. We want fewer edge-case bugs in protocol and reconfiguration code. The second benefit is velocity. When more of the proxy is structured as pure state machines with explicit I/O boundaries, new protocol and load-balancing behavior becomes safer to evolve. The third benefit is operability. Hot reload, overload, and failure behavior become easier to reason about because the code has been exercised under those exact shapes.

That is the next layer under the programmable edge. The knobs exposed to users are only worth exposing if the machinery beneath them is deterministic enough to trust.

What this unlocks

For managed Kubernetes, UDP support gives Sōzu a stronger basis for direct transport services. A platform can offer web traffic, TCP services, and UDP services under a more coherent load-balancing model, rather than splitting responsibilities between unrelated components.

For PaaS, it opens the way to product features around datagram workloads without starting from a separate operational stack. DNS-like services, syslog-like flows, NTP-like probes, and generic UDP applications can be reasoned about through the same proxy vocabulary: listeners, clusters, backends, health, metrics, and hot reconfiguration.

For self-hosted Sōzu operators, it means the project covers more of the infrastructure edge. If you already use Sōzu because you want an open-source, hot-reconfigurable proxy with signed releases and a Rust codebase you can audit, 2.1.0 expands the class of traffic you can bring under that umbrella.

There is an observability consequence too. UDP traffic now has native proxy metrics. You can ask how many flows are active, how many were shed, why datagrams were dropped, whether backends are healthy, and how long flows live. This is what turns a protocol feature into something operators can run.

Reliability also comes from the release around UDP

The headline is UDP, but 2.1.0 also continues the operational work from 2.0.

Hot reconfiguration is one of Sōzu's core promises, so state replay correctness matters. This release fixes a case where a listener whose configuration changed while it remained active could be replayed as remove plus add without re-emitting activation. That kind of bug is exactly why the state model has to be tested as a lifecycle, not only as isolated commands.

The release also fixes an arithmetic-underflow panic in the pattern trie for hostnames whose leftmost segment is a regex. It fixes the release pipeline by pinning the cosign binary to the 2.x line, after a tooling change broke the signature artifact flow during the 2.0.2 release.

These are not the parts of the release that users will see first. They are still part of the product. At Clever Cloud's scale, operational quietness is a customer benefit. A proxy that reconfigures safely, signs its artifacts predictably, and turns edge cases into tests is a proxy that lets applications keep serving traffic while the platform moves underneath them.

What comes next

UDP support will continue to mature with real-world use. There is room for performance work, batching, and broader operational feedback. But the larger direction is architectural: make more of Sōzu deterministic, make more of it sans-io where that makes sense, and make more failure modes reproducible before they can become incidents.

That is the lesson from Sōzu 2.1.0. The programmable edge is not only a set of user-facing toggles. It is also a way of building infrastructure software: protocol by protocol, state machine by state machine, with enough observability to operate it and enough simulation to trust it.

Sōzu is open source under AGPL-3.0, with its command library under LGPL-3.0. The code, release notes, issues, and design discussions live at github.com/sozu-proxy/sozu. Thank you to the contributors and operators who keep pushing the project toward a broader, safer, more programmable edge.

References

Sōzu

• Sōzu 2.1.0 release notes. First-class UDP load balancing, deterministic simulation, assertion-density work, CI and documentation updates. https://github.com/sozu-proxy/sozu/releases/tag/2.1.0
• Sōzu UDP RFC and master plan. Public design issue for first-class UDP load balancing. https://github.com/sozu-proxy/sozu/issues/1273
• Sōzu UDP implementation PR. Implementation of first-class UDP listeners and load balancing. https://github.com/sozu-proxy/sozu/pull/1274
• Long-standing UDP load-balancing issue. Original public tracking issue opened in 2020. https://github.com/sozu-proxy/sozu/issues/654
• Sōzu 2.0: turning a reverse proxy into a programmable edge. Milestone release article. https://www.clever.cloud/blog/engineering/2026/05/29/sozu-2-0-reverse-proxy-programmable-edge/
• Sōzu configuration documentation. UDP listeners, UDP clusters, health checks, PROXY protocol, and metrics. https://github.com/sozu-proxy/sozu/blob/2.1.0/doc/configure.md
• Sōzu testing documentation. Testing doctrine: unit, e2e, fuzz, deterministic simulation, and regression guards. https://github.com/sozu-proxy/sozu/blob/2.1.0/doc/testing.md
• Sōzu UDP simulation documentation. 256-seed default sweep and replay knobs. https://github.com/sozu-proxy/sozu/blob/2.1.0/doc/udp_simulation.md

Protocols and algorithms

• PROXY protocol v2 specification. Client-address propagation across proxies. https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
• Rendezvous hashing / HRW. Flow-affine selection with minimal disruption on backend-set changes. https://en.wikipedia.org/wiki/Rendezvous_hashing
• Maglev: A Fast and Reliable Software Network Load Balancer. Google paper describing Maglev consistent hashing. https://research.google/pubs/maglev-a-fast-and-reliable-software-network-load-balancer/

Testing

• FoundationDB testing. Deterministic simulation and fault injection lineage. https://apple.github.io/foundationdb/testing.html
• TigerBeetle TigerStyle. Assertion-first engineering style. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md
• TigerBeetle VOPR. Simulation testing approach. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/internals/vopr.md
• Moonpool. Deterministic simulation testing for distributed systems in Rust. https://crates.io/crates/moonpool
• moonpool-sim. Simulation engine for the Moonpool framework. https://crates.io/crates/moonpool-sim
• Moonpool repository. Developed by PierreZ. https://github.com/PierreZ/moonpoo

To understand why such a mechanism is necessary, it is enough to look at what has already happened. In 2023, a French data-management software vendor with more than fifteen years on the market was acquired by an American investment fund specialising in technology assets. A perfectly legal transaction, yet one that illustrates a risk few organisations anticipate: the moment a European technology player comes under non-European control. For customers who had made this choice partly for reasons of legal proximity or data governance, the acquisition raised a question their existing contracts did not address. Not the portability of data, but the durability of sovereignty.

This case is not isolated. It is structural.

For several years, public administrations, critical sectors and strategic players have sought to reduce their technological dependencies by favouring European providers. Hosting in Europe, workforce, decision-making headquarters and most R&D in Europe, European jurisdiction, control of capital: these criteria have become reflexes. Legitimate and necessary.

But they all answer the same question: who is this provider today?

Rarely another, equally essential one: who will it be tomorrow?

Sovereignty assessed at a single point in time

When an organisation chooses a European cloud provider, it generally checks where the data is hosted, which jurisdictions apply, who controls the company, and which certifications are held. These criteria make it possible to assess the present situation.

But the digital industry is structurally marked by constant consolidation. A company that is independent today may change hands within five years. In that scenario, the guarantees originally sought can shift profoundly, without the physical infrastructure changing by a single byte.

The servers stay in Europe. The data continues to be stored there. The contracts remain in force. But the centre of decision-making, the strategic direction and effective control of the technology can move outside the European perimeter.

An economic model that amplifies the risk

The issue is also macroeconomic. Part of the sovereignty risk comes not only from the technology, but from how certain digital companies are funded and valued.

European players, sometimes backed by public funding, innovation support schemes or the confidence of national institutions, can be built with an implicit trajectory of resale to private equity funds or non-European groups. In that scenario, the management of critical data, initially presented as a sovereign service, gradually becomes a marketable asset that can be transferred to non-European interests.

The Ultimate Sovereignty Clause is not intended to prohibit such transactions or to impose a general constraint on the market. Its purpose is to introduce an explicit and verifiable commitment that distinguishes companies genuinely committed to sovereignty over the long term from those whose model ultimately rests on the possible sale of a strategic dependency.

What conventional reversibility does not cover

The usual answer to digital dependency is reversibility: assuring customers they can retrieve their data if they decide to change provider. This is a necessary protection, and it can be sufficient for data of low sensitivity. But as criticality rises, reversibility alone is no longer enough. It must be paired with guarantees set at a credible level of proportionality, meaning commitments whose strength matches the sensitivity of the data involved.

A digital platform is more than the data it hosts. It runs on software, deployment tools, orchestration mechanisms, operating procedures, documentation and configurations. In many cases, retrieving the data without access to this technical environment is not enough to rebuild a working service.

The real dependency is not on the data. It is on the ability to operate the platform as a whole.

The Ultimate Sovereignty Clause

To address this, Clever Cloud has designed a new contractual mechanism for contracts covering critical or sensitive public services: the Ultimate Sovereignty Clause.

The principle is simple. If control of a European provider passes to a non-European entity, the mechanism triggers automatically, with no formality or external approval. Concretely, if Clever Cloud were to come under the control of a non-European player, the continuity rights defined in the contract would become exercisable by the designated public beneficiary: a government body, a local authority, a public institution or a European public operator. Where the takeover requires specific technical expertise, this beneficiary can appoint an authorised European operator, bound by the security and confidentiality requirements set out in the contract.

Within this framework, the technical elements identified as necessary to resume the service (certain software components, deployment scripts, orchestration elements, technical documentation and operating procedures) can be mobilised to organise temporary continuity or a controlled migration to a European solution.

One important clarification: the Ultimate Sovereignty Clause does not replace existing guarantees, it extends them. A SecNumCloud-qualified or GDPR-compliant provider already offers solid sovereignty guarantees during the term of the contract. What these schemes do not cover is what happens after a change of control, and that is precisely the risk the Ultimate Sovereignty Clause addresses. It does not make Clever Cloud's code open source and involves no general handover of production keys or secrets.

A logic of resilience, not portability

The distinction matters. Conventional reversibility is a logic of exit and migration: it sets the conditions under which a customer can leave a provider or move their service to another. The Ultimate Sovereignty Clause is a logic of continuity: it ensures the service can keep running within a controlled framework, even in a scenario of major disruption. It does not seek to prohibit an acquisition or to call into question the freedom of capital transactions: an acquirer can buy the company, but cannot use that acquisition to block or capture a sovereign dependency built around public services.

This approach is part of current debates on digital resilience, alongside requirements of security, compliance and availability. The Ultimate Sovereignty Clause raises a further question: can an organisation maintain its operational autonomy if its provider changes structurally?

A mechanism designed to become a standard

Clever Cloud designed this mechanism for its own contractual commitments. But the ambition goes further.

The Ultimate Sovereignty Clause is designed to be replicable by any European provider that wants to ground its customer relationships in lasting trust. It is meant to fit into existing digital-resilience frameworks, supplier-dependency assessment criteria, and the sovereignty doctrines advanced by institutional bodies in each sector.

A company that accepts this kind of commitment sends a clear signal: its value does not rest on the prospect of a future sale to a foreign player, but on a long-term model built on service continuity and trust.

Digital sovereignty is not measured only by where the data sits today. It is also measured by the ability to ensure that critical infrastructure remains controllable, whatever the ownership future of those who operate it.

Today we're opening the private beta of Openvisio, our video conferencing solution fully operated by Clever Cloud on European datacenters and developed in partnership with Vopenia, a software vendor specialized in real-time communication.

Openvisio deploys as an add-on within an existing Clever Cloud organization, alongside Docs, Grist and Clever Kubernetes Engine.

This beta is aimed at organizations looking to test a video conferencing tool aligned with the same sovereignty requirements as the rest of their stack, with no heavy install on the end-user side.

Why we're building a new video conferencing tool

When a CIO talks to us about sovereignty today, the conversation always ends up on video conferencing. Databases, storage, orchestration: all of these have found their European alternatives in recent years.

Video conferencing, far less so.

Most of the European organizations we work with still use a tool hosted outside Europe, with the jurisdictional questions that come with it.

Cloud Act, FISA, non-EU data transfers: these are topics CISOs have been documenting for years, without being able to truly resolve them as long as no credible alternative existed for their most everyday use case.  

We started running Openvisio internally on our own infrastructure several months ago.

The experience convinced us that an add-on solution, integrated into the Clever Cloud console, made sense for organizations looking to reduce their exposure to non-European jurisdictions without launching a heavy migration project across workstations.

What Openvisio does

Openvisio covers the expected use cases of a modern video conferencing tool.
Access happens through a browser, with no client to install.

Audio and video flow over WebRTC, an open web standard.
Screen sharing is built in. Automatic transcription is available. Authentication plugs into your organization's directory via SSO or OIDC.

Features available in the beta:

• Large-scale meetings: stabilized architecture for sessions with 100+ participants.
• Multi-stream screen sharing: several participants can share their screen at the same time.
• Secure, non-persistent chat: no server-side retention after the meeting ends.
• Meeting recording: audio, video and screen share capture, stored on Cellar.
• Automatic transcription and summary: text record and synthesis of conversations.
• Access control: robust authentication and fine-grained permissions per room.

Infrastructure operated in Europe, with no non-European dependencies

This is the point that drives most of our incoming requests.

The dominant tools on the market are hosted outside European jurisdiction, which exposes communications to extraterritorial laws (the Cloud Act in the United States, FISA).

Many organizations have chosen to live with this risk for lack of an operational alternative.

Openvisio joins the set of products that Clever Cloud operates in-house to address these concerns: French and European infrastructure, GDPR compliance, no transfer outside the EU by default.

Openvisio joins Docs (document workspace), Grist (structured data) and Clever Kubernetes Engine (orchestration) in a suite designed for organizations operating under sovereignty constraints.

Provisioned as a Clever Cloud add-on

On the deployment side, Openvisio works on the same model as Docs and Grist. You provision it from the Clever Cloud console or via the Clever Tools CLI.

The infrastructure is operated by our teams, with no operational maintenance on your end. Resource consumption stays light: we've sized the add-on so it doesn't introduce unexpected operational costs on your Clever Cloud bill.

The add-on plugs into your organization's existing ecosystem: Cellar for storage, managed databases, IAM, unified monitoring.

User permissions and billing are managed in the same place as your other Clever Cloud products.

A private beta, built together

Openvisio is in private beta.

We're opening a limited number of slots to European organizations that want to test the solution on real-world use cases and share regular qualitative feedback with us.

We're not looking for end customers but for demanding test partners: CIOs, platform teams, CISOs, business decision-makers facing sovereignty requirements.

In return for their commitment, selected organizations get free access during the beta (infrastructure usage may be billed according to the standard Clever Cloud pricing), direct influence on the roadmap, and preferential pricing at general availability.

The goal is straightforward: evolve the product on meaningful use cases before a broader release.

Sensitive internal discussions, executive committees, cross-department meetings, collaboration between European organizations: these are the contexts where we want to stabilize Openvisio before opening up.

Who it's for

Openvisio is built for organizations with a formal or contractual sovereignty requirement on their communications.

This covers companies subject to GDPR compliance on sensitive topics, public sector organizations, and regulated industries (healthcare, finance, energy).

It's also relevant for groups looking to reduce their dependency on a non-European provider without launching a costly change management effort on the user side.

Let's meet at VivaTech (June 17-20, 2026)

We'll be at VivaTech from June 17 to 20, 2026. Florent Perreux and the product team will be running demos throughout the event.

It's also a chance to discuss your use case in person.

If you want to test Openvisio in your organization, apply for the beta through the form below.

We get back to every applying organization to scope the test together before opening access.

For VivaTech 2026, Clever Cloud will present several major evolutions of its offering. On the agenda: a Clever AI enhanced with new capabilities to support the industrialization of artificial intelligence in companies, the opening of the private beta of Openvisio, our video conferencing solution operated on European infrastructure, as well as a new approach to the continuity of critical services with the Final Sovereignty Clause.

These announcements answer a single ambition: enabling organizations to adopt new uses while keeping control over their data, their infrastructure and their strategic tools. Whether it concerns artificial intelligence, collaboration or the resilience of digital services, the stakes of control, continuity and strategic autonomy now hold a central place in the technology choices of companies and public-sector players.

Clever AI becomes a full suite to industrialize AI

When we presented Clever AI at VivaTech 2025, the goal was to address a challenge that is increasingly present in companies: allowing employees to use artificial intelligence in a controlled environment.

At the time, the platform offered a single interface giving access to several language models, with the ability for IT teams to control usage, define which models were accessible to which teams and set up filtering mechanisms suited to their constraints.

One year later, expectations have evolved. Companies are no longer only looking to access models. They want to integrate AI into their processes, their applications and their daily work while keeping visibility over usage, costs and data.

To meet these needs, Clever AI is now built around three complementary components: Clever Assistant, AI Pilot and Clever Inference.

Clever Assistant moves beyond simple chat

Clever Assistant remains the users' gateway to artificial intelligence, but its scope has expanded considerably.

Beyond access to a broad catalog of models, the assistant now integrates meeting recording, real-time transcription, automatic summary generation, voice search, information extraction and document classification. It also becomes possible to create agents able to interact with the company's tools thanks to support for the MCP protocol.

The assistant also connects to calendars, address books and various services across the organization in order to centralize more uses within a single environment.

This evolution answers a simple observation: employees use AI in more and more contexts. The challenge is therefore to provide them with a tool able to support them in these uses while remaining administered by the company.

AI Pilot brings the governance needed to scale

AI adoption often comes with another phenomenon: the proliferation of tools, subscriptions and models used without any global visibility.

AI Pilot was designed to address this issue.

The solution acts as a governance layer that centralizes access to artificial intelligence models through a single entry point. Companies can manage request routing, quotas, filtering rules, the traceability of exchanges, consumption and the costs associated with the various models in use.

The goal is to enable AI adoption at scale while limiting the effects of shadow AI and ensuring better control over usage.

Clever Inference extends control down to the infrastructure

Industrializing AI is not limited to usage. It also involves choosing where and how models are run.

With Clever Inference, Clever Cloud offers an option that lets customers either run on their own infrastructure through Clever Kubernetes Engine, or use an inference offering operated on specialized European infrastructure.

This approach addresses challenges of data localization, cost control and energy sobriety. The remote inference offering relies in particular on the SpiNNaker2 processors from SpiNNcloud and can reduce energy consumption by up to eighteen times compared with some conventional GPU architectures.

With Clever Assistant, AI Pilot and Clever Inference, Clever AI thus evolves from a platform for accessing models into a full suite designed to support the industrialization of artificial intelligence in organizations.

Openvisio: European-operated video conferencing enters private beta

The other novelty presented at VivaTech concerns video conferencing.

With Openvisio, Clever Cloud is opening the private beta of a video conferencing solution operated entirely on European infrastructure and integrated into the Clever Cloud ecosystem.

This initiative was born from an observation regularly raised by CIOs and CISOs. While European alternatives now exist for storage, databases or orchestration, video conferencing remains largely dominated by solutions subject to non-European jurisdictions.

Openvisio aims to provide an operational alternative to these tools while keeping a simple experience for users. Access happens directly from a browser, with no software to install, and with authentication integrated into corporate directories through SSO or OIDC.

The beta already includes the features expected of a modern platform: large-scale meetings, multi-stream screen sharing, secure non-persistent chat, meeting recording, automatic transcription and summary generation.

The solution is built on a partnership with Vopenia, a software vendor specialized in real-time communication.

This private beta is aimed at a limited number of organizations wishing to test the solution in real conditions and actively take part in its evolution. Feedback from IT teams, CISOs and business users will help shape the product before its wider release.

The Final Sovereignty Clause: guaranteeing the continuity of critical services

VivaTech will also be an opportunity to present a more cross-cutting initiative around digital strategic autonomy: the Final Sovereignty Clause.

For several years, sovereignty questions have often been assessed through criteria such as data localization, applicable jurisdiction, the provider's location or its shareholding structure. These elements remain essential, but they primarily describe a situation at a given moment.

One question, however, is rarely addressed: what happens if the conditions that motivated the choice of a provider change over time?

Recent events in the artificial intelligence ecosystem have served as a reminder that the continuity of a service does not depend solely on its technical infrastructure. It also rests on its governance, its legal framework and the ability of users to retain control over their services when the context changes.

It is to address this issue that Clever Cloud is launching the Final Sovereignty Clause.

Integrated into certain contracts covering critical services, this clause provides that, in the event of a development calling into question the initial framework of trust — a change of ownership, an acquisition by a non-European player or a major regulatory shift — a predefined continuity mechanism can be activated.

A trusted European public entity designated in advance could then obtain the rights needed to ensure the operational continuity of the service, either temporarily or as part of a controlled migration to another European environment.

The goal is simple: to go beyond data reversibility and provide guarantees on the effective continuity of the service itself.

Designed to be reusable by other players in the European digital sector, the Final Sovereignty Clause is part of a broader reflection on the resilience of digital infrastructure in the face of economic, regulatory and geopolitical uncertainty.

Meet us at VivaTech 2026

The Clever Cloud teams will be present at VivaTech from June 17 to 20, 2026 to present these new developments and run demonstrations of Clever AI and Openvisio.

You can find us in several areas of the show:

It will be the occasion to talk with our teams, discover the latest evolutions of Clever AI, attend Openvisio demonstrations and discuss your projects around artificial intelligence, cloud and digital strategic autonomy.

Founded in 2010 in Nantes, France, Clever Cloud has established itself as a prominent player in the European cloud computing landscape, specializing in innovative Platform as a Service (PaaS) solutions. Our core mission is to empower developers by providing a reliable, scalable, and secure infrastructure that enables seamless application development, deployment, and management. Clever Cloud is firmly committed to the principles of digital sovereignty, European values while advocating for a resilient and strategically autonomous digital ecosystem. We believe that Europe must prioritize its digital ecosystem to ensure that businesses and public authorities can operate independently without reliance on inadequate non-European solutions. Our expertise, underscored by a workforce composed of over 70% developers and engineers, positions us as a company of experts dedicated to both technical excellence and strong ethical European values.

As an active participant in the European legislative framework, Clever Cloud engages with critical initiatives aimed at enhancing Europe's digital sovereignty. We contribute to the development of key frameworks such as the Digital Markets Act (DMA), the EU Cybersecurity Act and of course the forthcoming EU Cloud and AI Development act among others... Our involvement in organizations like Eurosmart, European Alliance for Industrial Data, Edge & Cloud, France Digitale, the Open Internet Project, and CISPE reflects our commitment to advocating for robust European certification schemes and ensuring that the cloud infrastructure respects and protects user rights. Through partnerships with leading European technology firms while preserving market freedom. In fact, we are building a cohesive digital ecosystem that fosters innovation, real free competition while preserving individual freedoms. Our dedication to creating and contributing to open-source projects further demonstrates our belief in collaboration as a means to strengthen Europe's digital sovereignty.

A Welcome and Pioneering First Step Towards Effective Digital Sovereignty Grounded in European Capabilities

Jean Monnet famously observed that people tend to accept change only when it becomes necessary and recognise necessity only in times of crisis.

On 3 June 2026, the European Commission unveiled the Cloud and AI Development Act (CAIDA), marking an important and timely step towards addressing one of Europe's most pressing strategic challenges: ensuring that the Union can rely on secure, resilient, competitive and genuinely European digital infrastructure.

In the realm of the Tech Sovereignty Package, the proposal forms part of a broader effort to strengthen Europe's technological sovereignty and industrial capacity across cloud, data centres and artificial intelligence. It introduces a common framework built around four EU-harmonised assurance levels for cloud services and seeks to provide a more structured response to the risks arising from excessive dependence on a limited number of non-European providers.

Clever Cloud welcomes this initiative as an important and timely step towards strengthening Europe's digital sovereignty.

For the first time, cloud infrastructure, data governance, platforms, algorithms and artificial intelligence are addressed not merely as technical layers or procurement items, but as strategic assets underpinning Europe's competitiveness, resilience, public services and democratic autonomy. The way Europe designs, procures and governs its digital infrastructure cannot be guided solely by short-term convenience or by the market power of a handful of dominant non-EU providers. It must also reflect the Union's values, strategic interests and long-term capacity to act.

CAIDA sends a strong signal: Europe is not destined to remain a follower or a consumer of technologies designed and governed elsewhere. It has the capacity to become an innovator and a leader again, by designing, building and operating the critical digital infrastructure that will underpin its competitiveness, public services and democratic autonomy.

The proposed assurance-level framework is a particularly important development. By moving away from a binary understanding of "sovereign" versus "non-sovereign" cloud, CAIDA introduces a more mature and operational approach: one based on documented, auditable and verifiable criteria. This is essential. Sovereignty must no longer be something providers can simply claim. It must be demonstrated.

Such a framework can also contribute to restoring the conditions for a more functional cloud market and fairer competition. Digital sovereignty should not be understood as market closure. Rather, it should be understood as the Union's ability to correct structural asymmetries that currently prevent European providers from competing on fair terms with dominant global players benefiting from massive scale effects, entrenched dependencies and quasi-systemic positions in public procurement.

Clever Cloud also welcomes the proposal's objective of allocating 25% of innovative public procurement in cloud and AI to innovative SMEs. This is a strong and welcome signal. Since the "Think Small First" principle introduced in 2008, the Union has repeatedly acknowledged the need to better integrate SMEs into industrial policy and public procurement. CAIDA now offers an opportunity to translate that principle into practice and to lay the foundations for a genuine European Small Business Act for cloud and AI.

However, while CAIDA lays the right foundations, it must now be strengthened throughout the legislative process.

The proposal is entering the ordinary legislative procedure, and its ultimate impact will depend on the amendments adopted by the co-legislators, as well as on subsequent implementing acts, delegated acts, audit methodologies, the interpretation of assurance levels, the mapping with existing certification schemes, and the criteria used to designate third countries as "trusted partners".

Several elements therefore require particular attention.

• First, the treatment of third-country providers must be clarified and tightened. While CAIDA rightly addresses risks associated with foreign-controlled providers, the treatment of US hyperscalers remains a central question. Clever Cloud supports the choice not to adopt a simplistic binary approach to digital sovereignty. However, the conditions under which third-country-controlled providers may access high assurance levels, notably Level 3, must be defined with the highest degree of legal and operational precision.
• On some issues, such as GDPR compliance or the existence of adequacy mechanisms for data transfers under the EU-U.S. Data Privacy Framework, a discussion may be possible. Yet the core sovereignty concerns lie elsewhere: extraterritoriality, potential access by foreign authorities, service interruption or degradation, sanctions, embargoes, technological dependency and effective control. On these matters, trust cannot be presumed. It must be assessed, evidenced, monitored and, where necessary, withdrawn. As a matter of fact, we consider that the proposal primarily targets non european providers especially from China but does not address the issue of US hyperscalers. And this is especially true when it comes to the US Cloud Act or the FISA.
• Second, CAIDA must not become a vehicle for legitimising "sovereign washing". A cloud service should not be considered sovereign merely because data is hosted in Europe or because a contractual European layer is placed on top of a non-European technological stack. Effective digital sovereignty must be assessed through control, jurisdictional exposure, operational autonomy, auditability, reversibility, continuity of service and dependency management.
• Third, the relationship between CAIDA and existing or forthcoming cloud certification schemes, in particular the European Cybersecurity Certification Scheme for Cloud Services (EUCS), should be made explicit. CAIDA should provide for coherent mapping with relevant certification schemes where requirements overlap, while ensuring that cybersecurity certification is not used as a substitute for sovereignty assessment. EUCS and CAIDA should be complementary: certification may support evidence-gathering, but it should not dilute the distinct sovereignty criteria introduced by CAIDA.
• Fourth, the proposal should better recognise the role of trusted European private providers. The EuroCloud Federation, as currently envisaged, appears primarily designed as a public-public cooperation mechanism. Such cooperation is valuable and should be supported. Yet Europe will not achieve effective digital sovereignty through public infrastructure sharing alone. It must also mobilise qualified, auditable and trusted European private providers capable of delivering innovation, operational excellence, resilience and scale.

The debate is therefore no longer only about defining what a sovereign cloud is. The central question is whether Europe is prepared to take the holistic measures required to make sovereignty effective: through public procurement, auditability, open source, data centre capacity, fair competition, SME participation, technological dependencies, capital control, certification frameworks, migration obligations, critical infrastructure governance and a clear European preference.

Through this position paper, Clever Cloud intends to identify the key priorities needed to ensure that CAIDA becomes not merely a regulatory framework, but a real instrument for effective digital sovereignty grounded in European capabilities, fair competition and technological resilience.

The first step has been taken. Europe must now ensure that it delivers.

1. Reserve Union Assurance Level 3 for European-Controlled Providers

Article 18 introduces a mechanism whereby the Commission may, by means of implementing acts, identify third countries whose cloud computing service providers or providers controlled by legal entities established in those countries may be audited against the criteria for Union assurance level 3.

While this mechanism reflects the proposal's risk-based and non-binary approach to digital sovereignty, it also raises an important concern regarding the integrity of the assurance-level framework.

Clever Cloud supports a proportionate and differentiated approach. Not all workloads require the same level of assurance, and for low-risk or less sensitive use cases, it may be appropriate to allow providers controlled from trusted third countries to qualify under strict and clearly defined conditions.

However, Union assurance level 3 should represent a higher threshold of sovereignty assurance. It should be the level at which effective European control becomes a structural requirement, rather than a matter of mitigation, contractual safeguards or political designation.

The difficulty lies in the relationship between Article 18 and Article 45 GDPR. Under Article 18, the existence of an adequacy decision under Article 45 GDPR is one of the conditions that may allow the Commission to identify a third country as sufficiently trusted for the purpose of the CAIDA assurance framework. In the case of the United States, the EU-U.S. Data Privacy Framework may therefore create a legal and political pathway for US providers to be treated as providers from a "trusted" third country.

This raises a fundamental contradiction.

The political purpose of CAIDA is precisely to reduce Europe's exposure to third-country control, extraterritorial legislation and strategic dependency in critical cloud and AI infrastructure. Yet, if Article 18 allows a third country to be recognised as trusted because of a data transfer adequacy framework, providers subject to that country's legal order could still access Union assurance level 3 despite remaining exposed to extraterritorial legislation, including the US CLOUD Act and FISA.

The issue therefore goes well beyond personal data transfers. Adequacy decisions under Article 45 GDPR may address part of the legal framework applicable to international transfers of personal data. They do not, however, fully address the broader sovereignty risks raised by foreign authority access, sanctions exposure, service continuity, technological dependency, operational autonomy, or effective non-European control.

This concern is not theoretical. Recent transatlantic tensions around EU digital regulation, including US criticism of the Digital Services Act and accusations of "extraterritorial censorship" against European actors, illustrate that digital regulation and technology governance are now matters of geopolitical leverage. They also show that allied status does not eliminate the risk of political pressure, legal conflict or extraterritorial assertion in the digital sphere.

In this regard, CAIDA rightly addresses risks linked to providers controlled from jurisdictions where no adequacy decision, reciprocal market access or trusted cooperation framework exists, such as China. However, the current wording remains less robust when applied to US providers. The EU-U.S. Data Privacy Framework may support part of the adequacy assessment for personal data transfers, but it should not be treated as sufficient to resolve the core sovereignty concerns associated with extraterritoriality, effective control and operational autonomy.

For these reasons, Clever Cloud considers that third-country recognition under Article 18 should not provide a pathway to Union assurance level 3. Such recognition may be appropriate for lower or substantial assurance levels, subject to strict safeguards, but level 3 should remain reserved for providers established in the Union and subject to effective European control.

Policy recommendations

Clever Cloud recommends that third-country recognition under Article 18 should only allow access to Union assurance level 2, not level 3.

Union assurance level 3 should be reserved for providers that are:

• established in the Union;
• subject to effective European control;
• not controlled by a third country or by a legal entity established in a third country;
• protected from foreign legal regimes enabling access, disruption, degradation or coercive influence;
• operationally autonomous within the Union;
• able to demonstrate control over critical infrastructure, personnel, support, management planes, cryptographic material and continuity procedures.

This would preserve proportionality while maintaining the integrity of the framework:

• Level 1: baseline assurance, open where relevant requirements are met;
• Level 2: substantial assurance, potentially open to trusted third-country providers under strict cumulative safeguards;
• Level 3: high sovereignty assurance, reserved for European-controlled providers;
• Level 4: highest sovereignty assurance, reserved for the most critical use cases.

The objective is not to exclude third-country providers from the European market, but to ensure that high sovereignty assurance remains meaningful.

2. Ensure Coherent Mapping Between CAIDA Assurance Levels and EUCS Certification

CAIDA introduces a new framework based on four EU-harmonised assurance levels for cloud services. This is a welcome development, as it provides a structured approach to sovereignty-related risks beyond purely technical cybersecurity considerations.

However, the proposal should further clarify how this new framework will interact with existing and forthcoming European certification schemes, in particular the European Cybersecurity Certification Scheme for Cloud Services (EUCS).

At this stage, CAIDA appears to allow the sovereignty framework to rely on existing certification schemes where relevant. This is useful. Yet the reverse relationship is not sufficiently clear.

A cloud service certified under EUCS should be able to reuse relevant cybersecurity evidence to support assessment under CAIDA where requirements genuinely overlap. However, EUCS certification should not automatically grant a CAIDA assurance level.

Cybersecurity certification and sovereignty assessment are complementary, but they are not equivalent.

EUCS primarily addresses cybersecurity criteria. CAIDA addresses broader sovereignty considerations, including control, jurisdictional exposure, access by foreign authorities, continuity of service, reversibility, dependency risks and effective operational autonomy.

Policy recommendations

CAIDA should explicitly provide for a structured and bidirectional mapping mechanism between CAIDA assurance levels and EUCS certification.

This mechanism should:

• identify which EUCS requirements can be reused as evidence for CAIDA Level 1, Level 2, Level 3 or Level 4;
• clarify which CAIDA sovereignty requirements are not covered by EUCS and must be assessed separately;
• allow cloud service providers to reuse audit and certification evidence across frameworks;
• prevent automatic equivalence between cybersecurity certification and sovereignty recognition;
• allow private entities to rely on CAIDA assurance levels as a voluntary reference framework for procurement, vendor assessment and cloud risk management;
• reduce administrative burden while preserving the integrity of the sovereignty framework.

The guiding principle should be clear:

EUCS may support evidence-gathering for CAIDA, but it must not replace the dedicated assessment of sovereignty criteria.

3. Establish a Structured Accreditation and Audit Framework for Annex II and Annex III under the New Legislative Framework

Article 21 provides that auditing organisations shall assess compliance with the criteria set out in Annex II on the basis of audit evidence listed in Annex III. It also empowers the Commission to adopt delegated acts to amend Annex III by laying down the evidence needed to assess the audit criteria under Annex II.

This provision is important, but insufficient.

Annex II and Annex III will define the practical substance of CAIDA. They will determine what sovereignty means in practice, how it is demonstrated, and what evidence providers must submit to auditors.

These annexes should not be treated as static lists. Sovereignty risks evolve quickly. Extraterritorial legislation, foreign authority access mechanisms, management plane architectures, AI infrastructure dependencies, encryption practices, support models, interoperability requirements and portability constraints are not fixed.

If Annex II and Annex III are not maintained through a structured and transparent process, several risks may arise:

• inconsistent interpretation across Member States;
• divergent audit practices;
• forum shopping by providers;
• outdated evidence requirements;
• weak assessment of emerging risks;
• excessive compliance burden for European SMEs;
• reduced credibility of the assurance-level framework.

The audit ecosystem must also be harmonised. Independent third-party audits will only be trusted if the organisations performing them are competent, independent and accredited under a common European approach.

Policy recommendations

Clever Cloud recommends establishing a structured accreditation and audit framework for CAIDA.

First, the Commission should regularly assess the adequacy, relevance and proportionality of Annex II and Annex III, taking into account technological, legal, geopolitical and market developments.

Second, this review should be supported by a public-private expert mechanism, able to provide input on interpretation issues, emerging risks, audit evidence and necessary updates.

Third, audit organisations should be accredited by national accreditation bodies within the meaning of Regulation (EC) No 765/2008, or an equivalent Union accreditation framework. This would align the audit framework with the logic of the New Legislative Framework and help avoid fragmentation.

The national competent authority should remain responsible for the final recognition decision. However, the underlying audit should be performed by accredited organisations with demonstrated technical, legal and organisational competence.

The accreditation scope should cover the ability to assess:

• effective control;
• jurisdictional exposure;
• Extraterritoriality;
• Ultimate voting control is held predominantly by european entities;
• Data localization
• operational autonomy;
• continuity of service;
• dependency risks;
• reversibility;
• interoperability;
• portability;
• audit evidence quality.

The policy objective should be simple:

Annex II and Annex III must be actively maintained, and audits must be performed by accredited bodies under a harmonised European framework.

4. Establish a Public-Private Cloud Assurance Expert Forum to Support the Interpretation and Evolution of CAIDA

CAIDA introduces a complex and innovative assurance-level framework. Its effectiveness will depend on consistent interpretation, regular updates and practical guidance.

However, the proposal currently lacks a dedicated public-private expert mechanism to support the interpretation of assurance levels, Annex II requirements and the practical implementation of the framework.

This is a critical gap.

The framework will need to address evolving and complex questions: extraterritoriality, effective control, operational autonomy, dependency risks, reversibility, interoperability, portability, audit evidence, trusted partner status and emerging technological threats.

These issues cannot be handled only through static legal provisions. They require continuous dialogue between public authorities, national competent authorities, cloud service providers, cybersecurity experts, auditors, SMEs, users, open-source communities and civil society stakeholders.

Comparable mechanisms already exist in other areas of EU digital policy. The NIS Cooperation Group provides a forum for national authorities. Cybersecurity certification frameworks also rely on cooperation and expert input to support maintenance and interpretation.

CAIDA should follow the same logic.

Policy recommendations

Clever Cloud recommends establishing a Public-Private Cloud Assurance Expert Forum under CAIDA.

This forum should not replace the Commission, Member States or national competent authorities. Its role should be to provide structured technical, market and operational input.

It should support the Commission and national competent authorities by:

• facilitating the exchange of information and best practices;
• supporting the interpretation of Union assurance levels;
• contributing to the interpretation of Annex II and Annex III;
• identifying emerging legal, geopolitical, technical and market risks;
• advising on updates to annexes, guidance, technical specifications and implementing acts;
• supporting the development of private-sector guidance under Article 31;
• contributing to interoperability, portability, reversibility and anti-lock-in requirements;
• ensuring that SMEs and European cloud providers can provide practical input.

The forum should include representatives from:

• European cloud service providers;
• SMEs and mid-cap companies;
• public-sector users;
• private-sector users operating in critical sectors;
• auditing organisations;
• cybersecurity experts;
• standardisation bodies;
• open-source communities;
• data protection experts;
• civil society organisations.

The guiding principle should be:

CAIDA should not rely solely on administrative interpretation. It needs a structured public-private expert mechanism to remain practical, innovation-friendly and resilient to emerging sovereignty risks.

5. The EuroCloud Federation: Include Trusted European Private Providers

The EuroCloud Federation, introduced under Article 34, is one of the key levers through which CAIDA seeks to support public-sector cloud cooperation. It is intended to facilitate the sharing of cloud and data centre services between Union entities and public-sector bodies.

The idea of a deeper public-public cooperation mechanism is useful and should be supported.

However, as currently designed, the EuroCloud Federation appears too limited. It does not include trusted European private providers.

Europe will not build effective digital sovereignty through public infrastructure sharing alone. It must also mobilise qualified, auditable and trusted European private providers capable of delivering innovation, operational excellence, resilience and scale.

A federation limited to public actors risks missing a significant part of Europe's existing cloud capacity and innovation ecosystem.

Policy recommendations

Clever Cloud recommends that CAIDA better recognise the role of trusted European private providers in or alongside the EuroCloud Federation.

This does not mean turning the EuroCloud Federation into an unregulated commercial marketplace. Rather, it means creating a structured role for European private providers that meet clear sovereignty, auditability and trust requirements.

This could be achieved through:

• a dedicated trusted European private provider framework;
• integration of recognised European cloud providers into EuroCloud-related catalogues;
• procurement channels linked to the EuroCloud Federation;
• public-private capacity pooling mechanisms;
• priority access for providers recognised under high CAIDA assurance levels;
• mechanisms enabling public-sector bodies to rely on trusted European private partners for deployment, operations, scaling and resilience.

The objective should be to combine public-public cooperation with public-private mobilisation.

The guiding principle should be:

"The EuroCloud Federation should not become a closed public-only mechanism. It should help mobilise the full European cloud ecosystem, including trusted European private providers."

6. Enable Private Entities to Use CAIDA as a Practical Risk Assessment Framework

Article 31 allows private-sector entities operating in sectors of high criticality to carry out impact assessments similar to those required from public-sector bodies.

This is a positive provision. Sovereignty risks do not only affect the public sector. Private companies also process sensitive, critical or strategic data and rely on cloud services for essential operations.

However, Article 31 remains too limited. It should not merely allow private entities to conduct assessments. It should provide them with a practical, harmonised and reusable framework.

Private entities should be able to rely on CAIDA assurance levels for cloud procurement, vendor assessment and risk management. This is especially relevant for companies operating under NIS2, CRA, DORA, GDPR, the Data Act or other sectoral requirements.

For instance, a private company selecting a cloud service for sensitive operational or industrial use cases should be able to use Commission guidance to conduct a sovereignty risk assessment, determine the relevant CAIDA level, and select a service recognised or audited accordingly.

Policy recommendations

Clever Cloud recommends that the Commission issue dedicated guidance for private-sector entities, including SMEs and companies operating in high-criticality sectors, so that all European businesses with legitimate ambitions to process, host or manage critical data can rely on a clear, proportionate and operational framework.

Such guidance should include:

• a methodology for private-sector cloud sovereignty risk assessments;
• practical templates and assessment tools;
• sector-specific examples;
• guidance for SMEs and mid-cap companies;
• mapping between categories of data, business criticality and relevant CAIDA levels;
• suggested mitigation measures;
• guidance on when to use Level 1, 2, 3 or 4;
• guidance on multi-cloud and multi-vendor strategies;
• alignment with NIS2, CRA, DORA, GDPR, the Data Act and sectoral obligations.

Private-sector use of CAIDA should remain voluntary, but the framework should be usable enough to become a trusted market standard.

The guiding principle should be: "Article 31 should become the bridge between CAIDA and the private market".

7. Turn the 25% SME Procurement Objective into a Genuine European Small Business Act for Cloud and AI

Article 33 introduces one of the most promising provisions of CAIDA: Member States shall pursue the objective that at least 25% of their procurement for cloud computing services and AI systems be awarded to innovative SMEs.

Clever Cloud strongly welcomes this provision, which reflects a measure we have been advocating for since 2010.

It is a significant and rather unexpected step towards translating the long-standing "Think Small First" principle into concrete market outcomes.

However, the current wording remains too weak. A non-binding objective, without clear monitoring, reporting, auditing or enforcement mechanisms, risks remaining purely aspirational.

If CAIDA is to become a genuine industrial policy instrument, Article 33 should be strengthened into a real European Small Business Act for cloud and AI.

Public procurement is one of the European Union's most powerful market-shaping instruments. It determines which companies can scale, which technologies become de facto standards, and which value chains Europe controls over the long term.

In strategic digital sectors (cloud, AI, cybersecurity, data infrastructure, critical software and digital public services) procurement choices are not neutral. They shape the structure of the market.

A procurement system that structurally favours large incumbents weakens Europe's innovation capacity. Innovation is often driven by new entrants, SMEs and scale-ups. The broader creative destruction framework, associated with Schumpeter and later developed by economists such as Philippe Aghion, shows that new entrants play a central role in technological disruption, market transformation and productivity growth.

This is particularly important in cloud and AI, where Europe already faces a structural dependency on a small number of non-European hyperscalers.

Policy recommendations

Clever Cloud recommends strengthening Article 33 in three ways.

First, the target should be increased from 25% to 35% for strategic digital and technological procurement.

Second, the target should be made measurable, auditable and reportable. Member States should include in their national strategies clear plans to achieve the target, including measures on lot division, simplified procurement procedures, proportionate eligibility criteria, SME participation in consortia, reduction of administrative burden and prevention of dependency on dominant providers.

The strengthened SME procurement objective should be supported by a more prominent role for the Network of SME Envoys. SME Envoys should help monitor implementation at national level, identify structural barriers to SME participation in cloud and AI procurement, and provide regular input to the Commission on whether Member States are effectively translating the "Think Small First" principle into procurement outcomes. They should also contribute to ex ante evaluations of relevant procurement procedures to ensure that tender design, eligibility criteria, lot structure and administrative requirements are genuinely applicable and accessible to SMEs.

Third, the framework should be extended as a voluntary reference for private-sector procurement, especially in critical sectors where supplier diversity, reversibility and dependency reduction are strategic concerns.

The strengthened objective should explicitly cover:

• cloud computing services, including IaaS, PaaS and SaaS;
• artificial intelligence systems and AI services;
• cybersecurity services and products;
• data infrastructure and data platforms;
• trusted data spaces and health data infrastructure;
• high-performance computing and AI compute resources;
• digital public services;
• critical software and platform technologies.

The Commission should publish an annual scoreboard assessing Member State progress.

The guiding principle should be: "CAIDA should move from an aspirational SME target to a measurable European Small Business Act for cloud and AI."

8. Introduce a Clear European Preference Objective for Strategic Cloud, AI and Digital Procurement

Article 33 is a welcome first step. By setting an objective that at least 25% of Member States' procurement for cloud computing services and AI systems should be awarded to innovative SMEs, CAIDA recognises that public procurement must play a stronger role in shaping Europe's digital and industrial ecosystem.

However, the SME objective should not be the end point. It should be the starting point.

In strategic digital sectors such as cloud, AI, cybersecurity, data infrastructure, digital public services and critical software, procurement choices are not neutral. They determine which providers scale, which technologies become embedded in public administrations, and which value chains Europe controls over the long term.

Today, European public procurement too often reinforces dependency on non-European providers, particularly in cloud and digital infrastructure. This is not primarily the result of a lack of European capabilities. Europe has a strong ecosystem of cloud providers, PaaS specialists, cybersecurity companies, AI and data infrastructure firms, SMEs, scale-ups and mid-sized technology companies. The issue is that procurement frameworks often favour large incumbents, oversized tenders, closed ecosystems and established global providers.

CAIDA should therefore go one step further. In addition to the SME procurement objective, it should introduce a clear European preference objective for strategic cloud, AI and digital procurement.

This should not be understood as a protectionist measure or as a blanket exclusion of non-European suppliers. It should be designed as a transparent, proportionate and rules-based procurement objective, aimed at ensuring that European public demand contributes to the development, scaling and resilience of Europe's own technological ecosystem.

Policy recommendations

Clever Cloud recommends that CAIDA establish a dedicated European technology participation objective for strategic digital procurement.

For cloud, AI, cybersecurity, data infrastructure and critical digital services, Member States should be encouraged to ensure that a significant share of annual procurement value is awarded to European technology providers.

A target range between 40% and 60% would provide a clear political signal while leaving Member States sufficient flexibility to adapt implementation to market availability, sectoral maturity and operational needs.

This objective should apply at aggregate level, not necessarily at the level of each individual tender. It should be monitored annually, reported by Member States and reflected in national strategies under Article 7.

The objective should cover, in particular:

• cloud computing services, including IaaS, PaaS and SaaS;
• artificial intelligence systems and AI services;
• cybersecurity services and products;
• data infrastructure and data platforms;
• trusted data spaces and health data infrastructure;
• high-performance computing and AI compute resources;
• digital public services;
• critical software, middleware and platform technologies.

To ensure legal certainty and avoid purely formal definitions, eligibility as a European technology provider should be based on objective criteria reflecting effective European control and economic substance.

Relevant criteria could include:

• headquarters and effective establishment in the European Union;
• ultimate voting control located within the Union;
• a majority of shareholders established or resident in the Union;
• at least 51% of R&D activities carried out in Europe;
• at least 51% of the workforce located in Europe;
• top management and strategic decision-making anchored in the Union;
• absence of control by a third-country entity;
• absence of exposure to extraterritorial legal obligations incompatible with Union law;
• compliance with the EU digital and cybersecurity acquis.

The purpose of such criteria is not to create a formal label based only on incorporation. It is to ensure that European preference benefits companies that genuinely contribute to Europe's technological base, employment, innovation capacity, legal autonomy and operational resilience.

This approach would complement, rather than replace, the SME objective under Article 33. The two objectives should work together:

• The SME objective ensures that innovative smaller providers can access procurement markets;
• The European preference objective ensures that strategic public demand strengthens European technological capabilities more broadly.

Together, they would help transform public procurement from a passive purchasing function into a strategic instrument for digital sovereignty, fair competition and industrial capacity.

The guiding principle should be clear:

In strategic digital technologies, European public procurement should not systematically build non-European industrial capacity where capable European alternatives exist.

Conclusion

CAIDA is a welcome and pioneering first step. It marks an important milestone in recognising cloud, software and AI infrastructure as strategic assets for Europe's competitiveness, resilience and digital sovereignty.

This first step must now be consolidated. CAIDA should become the key legislative instrument for European digital sovereignty in cloud, software and AI, by making sovereignty operational, measurable and grounded in European capabilities.

Clever Cloud stands ready to contribute to this effort and to make its technical, operational and market expertise available to European institutions, Member States and stakeholders.

The objective is clear: to help build a resilient, sovereign and strategically autonomous European digital ecosystem, capable of supporting innovation, fair competition and long-term technological leadership.

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.

Since its launch, the UP Program has supported tech startups at different stages of maturity, with one simple goal: helping them build, deploy and scale their product on a robust cloud foundation, without turning infrastructure into an operational bottleneck.

Cybersecurity, health, legaltech, agriculture: this fifth selection once again reflects the diversity of the use cases supported by Clever Cloud. It brings together projects operating in demanding environments, where reliability, security, data control and the ability to scale quickly become decisive factors.

UP Program: the startups selected for this fifth edition

Sentibee — Simplifying vulnerability intelligence

Sentibee develops a vulnerability intelligence solution designed to help organisations better prioritise cyber risks.

Its goal is to reduce noise, contextualise alerts and turn complex data into truly actionable insights. The platform combines data collection, AI-powered qualification and human expertise to help teams understand what really matters: exploitability, real-world impact, priority level and the actions to take.

With VulnPilot, Sentibee also enables organisations to build watchlists, monitor critical assets or technologies, and generate prioritised action plans. A pragmatic approach to cybersecurity, designed to make vulnerability intelligence clearer, more useful and more accessible.

Pictaderm — Dermatological expertise in pharmacies

Pictaderm makes it easier to access dermatological advice through partner pharmacies, without an appointment.

The solution allows a patient to visit a pharmacy for a skin condition or a lesion that needs monitoring, and receive the opinion of a medical expert within 48 hours. Pictaderm addresses a concrete challenge: bringing medical expertise closer to the field, in a context where access to dermatology appointments can involve long waiting times.

The platform relies on a network of registered pharmacies and has already supported several tens of thousands of patients. For pharmacists, it provides a tele-expertise tool that helps guide patients more quickly and strengthens their role in the care pathway.

Legaia — An AI legal assistant designed by lawyers

Legaia develops Gaia, an AI legal assistant available directly by email and designed for lawyers.

The promise is simple: enabling law firms to use AI without changing their working habits. No new platform to open, no additional tool to learn: the lawyer simply forwards an email to Gaia and receives an initial analysis, search, draft or translation.

The solution covers several day-to-day use cases: drafting letters, searching case law, numbering and stamping exhibits, retrieving official documents or translating attachments. Legaia also places strong emphasis on security, confidentiality and compliance, which are essential requirements for professionals handling sensitive documents.

Cockpit Agriculture — Managing agricultural performance

Cockpit Agriculture develops an intelligent performance management solution for farmers and their value chains.

The startup is part of an augmented agriculture approach: helping agricultural stakeholders gain greater control, better monitor their activity and make more reliable decisions. In a sector facing strong economic, environmental and operational constraints, the ability to manage performance and make decisions with confidence is a key issue.

With this approach, Cockpit Agriculture addresses a central need: giving farmers and agricultural value chains tools designed to fit the realities of the field.

A batch that reflects the challenges faced by tech startups

The four startups in this new selection operate in very different sectors, but share several common points.

They all develop products where technology is not just a support function, but a central part of the value proposition. They also address use cases where trust is central: cyber vulnerabilities, care pathways, legal documents and agricultural management.

In these contexts, cloud infrastructure must remain reliable, scalable and under control. It must allow teams to iterate quickly, secure data, absorb growth and maintain a high level of availability, without diverting them from their core business.

This is precisely the role of the UP Program: supporting startups at the stage where infrastructure becomes a strategic topic.

The UP Program: a support framework designed for the long term

The UP Program was designed to support startups beyond their first cloud credits.

Selected startups benefit from a set of resources to help them structure their technical trajectory:

— up to €10,000 in cloud credits for the first year;
— onboarding on the Clever Cloud platform;
— training with Clever Cloud engineers;
— monthly coaching;
— access to support;
— workshops and masterclasses for technical teams;
— mentoring for founders and product teams;
— visibility through Clever Cloud media, social networks and events;
— access to financial planning and structuring tools.

The goal is to allow startups to focus on their product, their users and their market, while building on an automated, robust infrastructure capable of scaling with them.

Are you a startup looking to join the UP Program?

The next UP Program selection will take place on 16 September 2026.

Startups wishing to apply can submit their application now and discuss their project, technical needs and growth challenges with the Clever Cloud teams.

Following its first certification Cloud Concepts 101, Advanced Deployments is aimed at developers, technical partners and DevOps teams who want to go further in their use of Clever Cloud: understanding the build / run cycle, configuring their environments, managing persistence, and making deployments more reproducible with Terraform.

With this second certification, Clever Cloud continues its educational path around cloud computing and its platform, with a concrete, progressive and directly applicable approach.

Understanding advanced deployments on Clever Cloud

The Advanced Deployments certification is built around five main modules:

1. Systems integrated into deployments: understand the full deployment cycle, from build to run, including logs, isolation, immutability, scaling, and the differences between build flavour and run flavour.
2. Advanced configuration through environment variables: learn how to interact properly with the platform, contextualise instances, organise environments, and use variables as a central configuration mechanism.
3. Language-specific environment variables: understand how Clever Cloud configures runtimes across ecosystems such as Node.js, PHP, Python, Java or Docker, and how to adjust versions, build behaviour, execution, memory and performance.
4. Storage and persistence management: distinguish between stateless and stateful approaches, choose the right storage add-ons, manage persistence in a distributed environment, and anticipate concurrency, backup and high-availability challenges.
5. Deploying with Terraform: discover Infrastructure as Code in a PaaS context, configure the Clever Cloud provider, describe applications, databases and storage in HCL files, and build reproducible, versionable environments.

A certification designed for real-world environments

In the life of a project, needs evolve quickly. One application becomes several environments. A simple configuration becomes a set of variables to organise. A database, a cache or object storage may become part of the architecture. And when infrastructure needs to be reproduced, audited or shared, Terraform becomes a valuable ally.

Advanced Deployments supports this gradual increase in complexity. It helps users better understand the platform’s mechanisms, diagnose build or runtime errors more quickly, configure environments properly, and manage deployments in a more reliable and reproducible way.

Showcasing your progress

As with Cloud Concepts 101, people who validate the Advanced Deployments certification can showcase this new step in their learning path.

They receive a digital badge, which they can add to their LinkedIn profile to highlight their growing expertise on Clever Cloud and advanced deployments.

Take Advanced Deployments now

The Advanced Deployments certification is now available on the Clever Cloud Academy.

Already validated Cloud Concepts 101? Now is the right time to move to the next level.

Discovering the Clever Cloud certification path for the first time? Start with the basics, then take on this new challenge.

But in production, the topic quickly goes beyond simply deploying containers. A Kubernetes cluster also means managing a control plane, updates, security patches, networking, storage, observability, costs, and coherent integration with the rest of the information system.

The question is no longer only whether you should use Kubernetes, but how to run it without rebuilding an entire operational platform around the cluster.

On Thursday 21 May at 11:30, Clever Cloud is hosting a webinar dedicated to Clever Kubernetes Engine (CKE), our managed Kubernetes service, to discuss these challenges with you.

Kubernetes: a standard, but not just an orchestrator

Kubernetes provides a common foundation for deploying, scaling and operating containerised workloads. It integrates with tools widely adopted by technical teams: kubectl, Helm, Terraform, GitOps…

That is also why many organisations have adopted it. Some solutions are already designed to be installed on Kubernetes. Some vendors distribute their solutions through Helm charts or manifests. Some teams have built their practices, workflows and architectures around this ecosystem.

But standardisation does not remove the operational workload. It shifts it. As soon as a cluster needs to be used in production, other topics appear: control plane availability, updates, monitoring, security, resilience, dependency management and integration with existing services.

This is precisely where architecture choices become important.

CKE: keep Kubernetes, reduce what needs to be operated

With Clever Kubernetes Engine, the goal is to offer another way to run Kubernetes: keep the standards, tools and practices your teams already use, while reducing the amount of infrastructure you need to manage day to day.

CKE lets you create and operate Kubernetes clusters on Clever Cloud infrastructure. The control plane is operated by Clever Cloud, nodes are provisioned on demand, and updates can be applied on request or in the event of a critical vulnerability.

For technical teams, the principle remains the same: you use Kubernetes with your usual tools. You retrieve your kubeconfig, use kubectl, Helm, Terraform or your GitOps workflows, without having to adopt a proprietary tool or completely rethink your practices.

CKE does not force you to change your Kubernetes tools. It mainly reduces what you need to manage around the cluster.

PaaS and Kubernetes: two complementary approaches

At Clever Cloud, PaaS remains at the heart of our approach. For a large number of applications, it enables fast deployment, reduces infrastructure workload and helps teams focus on code. But not all use cases are the same.

Some teams already use Kubernetes. Some architectures require more control over orchestration. In these cases, Kubernetes is not just a technical choice: it is already the team’s working framework.

CKE complements Clever Cloud’s PaaS to address these needs, without opposing the two models. The point is to use the right tool in the right place: PaaS when it helps teams move faster, Kubernetes when it naturally fits the architecture and the team’s practices.

A webinar to see how it works in practice

On Thursday 21 May at 11:30, Florent Perreux, CSO at Clever Cloud, and Gilles Biannic, SRE Engineer at Clever Cloud, will show you how CKE integrates into existing architectures and what it changes in the day-to-day operation of a Kubernetes cluster.

The goal: understand how to use Kubernetes with your usual tools, while reducing the operational workload around the cluster.

On the agenda

During this 30-minute webinar, we will cover:

• why Kubernetes remains demanding to operate in production;
• when Kubernetes makes sense as a complement to a PaaS;
• what CKE handles: control plane, updates, critical patches, platform integration;
• how to keep your usual tools: kubectl, Helm, Terraform, GitOps;
• a demo: creating a cluster, retrieving the kubeconfig, deploying an application and exposing a service;
• concrete use cases: migration from an existing cluster, PaaS complement, reduced operational workload;
• a Q&A session to ask your questions live.

Why attend?

This webinar is for teams already using Kubernetes, operating clusters in self-managed environments or with a hyperscaler, or looking for a European alternative to clusters operated by hyperscalers or self-managed setups.

You will be able to:

• understand what really creates complexity around Kubernetes;
• identify whether CKE fits your context: hyperscaler, self-managed, PaaS or hybrid architecture;
• see how to use Kubernetes without changing your tools or workflows;
• discover how CKE integrates with the Clever Cloud ecosystem;
• ask your questions directly to our teams.

CKE is currently available in public beta. During this period, you will also be able to talk to our teams to learn more about access conditions and available discount vouchers.

Register now

The webinar will take place on Thursday 21 May 2026 at 11:30, online on Livestorm.

You already use Kubernetes, operate your own clusters, or are looking for an integrated alternative to reduce your operational workload? Join us on 21 May.