Faced with the Clever Cloud CLI, an assistant with no context does what it can: it guesses. It invents an option that doesn't exist, mixes the syntax of an old version with today's, or falls back on manual git push commands. It often works in the end, after a few round trips.

Clever Tools now ships a skill: a small package of knowledge your assistant loads when it needs it, which teaches it the CLI from the source rather than by approximation. In this post, we install it, then watch it work on a real deployment: a todo application backed by Materia KV.

What is a skill?

A skill is a folder containing a SKILL.md file. That file starts with a name and a description, followed by instructions in Markdown, and can come with reference files. The format is open – it's the Agent Skills specification – and it's supported by Claude Code, Cursor, Codex, Copilot and others.

The idea is frugal. At startup, the assistant reads only the name and description of each installed skill. It loads the full content only when the task calls for it: you talk about deploying to Clever Cloud, it opens the clever-tools skill. The rest of the time, it costs nothing in your context.

Ours lives in the Clever Tools repository, next to the CLI's code. It contains a cheat sheet of the essential commands (deployment, logs, environment variables, domains, add-ons, scaling, SSH) and a complete reference of every command, option, runtime, add-on and zone. Since it evolves in the same repository as the CLI, it follows its releases.

Installation

You need Node.js for npx, and Clever Tools installed and logged in to your account (clever login). Then, a single command:

npx skills add CleverCloud/clever-tools

skills is the installer of the Agent Skills ecosystem. It clones the repository, finds the clever-tools skill, then asks you two questions:

• which assistants to install it for: Claude Code, Cursor, Codex…
• where to install it: in the current project only, or globally for all your projects.

If you deploy to Clever Cloud from several projects, the global install is the most convenient. If you want the whole team to benefit, install it in the project and commit it with the rest.

Two commands will come in handy afterwards: npx skills list to see what's installed, and npx skills update to get the latest version of the skill when the CLI evolves.

You may come across npx add-skill in older documentation: it's the former name of the same tool, which now prints a warning and redirects to npx skills add.

A real session

To see what it looks like, I asked Claude Code, with the skill installed, for something simple: "make a small todo application that uses Materia KV as if it were a Redis, and deploy it to Clever Cloud".

Materia KV is our serverless key-value database, built on FoundationDB and replicated across three datacenters in Paris. It speaks the Redis protocol: any Redis client works, with no specific SDK.

What follows are the commands the assistant actually ran, with their output.

The application and its database

After writing a small Node.js application (an HTTP server, an HTML page, the official redis client), the assistant created the application and the add-on:

$ clever create --type node todo-kv --region par
✓ Application todo-kv successfully created!

$ clever addon create kv todo-kv-store --plan base --region par --link todo-kv
Add-on created and linked to application todo-kv successfully!
/!\ The Materia KV provider is in beta testing phase

--link does the wiring: on creation, the add-on is linked to the application, and its environment variables are injected into it. The assistant checked they were there:

$ clever env
KV_HOST=…
KV_PORT=…
KV_TOKEN=…
REDIS_HOST=…
REDIS_PORT=…
REDIS_PASSWORD=…
REDIS_URL=…
…

That's what the REDIS_* aliases are for: an application expecting a Redis finds what it's looking for without changing a line of configuration.

An interesting detail slipped in here. Before writing the code, the assistant read the Materia KV documentation, in Markdown, and found the list of supported commands there. Materia KV doesn't support Redis lists (LPUSH, LRANGE) yet. So instead of a list, the todos are stored in a hash, with a counter for the IDs:

const id = await kv.incr('todos:next-id');
await kv.hSet('todos', String(id), JSON.stringify({ id, title, done: false }));

Deployment

$ clever deploy
   ✓ Code pushed to Clever Cloud (0.6s)
   ✓ Deployment started
Starting with Node.js v24.21.0
Installing dependencies…
todo-kv listening on 8080
Response from GET / is 200 (within expected range 200...500)
Successfully deployed in 0 minutes and 7 seconds

✓ Access your application: https://app-….cleverapps.io/

clever deploy pushes the code and follows the deployment to the end, logs included. For the assistant, that's valuable: it sees the result in the same command, without having to look for it elsewhere.

Checking, from the application down to the database

The assistant then tested the live API: creating three todos, marking one as done, reading the list. Then it checked directly in Materia KV with clever kv, which sends a raw command to the database without installing redis-cli.

First hiccup: clever kv didn't appear in the help. The command is an experimental feature that has to be enabled first. The assistant listed the features with clever features, found the right one, and enabled it:

$ clever features enable kv
Experimental feature 'kv' enabled

$ clever kv todo-kv-store PING
PONG

