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

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

UP Program: the startups selected for this fifth edition

Sentibee — Simplifying vulnerability intelligence

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

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

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

Pictaderm — Dermatological expertise in pharmacies

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

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

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

Legaia — An AI legal assistant designed by lawyers

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

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

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

Cockpit Agriculture — Managing agricultural performance

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

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

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

A batch that reflects the challenges faced by tech startups

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

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

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

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

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

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

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

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

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

Are you a startup looking to join the UP Program?

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

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

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

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

Understanding advanced deployments on Clever Cloud

The Advanced Deployments certification is built around five main modules:

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

A certification designed for real-world environments

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

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

Showcasing your progress

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

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

Take Advanced Deployments now

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

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

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

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

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

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

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

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

Why these vulnerabilities called for a fast response

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

Dirty Frag rests on two Linux kernel flaws.

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

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

What we verified

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

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

Our customers' applications were redeployed shortly after.

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

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

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

Our operational response

Rolling out immediate measures

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

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

Redeploying the affected workloads

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

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

Improving the process along the way

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

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

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

What this changes for Clever Cloud customers

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

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

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

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

What we take away

This sequence confirms three principles.

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

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

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

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

Q&A

What is a local kernel vulnerability?

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

Why do these flaws concern cloud platforms?

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

Are Dirty Frag and Copy Fail the same vulnerability?

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

What action is required from Clever Cloud customers?

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

How Kubernetes Works: a Declarative Orchestrator

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

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

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

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

Architecture in Brief: Control Plane, Nodes, Pods

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

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

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

Why K8S Became the Orchestration Standard

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

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

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

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

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

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

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

Kubernetes delivers real value in several contexts:

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

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

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

The Limits of the Standard: Operational Debt

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

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

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

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

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

In Summary

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

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

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

FAQ

Are K8S and Kubernetes the same thing?

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

What is the difference between Docker and Kubernetes?

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

Is Kubernetes free?

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

Do you always need Kubernetes for production deployments?

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

What is the difference between K3S and K8S?

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

How do I get started with Kubernetes?

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

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

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

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

Kubernetes: a standard, but not just an orchestrator

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

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

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

This is precisely where architecture choices become important.

CKE: keep Kubernetes, reduce what needs to be operated

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

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

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

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

PaaS and Kubernetes: two complementary approaches

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

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

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

A webinar to see how it works in practice

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

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

On the agenda

During this 30-minute webinar, we will cover:

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

Why attend?

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

You will be able to:

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

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

Register now

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

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

A concrete response to sovereignty challenges and a new benchmark for European cloud

In a context of increasing reliance on non-European technologies, this decision highlights the ability of these three players to deliver concrete, competitive solutions aligned with European values.

Through this selection, the Commission demonstrates that technological performance can be combined with strategic control. It also confirms a multi-vendor approach, aimed at strengthening resilience and avoiding dependency on a single provider.

A European consortium serving the EU’s strategic autonomy

The selected consortium brings together leading and complementary European players, meeting the highest standards in terms of sovereignty, security and performance.

OVHcloud provides, through its OPCP platform, a standardized, scalable and operational cloud solution designed to deliver massive compute resources and enable rapid large-scale deployment via OPCP Core.

Clever Cloud contributes an advanced orchestration layer — including PaaS, containerization and managed services — enabling the management, automation and unification of complex environments. This approach supports hybrid architectures combining public cloud, private cloud and dedicated infrastructures with a high level of flexibility.

DEEP contributes both its hosting capabilities and its expertise in cloud, cybersecurity and artificial intelligence.

A strong signal for Europe’s digital future

This framework raises the bar for sovereignty requirements, encourages the adoption of European standards, and paves the way for more balanced competition in cloud and AI.

It also reflects strict alignment with the European Commission’s Cloud Sovereignty Framework, which sets high standards in terms of strategic and legal control, security and European compliance, dependency transparency, technological openness and environmental performance.

Octave Klaba, CEO of OVHcloud, said:“We are very pleased with the trust placed by the European Commission in our consortium. This project proves that strong alternatives exist in Europe, capable of meeting the highest standards. It also shows that when European players join forces, they make a difference.”

Quentin Adam, CEO of Clever Cloud, added:“We are very proud to have been selected. This is the result of significant collective work carried out with OVHcloud and DEEP. We have built a robust response capable of meeting the requirements of European institutions. What is interesting here is that technological sovereignty is no longer just a concept: it takes shape through infrastructures, platforms and players capable of operating together in production. It also proves that European players can cooperate effectively and strengthen the entire ecosystem.”