$ clever kv todo-kv-store HGETALL todos
[
  '1', '{"id":1,"title":"Écrire le billet sur le skill","done":false}',
  '2', '{"id":2,"title":"Tester npx skills add","done":true}',
  '3', '{"id":3,"title":"Ouvrir une PR sur le SKILL.md","done":false}'
]

Reading the logs

Last step, asking what's going on in the application:

$ clever logs --app todo-kv --since 15m --until 1m
…
todo-kv listening on 8080
Successfully deployed in 0 minutes and 7 seconds
KV error SocketClosedUnexpectedlyError: Socket closed unexpectedly

One error, three minutes after the last request. The assistant read it, assumed an idle connection closed on the server side, and checked: the redis client reconnects on its own, and a new write through the API went through fine. Nothing to fix, but it needed to be observed rather than assumed.

Along the way, a useful option: --until bounds the log read. Without it, clever logs --since 15m keeps following the stream forever, which suits a human in front of a terminal much better than an assistant waiting for the command to finish. The assistant learned this the hard way with clever accesslogs, which followed the stream without ever returning, and which it ended up interrupting.

Takeaways

The whole session took about a dozen commands. Most of them did what the assistant expected the first time, and that's what the skill brings: the right command, with the right options, without fumbling.

What also makes it work is the short loop between a command and its result. Run, read the output, correct: clever deploy showing the build logs, clever env showing what was injected, clever kv showing what's actually in the database. The assistant never works blind.

The session also showed the skill's current limits, and that's a good thing: it didn't mention that clever kv needs clever features enable kv, nor how --until behaves. Those are two lines to add to SKILL.md, and exactly the kind of feedback we're after.

Skill or MCP server?

The skill isn't the only way in for an assistant. Clever Cloud also offers an MCP server, which gives the assistant direct access to the API without going through the CLI, through three tools: search to discover operations, execute to call them, doc to read the documentation. And the whole documentation is readable in Markdown, with an llms.txt index that lets an assistant find the right page without crawling the site.

The three complement each other. The skill is the simplest starting point: one install command, and your assistant speaks Clever Tools fluently. The MCP server is for when you want to go beyond what the CLI exposes. The Markdown documentation, as we saw with Materia KV, helps in every case. All of this is described on the Drive Clever Cloud from an AI agent page of our documentation.

In short

npx skills add CleverCloud/clever-tools

One command, two questions, and your assistant knows how to deploy to Clever Cloud, manage your add-ons and environment variables and read your logs, with the CLI as it is today.

The skill is open source and lives in the Clever Tools repository. It improves like the rest of the code: if your assistant stumbles on a command, open an issue or a PR on SKILL.md. And to tell us what works, what doesn't and what's missing, the discussion is open on our GitHub community.

Four startups, four products and very different use cases: telemedicine, AI agents, interactive learning and hotel performance management. Yet behind that diversity lies the same challenge: turning a technology product into a service that people genuinely use.

Once the first users arrive, it is no longer enough for a product simply to work. It needs to be deployed, operated and secured reliably, while being able to support new use cases without its cloud infrastructure becoming a barrier to growth.

This is precisely the stage at which the UP Programme supports selected startups.

The four startups joining the sixth UP Programme cohort

Kernel: simplifying access to online care pathways

Kernel is a telemedicine platform providing access to personalised online care pathways, particularly for dermatology and hair loss.

The process starts with a structured medical questionnaire. A doctor registered with the French Ordre des médecins then reviews the case, establishes a diagnosis and, where necessary, issues an appropriate prescription. The treatment can then be prepared by an authorised pharmacy and delivered to the patient.

Kernel also provides a follow-up area that allows patients to stay in contact with their doctor. In a context where the data involved is particularly sensitive, the platform states that medical data is encrypted and hosted in France on HDS-certified servers.

With Kernel, technology supports an end-to-end care pathway, from the initial consultation through to patient follow-up.

Nijal AI: deploying AI agents without giving up autonomy

Nijal AI develops artificial intelligence agents for businesses, institutions and local authorities.

Its approach is built around three principles: providing solutions that are ready to deploy, allowing them to run either in the cloud or on-premises, and avoiding technological dependencies that can become difficult to control.

Nijal AI also places a strong emphasis on transferring skills to the teams using its solutions. The objective is not simply to design an AI agent, but to enable organisations to integrate it into their processes, maintain it themselves and retain control over how it evolves.

This approach reflects an increasingly practical challenge in AI: moving beyond experimentation towards services that can genuinely be operated, maintained and integrated into an organisation’s information systems.

Qiplim: turning content into interactive learning experiences

Qiplim develops a platform combining interactive live sessions with artificial intelligence.

From a document, presentation, web page or video, the platform can generate interactive activities that can then be used during a live session. Participants join via a QR code without having to create an account.

Qiplim is also developing an AI Studio designed to extend the experience beyond the live session, allowing participants to interact with the source material made available to them and transform it into different learning formats.

Data sovereignty is an integral part of its positioning: Qiplim processes its data in France on Clever Cloud, while the artificial intelligence models it uses are served from within the European Union by Mistral AI.

The platform already reports more than 210 beta testers and positions itself as a sovereign alternative to tools such as Kahoot and NotebookLM.

Arkan: from developing AI solutions to building its own products

Arkan supports businesses in designing, developing and deploying solutions based on artificial intelligence.

Alongside bespoke AI projects for companies across different sectors, Arkan is also developing its own products.

Among them, its Hotel Performance Platform centralises data from the tools already used by hospitality businesses, including property management systems (PMS), channel managers and extranets. This data is brought together in a dashboard designed to make it easier to monitor metrics such as occupancy, average room rate, RevPAR and booking trends. An AI assistant also allows users to query the data using natural language.

The platform is already used by two hotel groups representing thirteen properties.

At the same time, Arkan is developing Covera, a solution designed to automate the verification of suppliers’ insurance certificates using artificial intelligence.

Combining bespoke AI development with the development and operation of its own products also illustrates the scaling challenges technology companies can face as they grow.

When a product meets its users, infrastructure becomes part of the product

Kernel, Nijal AI, Qiplim and Arkan address very different needs and are not necessarily at the same stage of development. Their journeys nevertheless illustrate different aspects of the same transition: turning technology into a service that people genuinely use.

As a product finds its users, new constraints emerge. Applications need to remain available, deployments need to be reproducible, data needs to be protected, resources need to scale with usage and teams need to be able to keep shipping quickly.

Infrastructure gradually stops being just a technical concern in the background. It directly contributes to a company’s ability to develop and grow its product.

The challenge is not to spend ever more time operating that infrastructure, but precisely to ensure that it can support growth without distracting teams from their core business.

The UP Programme: turning cloud infrastructure into a growth enabler

This is the stage that Clever Cloud’s UP Programme is designed to support.

Launched in 2024, the programme was created to support technology startups beyond simply providing cloud credits. Its purpose is to give them access to the technical, human and financial resources they need to build their products on cloud infrastructure that can evolve with them.

Selected startups can benefit from:

• up to €10,000 in cloud credits during their first year;
• onboarding onto the Clever Cloud platform and training with our engineers;
• monthly coaching;
• access to Clever Cloud support;
• workshops and masterclasses for technical teams;
• mentoring for founders and their teams;
• visibility through Clever Cloud media, social channels and events;
• tools and resources to support the structuring of their business.

The objective remains the same: enabling teams to focus their energy on their product, users and market rather than on the day-to-day operation of their infrastructure.

Kernel, Nijal AI, Qiplim and Arkan are therefore joining a programme designed to support this pivotal stage: when usage grows, technical requirements evolve and infrastructure needs to keep pace with the product over the long term.

Want to join the next UP Programme cohort?

The next UP Programme selection will take place on 7 January 2027.

Are you building a technology startup and looking for cloud infrastructure that can scale with your product, while benefiting from regular support from Clever Cloud teams?

Discover the UP Programme and apply to join the next cohort.

The episode, titled “We no longer pay developers to write code”, is available on the Underscore_ YouTube channel.

From AI experimentation to industrialization

About 18 months ago, Quentin started seriously experimenting with AI agents for software development. Initially skeptical, he gradually found that they could deliver certain developments faster, sometimes with a better implementation than the one he would have written himself.

But one of the main lessons from Clever Cloud’s experience is precisely that simply giving developers access to an AI tool is not enough. Adoption required changing practices, supporting teams, and even giving up on the idea of imposing a single tool: in a market evolving extremely quickly, developers experiment with different solutions and share what they learn.

When AI also transforms software quality

The focus then shifts from simply generating code to everything required to verify, test, and secure it. Unit and integration tests, distributed systems simulation, automated security audits: AI makes it possible to apply much more systematically practices that already existed but whose time cost sometimes limited their use.

At Clever Cloud, every commit in GitLab can be sent through simulation to look for failures, generate a report, and open an issue when a problem is detected. The question is therefore no longer simply, “How much code can AI produce?” but rather, “What organization and engineering pipeline do we need to build to use this capability in production?”

That is precisely what separates one-off experimentation from industrialization.

Rust, legacy, and new software development practices