Sébastien Genesca, Managing Director of DEEP by POST Group, concluded:“We thank the European Commission for the trust placed in our consortium. Together with OVHcloud and Clever Cloud, we have carried out demanding and exciting work with a shared objective: to build a sovereign cloud offering by combining the best of our technological expertise, while sharing common European values.”

About OVHcloud

OVHcloud is a global player and the leading European cloud provider, operating more than 500,000 servers across 46 data centers on 4 continents, serving 1.6 million customers in over 140 countries. A pioneer of trusted and sustainable cloud with a competitive performance-to-price ratio, the Group has relied for over 20 years on an integrated model that ensures full control over its value chain — from server design to data center construction and operation, including the orchestration of its fiber optic network. This unique approach enables OVHcloud to independently cover all customer use cases, while promoting a responsible model with efficient resource usage and one of the lowest carbon footprints in the industry. Today, OVHcloud delivers next-generation solutions combining performance, price predictability, and full data sovereignty to support customers’ growth with complete freedom.

About DEEP by POST Luxembourg Group

DEEP by POST Luxembourg Group is an entity of POST Telecom S.A., a subsidiary of POST Luxembourg, bringing together all the Group’s telecom and ICT expertise to support the digital transformation of businesses and organizations. With more than 750 employees, DEEP is a leading partner for professional digital services in Luxembourg, the Greater Region, and internationally.

DEEP offers a comprehensive portfolio of services and solutions across seven technological domains, with Cloud, Cybersecurity, and Artificial Intelligence playing a key role. As both a Luxembourg-based player and a provider of critical services for the national economy, DEEP delivers solutions designed and operated by its own teams.

DEEP relies on some of the most advanced and resilient telecom and data center infrastructures in the country, recognized among the most robust in Europe. The convergence of telecom and ICT expertise enables DEEP to cover the entire value chain, from connectivity needs to data valorization.

More information: www.deep.eu – www.postgroup.lu

About Clever Cloud

Clever Cloud was founded in 2010 in Nantes, France, and specializes in cloud hosting and automation. Its platform enables applications to be deployed in just a few clicks, on public cloud environments as well as on customer infrastructures, without having to manage scaling or maintenance. At the same time, it ensures a high level of security and data control, in line with sovereignty requirements. Its customers include Airbus, Great Place to Work, MAIF, Docaposte, Fairphone, Solocal, and Limagrain.

This is precisely the role of observability. It is also why Elasticsearch has gradually established itself as an analytical foundation for logs, metrics, and traces.

In this article, we will look at how Elasticsearch fits into an observability approach beyond simple logging, and how it enables technical signals to be correlated in order to better understand application behaviour.

What is observability, and why Elasticsearch is involved

Observability refers to the ability to understand the internal state of a system based on its external signals. Unlike traditional monitoring, it is not limited to predefined metrics or fixed thresholds.

Observability relies on collecting rich, contextual data, analysing it across multiple dimensions, and exploring situations that were not anticipated in advance. In this context, Elasticsearch plays a key role. Its indexing and search engine can analyse large volumes of heterogeneous data, structured or unstructured, in near real time, which aligns precisely with the needs of a modern observability approach.

The three pillars of observability: logs, metrics, and traces

An observability strategy is built on three complementary types of signals. Each addresses a different question and provides a specific perspective on system behaviour.

Logs: understanding what happened

Logs are events produced by applications and infrastructure components. In Elasticsearch, they are associated with a timestamp, either derived from the log event itself or from the ingestion time. They provide a high level of detail and make it possible to understand the precise context of an error, unexpected behaviour, or incident.

Elasticsearch has historically been well suited to this use case:

• ingesting large volumes of data,
• fast full-text search,
• fine-grained event exploration.

Logs provide valuable context, but they become difficult to exploit on their own as architectures become more distributed and data volumes grow significantly.

Metrics: measuring system state

Metrics are numerical data aggregated over time. They describe the overall state of a system and make it possible to track its evolution. Latency, error rates, and resource consumption provide a high-level view of application or infrastructure health.

In Elasticsearch, these data are stored as time-series. This enables aggregations, long-term trend analysis, and anomaly detection, while still allowing metrics to be linked to other technical signals.

Traces: following a request end to end