The episode also explores Rust’s role in this transformation. Quentin explains why the language’s constraints and the precise feedback provided by its compiler create a particularly effective feedback loop with AI agents.

This approach is now part of a much broader project at Clever Cloud: reducing and ultimately eliminating the legacy accumulated since the company was founded more than 15 years ago, progressively rewriting components while preserving architectural decisions and strengthening their validation.

At the time of recording, Quentin still described eliminating legacy as a work in progress. Since then, this Rust rewrite is now nearly complete.

For a tech company of more than 100 people operating critical infrastructure, this goes far beyond a POC: it means fundamentally changing how software is designed, built, tested, and maintained.

What role is left for developers and CIOs?

This transformation ultimately raises a broader question: what happens to the developer’s role when producing code becomes significantly cheaper?

Quentin argues that value is shifting towards specifications, architecture, testing, and the environment in which software is produced. As a developer himself, he explains that it took him several months to come to terms with this shift.

For CIOs, this experience therefore raises the question of how to integrate AI without simply adding another tool to the stack, by rethinking the processes required to capture its benefits without sacrificing quality or security. This is precisely where Quentin believes companies focusing solely on code generation risk missing a large part of the potential gains.

Ultimately, this may be the main takeaway: the most structural gains emerge when AI leads us to fundamentally rethink how software is designed, built, and evolved. For European companies, the challenge is therefore no longer simply to adopt these tools, but to turn them into a genuine industrial capability.

To watch the full conversation between Quentin Adam, Micode, and Matthieu Lambda:

The story is that of a French company engaged in a commercial dispute with a local competitor, abroad. The authorities of the country decide to launch an audit and the company, anxious to be beyond reproach, agrees to hand over financial data as well as information on its manufacturing processes.

The result: the company is hit with a surcharge all the same, then loses the majority of its customers to the competitor that had reported it. In the meantime, it has handed over valuable economic information which, for its part, can never be taken back.

This case led me to consider a dimension of compliance that we do not discuss enough for my liking. We generally regard it as a way of reducing risk, protecting the company and establishing trust.

But what happens when the tools of compliance (the audit, the inspection, the certification) stop being safeguards and become weapons of economic warfare?

Behind the procedure, the balance of power

An audit appears neutral to us because its vocabulary is. We speak of frameworks, of evidence, of non-conformities, of corrective actions. Everything seems to belong to an objective method whose conclusion would follow naturally from the facts observed.

Yet a control procedure never takes place outside the political and economic context in which it was decided.

The DGSI says so bluntly: these audits, "generally requested by government authorities as part of regulatory procedures, may also result from requests by competing companies".

What I take from this: the official procedure can be diverted in order to capture know-how, to slow a rival down, or to force it to expose itself.

Since it is the authority that audits, and that determines the information it wishes to obtain, the power sits on the other side and the balance of forces is uneven.

The two other examples reported by the DGSI illustrate precisely this risk: an audit tied to an export licence drags the timescales out to the point of leaving a factory facing a supply shortage, and in the other case, a compliance inspection results in modification requirements heavy enough to destabilise the company concerned.

The information that an audit makes it possible to obtain is considerable: the complete supply chain, the detail of industrial processes, the identity of those who hold the know-how, the architecture of a system, sometimes access to source code.

In this way, delaying a licence, suspending a delivery, drawing on the processes, taking the market, imposing costly modifications all become a reality within the economic and industrial balance of power.

In each of these situations, the company's cooperation is not enough to protect it. This obviously does not mean that every audit should be refused, or every certification suspected of being a hostile manoeuvre. It simply means that a technical tool can also carry a political function, and that it would be unwise to forget it.

The concrete cases

Without dwelling on the well-known examples of Alstom or BNP Paribas, concerning foreign interference that goes even further than simple audit procedures, there are a good number of concrete cases worth knowing.

The Micron affair, in China, is probably the clearest example of this shift.

In March 2023, the Cyberspace Administration of China opened a cybersecurity review into the products of the American memory manufacturer. Two months later, it announced that these products presented serious problems liable to threaten the supply chain of the country's critical infrastructure. The operators concerned were therefore ordered to stop buying them.

The regulator did not publish technical details precise enough to allow any assessment of the nature of the vulnerabilities found.

The decision also came amid strong tensions surrounding semiconductors, at a time when the United States had already tightened its restrictions on the export of advanced technologies to China.

It is hardly surprising, then, that it was widely interpreted as a retaliatory measure, even though the reason officially given remains that of cybersecurity. Here, a genuine security concern serves a broader economic strategy: the decision put at stake half of Micron's Chinese market, or around 12.5% of its worldwide revenue.