Traces describe the full journey of a request through a distributed system. They are essential for understanding dependencies between services and for pinpointing the exact source of latency or errors.

Each trace is composed of multiple segments representing different execution steps. Once indexed in Elasticsearch, these traces can be correlated with associated logs and metrics, making it easier to analyse complex behaviours in microservices environments.

How Elasticsearch correlates logs, metrics, and traces

The value of observability does not lie in individual signals taken in isolation, but in their correlation. Elasticsearch facilitates this correlation through several structural mechanisms:

• a shared indexing engine,
• common schemas such as ECS (Elastic Common Schema), which provides a shared structure for logs, metrics, and traces,
• cross-signal search capabilities.

In practice, this approach makes it possible to navigate naturally between signals. An alert triggered by a metric can lead to the analysis of related traces, followed by the exploration of logs associated with a specific request. Kibana plays a central role by making these correlations visible and actionable, through visualisations, dashboards, and exploration tools designed for cross-signal analysis.

Historically, Elasticsearch is best known for powering application search engines, particularly for indexing and querying website content. The same principles of fast, contextual search apply to observability data: logs, metrics, and traces are also indexed and queried as datasets, which makes large-scale exploration and correlation possible.

OpenTelemetry: a key standard for observability with Elasticsearch

In modern architectures, data collection is just as important as data analysis. OpenTelemetry has emerged as an open standard for application instrumentation, covering traces, metrics, and logs.

Elasticsearch natively supports OpenTelemetry, enabling signal collection to be standardised without relying on proprietary formats. This compatibility improves interoperability, reduces technological lock-in, and allows observability tooling to evolve without requiring changes to existing application instrumentation.

Observing your applications with Elastic on Clever Cloud

In a PaaS hosting context, observability must remain easy to enable and simple to operate. On Clever Cloud, Elasticsearch is available as a managed add-on. Applications can send their logs using Elasticsearch drains, enabling automatic centralisation of application logs. Several components can then be enabled depending on requirements:

• a managed Elasticsearch cluster,
• Kibana for exploration and visualisation,
• Elastic APM for application performance analysis.

This approach makes it possible to centralise application logs, collect relevant metrics, and trace requests without having to manage the underlying infrastructure. The goal is not to multiply tools, but to provide a coherent observability foundation integrated into the application lifecycle.

Conclusion

Observability is not about stacking monitoring tools. It is about correlating logs, metrics, and traces in order to understand increasingly complex systems.

Thanks to its indexing, search, and analysis capabilities, Elasticsearch provides a solid technical foundation for this approach. Combined with open standards and interfaces such as Kibana, it enables teams to move from fragmented visibility to a comprehensive understanding of application behaviour.

In modern cloud environments, this correlation is no longer a luxury. It is a necessary condition for operating production systems reliably.

It is in this context that the ELK stack has established itself as a technical foundation for analysing, searching, and visualising technical data, particularly logs.
In this article, we answer three key questions:

• What exactly is the ELK Stack?
• What is it used for today, especially in observability?
• How can it be used effectively without managing the underlying infrastructure?

ELK Stack: a clear definition

The ELK Stack is a historical acronym that refers to three components:

• Elasticsearch: a distributed search and analytics engine;
• Kibana: a data exploration and visualisation interface;
• Logstash: a data collection and transformation tool (depending on the context).

At present, Elasticsearch and Kibana form the functional core of the ELK stack, particularly for data analysis and visualisation use cases, once the data has been ingested into Elasticsearch.

The term Elastic Stack is also used, referring more broadly to the entire Elastic ecosystem. In common usage—especially in cloud environments—the ELK Stack generally refers to the combination of a data collection mechanism, often agent-based, with Elasticsearch for storage and analysis, and Kibana for visualisation.

What is the ELK Stack used for?

The ELK Stack is used to centralise, analyse, and exploit technical data coming from systems and applications. It enables large volumes of data to be indexed and analysed across wide time ranges, while correlating information from multiple sources, services, or environments.

This analytical capability makes it a widely adopted tool for understanding application behaviour, diagnosing incidents, investigating anomalies, or exploring operational data. Its main strength lies in the ability to move quickly from raw data to actionable insights, without relying on specialised tools for each individual use case.

ELK Stack and observability: what is the connection?

Observability aims to understand the internal state of a system through its observable signals. Among these signals, logs play a central role, as they describe precisely what an application is doing at a given point in time.

In this context, the ELK Stack provides a particularly well-suited foundation for log-centric observability. Elasticsearch enables large-scale search and correlation of events, while Kibana provides a visual layer that makes analysis and interpretation easier. Together, they make it possible to detect abnormal behaviour, reconstruct the timeline of an incident, and analyse trends over time.

In an observability approach, the ELK Stack is therefore mainly used as a log analysis foundation, complemented by other signals depending on the needs.

How to use the ELK Stack without managing infrastructure

One of the main barriers to adopting the ELK Stack has long been its operational complexity. Deploying, maintaining, and scaling such a stack requires handling capacity planning, upgrades, security, and backups.

In cloud environments, this operational burden can quickly distract teams from their primary goal: analysing data rather than managing infrastructure. This is why many teams now turn to managed approaches.

Managed approach

In a managed approach, Elasticsearch and Kibana are provided as ready-to-use services. The underlying infrastructure and part of the day-to-day operations—such as service provisioning, maintenance, backups, and access control according to the platform’s model—are handled by the platform. This allows teams to focus on usage rather than operations.

In this model, log collection is handled by the platform’s mechanisms. On Clever Cloud, applications and add-ons can expose their logs through drains, which redirect them to a target Elasticsearch instance without deploying any collection tooling inside the PaaS.

On Clever Cloud, it is for example possible to create an Elastic Stack add-on that provides:

• a managed Elasticsearch service;
• an associated Kibana instance;
• built-in security and backup mechanisms;
• a connection using the access credentials provided by the add-on.

This approach makes it possible to leverage the ELK Stack without managing low-level infrastructure concerns, while retaining the analytical power of Elasticsearch.

Concrete observability use cases

Application log analysis

Centralising application logs in Elasticsearch makes it possible to quickly search for errors, explore specific events, or filter data using multiple criteria. This capability is essential for understanding the real behaviour of an application in production.

Incident diagnosis

When an incident occurs, event correlation becomes critical. The ELK Stack allows teams to analyse event timelines, identify the components involved, and better understand root causes, without being limited to a fragmented view of logs.

Application behaviour monitoring

Over time, analysing indexed data in Elasticsearch helps detect trends, abnormal spikes, or behavioural changes. Kibana dashboards facilitate this analysis and provide a synthetic view tailored to technical teams.

Conclusion

The ELK Stack remains a solid foundation for analysing and exploiting technical data, particularly logs. Its role in observability practices has grown alongside the evolution of cloud-native and distributed architectures.

By relying on the functional core of the ELK Stack—namely Elasticsearch and Kibana—it is possible to build an analysis environment suited to modern needs without necessarily managing the underlying infrastructure. Managed approaches help reduce operational complexity and allow teams to focus on data value.

ELK Stack use cases continue to evolve. Recent work by Elastic on new log management models, such as streams, opens the door to more flexible approaches better suited to current data volumes. These evolutions build on existing foundations without calling into question Elasticsearch’s central role in observability data analysis.

For those looking to explore these use cases in a controlled environment, creating an Elastic Stack add-on on Clever Cloud offers a pragmatic way to approach Elasticsearch-based observability without turning operations into a constraint.

Since its launch, the UP Programme has supported early-stage and growing technology companies at various levels of maturity, with a strong focus on technical robustness, cloud infrastructure mastery, and the ability to scale a product over time.

Previous selections have welcomed startups from a wide range of sectors, including data, Green IT, fintech, healthtech, and legaltech. To discover them:

• Clever Cloud welcomes the first startups of the UP Programme
• UP Programme: Who are the newly selected startups?
• UP Programme: Discover the startups from the third cohort

The startups selected for this fourth edition

Moustache AI – Custom AI conversational agents

Moustache AI develops customised conversational and voice-based AI agents designed to adapt to the specific business use cases of each organisation.

The solution automates a large share of incoming requests while maintaining a high level of control over data, hosting, and regulatory compliance. Agents can be deployed quickly and integrated into existing tools, without heavy technical dependencies.

Diag n’Grow – Valuation of intangible assets

Diag n’Grow provides a platform for the financial valuation of companies’ intangible assets, such as software, patents, trademarks, data, or know-how.

The solution targets startups as well as SMEs and mid-sized companies facing challenges related to financial management, taxation, restructuring, or fundraising. Its goal is to deliver a clear, documented view of the real value of these assets, which are often underestimated in traditional financial statements.

Swily – Business software for self-employed nurses