China had already raised concerns in 2015, when it sought to impose highly intrusive control rules on service providers in the banking sector, rules that amounted to leaving all know-how at the point of entry. The initiative was suspended that same year following significant diplomatic pressure.

A quick detour to our British neighbours brings us to the case of Huawei.

From 2010, the Chinese company submitted to British scrutiny for close to a decade. GCHQ (Government Communications Headquarters) and then the NCSC (National Cyber Security Center) examined the company's equipment, its source code and its engineering practices. In July 2020, the British services were not convinced and, under American pressure, Huawei was removed from the British 5G network.

The tools France has built

France is not defenceless, it holds several defensive regulatory instruments:

The blocking statute of 1968, for a long time almost never applied, was reformed in 2022 (decree no. 2022-207). It prohibits the disclosure to a foreign authority of sensitive information of an economic, commercial, industrial, financial or technical nature that touches on the essential interests of France. Since April 2022, a single point of contact, the SISSE (the strategic information and economic security service, attached to the DGE), issues an opinion within one month setting out what may or may not be disclosed (sources: economie.gouv.fr, DGE, DGSI).

To this judicial shield an infrastructure shield has been added. The cloud at the centre policy, set out by circular in 2021 and updated in 2023, requires public administrations to host their digital projects on the state's internal clouds or on qualified commercial offerings.

For data of particular sensitivity, the offering chosen must hold the SecNumCloud qualification, or an equivalent European qualification, and must be immune to any unauthorised access by the public authorities of third states.

This qualification goes beyond technical measures, covering the legal control of the company, its personnel, the location of its activities and the legislation to which the service may be subject.

SecNumCloud constitutes, in this sense, a defensive instrument. It allows the state to define the conditions under which certain sensitive data may be entrusted to a provider, rather than accepting that the market or foreign powers alone determine the level of risk we ought to tolerate.

France then argued for the introduction of comparable criteria into the European cloud services certification scheme, EUCS, particularly at its highest level. These sovereignty criteria have never commanded consensus among member states. The scheme has been pending ever since.

Several member states and organisations representing European and foreign industrial interests opposed these criteria, which they considered protectionist and alien to a certification that was supposed to remain purely technical. Conversely, several European companies called for them to be retained, precisely because they held that the security of a cloud could not be separated from the law to which it is exposed.

The United States, for its part, does not hesitate: its FedRAMP programme has for years made access to the federal market for cloud services conditional on a certification that it controls.

This debate says a great deal about our collective difficulty. At the very moment when we were seeking to define the conditions of trust applicable to our own market, we hesitated to accept that a certification might also express a sovereignty choice. To return to the image of the weapon, we began by blunting it ourselves. The reality is that we have not managed to equip ourselves with the safeguards needed in the face of the compliance instruments of non-European countries.

Their function is defensive, they are ramparts. Unlike the FCPA and OFAC, which are instruments of projection: they go and find the foreign company on its own ground.

From compliance endured to reciprocity

Two thousand four hundred years ago, Thucydides staged the Melian dialogue. Athens wants to subjugate the small island of Melos, which appeals to law and justice. The Athenians' reply has remained famous: "the strong do what they can and the weak suffer what they must".

The idea is not to devalue the usefulness of compliance and of law, nor to call open markets into question. It is to recall that being in order does not guarantee being protected. Law does not defend itself: it only truly protects where a public authority is prepared to enforce it.

For as long as the asymmetry in means of pressure exists, the most aggressive actor will keep its advantage. If access to a foreign market entails handing over source code or opening up one's factories, we must be able to demand comparable guarantees.

It is time to add a principle that the European Union and its member states have recently begun to establish, but still hesitate to assume fully: reciprocity in their regulatory framework, faced with the offensive legal instruments of third countries.

— Darya KHENDRIK, Compliance Manager at Clever Cloud, IMS lead (Integrated Management System) and DPO

Sources

• DGSI, Foreign audits as vectors of destabilisation and interference for French strategic entities
• Cyberspace Administration of China, Micron decision of 21 May 2023
• USITO, suspension of the Chinese banking "secure and controllable" guidelines
• NCSC, summary of analysis of the US May 2020 sanctions concerning Huawei
• NCSC, advice on high-risk vendors
• ANSSI, SecNumCloud framework of requirements v3.2
• ITI, position of 11 April 2024 on removing the sovereignty criteria from the EUCS
• FedRAMP, conditions of access for cloud services to the federal market
• EUR-Lex, International Procurement Instrument, Regulation 2022/1031
• EUR-Lex, Foreign Subsidies Regulation 2022/2560
• EUR-Lex, Anti-Coercion Instrument, Regulation 2023/2675

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.