Swily is a software solution designed to simplify the day-to-day work of self-employed nurses. The platform enables the management of patient rounds, medical records, billing, and electronic transmission, through an application built for field usage.

Developed in close collaboration with healthcare professionals, the solution addresses strict requirements in terms of reliability, data security, and service continuity, which are critical in the medical sector.

LeCoffre.io – Secure document exchange for notaries

LeCoffre.io is a secure document exchange and collection platform designed by and for notaries.

The solution aims to replace sensitive document exchanges via email, relying on advanced encryption and traceability mechanisms. Data is hosted in France and complies with strict requirements in terms of data sovereignty and regulatory compliance.

Expert-Flow.ai – AI platform for judicial experts

Expert-Flow.ai develops an artificial intelligence platform dedicated to judicial experts, designed to automate and structure the entire expert assessment process, from judicial requisition to final report delivery.

The solution significantly reduces the time spent on administrative tasks through automatic data extraction, interview preparation assistance and guided report drafting. Built for sensitive use cases, the platform meets high standards of security, confidentiality and regulatory compliance.

A new selection reflecting the supported ecosystem

The startups joining the UP Programme today operate in demanding environments, where technology lies at the very core of the product.

Artificial intelligence, finance, healthcare, or legaltech: these projects are already in production or in acceleration phases, facing concrete challenges related to performance, security, compliance, and scalability. These are issues commonly encountered by startups once infrastructure becomes a structuring concern. This is precisely the context in which their integration into the UP Programme takes place.

The UP Programme: a structured support framework

The UP Programme has been designed to support technology startups beyond the initial deployment phases. It combines cloud credits, technical support, access to Clever Cloud teams, regular exchange sessions, and increased visibility, enabling founders and product teams to focus on what matters most: building and evolving their solution.

Are you a startup and looking to join the UP Programme?

The next UP Programme selection will take place on May 16, 2026. Startups wishing to apply can already submit their application and start discussions with the Clever Cloud teams.

For engineering teams, the question goes beyond simple data location. It also involves application hosting, infrastructure automation, resilience, and the ability to operate cloud platforms reliably over time.

In this context, many organizations are increasingly looking for European alternatives to US hyperscalers such as AWS, Microsoft Azure, and Google Cloud.

Over the past decade, the French cloud ecosystem has matured significantly. Several providers now offer infrastructures and platforms capable of supporting both private-sector organizations and public institutions with demanding regulatory requirements.

This article analyses five major sovereign cloud providers in France, highlighting their technical positioning, strengths, and operational models.

Sovereign Cloud France: Key Takeaways

• A French sovereign cloud aims to ensure European governance and avoid exposure to extraterritorial laws such as the CLOUD Act and FISA Section 702.
• It helps organizations maintain GDPR compliance and stronger legal control over data.
• Some providers deliver Infrastructure as a Service (IaaS), while others offer automated Platform as a Service (PaaS) environments.
• Automation levels vary significantly between providers.
• Clever Cloud adopts a DevOps-oriented automated PaaS approach, reducing operational complexity for engineering teams.

What Is a Sovereign Cloud in France?

A sovereign cloud typically relies on several structural elements:

• a provider operating under European jurisdiction and GDPR compliance frameworks (data processing agreements, technical safeguards, traceability);
• governance independent from extraterritorial legislation such as the US CLOUD Act or FISA;
• infrastructure operated by the provider itself or by trusted sovereign partners;
• strong technical control over data, infrastructure, and operations.

Cloud sovereignty therefore does not depend solely on data center location.
It also relies on the legal framework, governance model, and operational independence of the cloud provider. In practice, sovereign cloud providers adopt different technical models.

Infrastructure as a Service (IaaS)

An IaaS provider offers raw infrastructure resources such as:

• virtual machines
• storage
• networking
• orchestration

Engineering teams must manage the architecture, deployments, high availability, and monitoring themselves.

Platform as a Service (PaaS)

A PaaS provider automates part of the operational layer, depending on the platform capabilities:

• application deployment
• runtime management
• scalability
• monitoring
• service continuity

This model reduces operational overhead and accelerates development cycles.

The 5 Best Sovereign Cloud Providers in France

The following providers offer cloud infrastructure or platforms capable of hosting and running applications within a sovereign French cloud framework.

1. Clever Cloud: Automated PaaS for Hosting and Deploying Applications

Clever Cloud is a French cloud platform founded in 2010 that allows organizations to host, deploy, and operate applications without managing the underlying infrastructure. The platform follows a Platform as a Service (PaaS) model that automates a large part of operational management and simplifies application deployment.

Clever Cloud is designed to simplify application operations for organizations of all sizes — from independent developers to enterprises and public-sector institutions. The platform handles automatic scalability, resilience, and monitoring.

Advantages

• Automated PaaS platform
• Native runtime support: Node.js, PHP, Docker, .NET, Go, Python, etc. 
• Managed Kubernetes (CKE)
• Native Git deployment and CI/CD integrations
• Platform-managed high availability
• ISO 27001, ISO 9001 and HDS (Health Data Hosting) certifications
• Sovereign infrastructure operated outside extraterritorial jurisdictions
• Reduced operational workload for engineering teams

Limitations

• Less suited for architectures requiring full IaaS-level infrastructure control
• No direct SecNumCloud certification (though a SecNumCloud environment is available through a partnership with Cloud Temple)

Why Clever Cloud Differs from IaaS Providers

Unlike traditional IaaS providers, Clever Cloud automates most of the operational workload. Engineering teams do not need to manage:

• virtual machines
• scalability
• resilience
• monitoring

The platform follows a simple principle: “You write the code. We run it.”

2. OVHcloud: Large-Scale European Cloud Infrastructure

OVHcloud is one of the leading European cloud providers. Founded in France in 1999, the company operates a large network of data centers across Europe, North America, and Asia. Its portfolio covers the entire cloud spectrum, including infrastructure, public cloud, private cloud, bare metal, and managed services. OVHcloud primarily targets large enterprises and public-sector organizations.

Advantages

• Extensive catalog of cloud services
• IaaS, PaaS, and bare-metal offerings
• SecNumCloud-certified services
• Managed Kubernetes
• European governance
• Infrastructure operated directly by the provider

Limitations

• Architecture can be complex to operate
• Automation often depends on integration layers
• Steeper learning curve for less experienced teams

3. Scaleway: Developer-Focused French Public Cloud

Scaleway is a cloud provider owned by the Iliad Group (Free) and is one of the most prominent French public cloud platforms. The platform provides a full public cloud offering including compute, storage, and managed services, and is widely used by technology startups and software companies.

Advantages

• French public cloud provider
• Managed Kubernetes
• S3-compatible storage
• Rich API ecosystem
• Transparent pricing model

Limitations

• SecNumCloud certification process currently underway
• Native CI/CD automation not included
• Primarily an IaaS-oriented platform

4. Cloud Temple: Sovereign Cloud for Regulated Environments

Cloud Temple is a French cloud provider specializing in highly regulated environments. The company delivers certified sovereign infrastructures and supports numerous public-sector projects. Its platform is frequently used for deployments requiring strong compliance frameworks.

Advantages

• SecNumCloud certification
• Strong positioning in the public sector
• Sovereign private cloud infrastructure
• Extensive regulatory expertise
• Personalized consulting and integration

Limitations

• Less developer-centric
• More project-driven offerings
• Solutions often structured around custom deployments and regulated environments rather than self-service application platforms

5. Outscale (Dassault Systèmes): SecNumCloud-Certified Sovereign Infrastructure

Outscale is the cloud subsidiary of Dassault Systèmes. The platform provides highly secure cloud infrastructure widely used in regulated sectors. Its cloud services are SecNumCloud certified by the French cybersecurity agency ANSSI, making it one of the most compliant cloud environments available in France.

Advantages

• SecNumCloud certification
• Strong regulatory compliance
• AWS-compatible APIs
• Infrastructure suited for regulated industries
• High resilience

Limitations

• Primarily an IaaS offering
• Less developer-focused
• Requires advanced cloud operational expertise

French Sovereign Cloud: A Mature Ecosystem

The sovereign cloud ecosystem in France is now highly developed and diversified. French providers cover the entire cloud spectrum:

• SecNumCloud-certified infrastructures
• public cloud platforms
• automated PaaS environments

This diversity allows organizations to select a platform that fits their specific priorities: regulatory compliance, performance, automation, or operational simplicity. For engineering teams, the right choice often depends on automation levels and internal operational capabilities.

In this landscape, automated PaaS platforms play a distinctive role. They help reduce operational complexity while maintaining a sovereign cloud environment. Clever Cloud follows this approach by combining platform automation, technological sovereignty, and open standards.