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

Why We Made This Change

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

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

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

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

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

Operating Your Own Network on the Internet

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

There are five RIRs worldwide:

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

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

Allocated Address Space

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

Creating Our Autonomous System

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

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

> whois AS213394

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

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

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

The Role of the RIPE Database

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

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

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

The BGP Protocol: How the Internet Routes Traffic

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

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

> show route for 91.208.207.0/24 all

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

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

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

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

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

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

The Migration Process

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

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

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

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

Migrating a prefix between ASNs

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

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

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

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

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

% Information related to '91.208.207.0/24AS43424'

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

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

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

Announcing Through Our Historical Provider

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

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

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

Announcing Through Our Own Transits

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

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

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

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

Complete Internet Routing Visibility

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

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

With this information, we are able to:

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

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

One Year Later

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

What's Next

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

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

Conclusion

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

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

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

In this context, the question is no longer whether to migrate, but how to structure what already exists, maintain control over day-to-day operations, and retain ownership of environments and data.

On Tuesday 28 April at 11:30 AM, Clever Cloud and Cycloid are hosting a webinar to address these challenges.

Two complementary perspectives on a shared challenge

We are offering a cross-functional discussion to provide concrete insight into these topics.

Cycloid covers the structuring and governance of environments through a unified internal developer platform and portal. Clever Cloud addresses managed operations, operational maintenance (MCO) and operational sovereignty.

Join Florent Perreux (Chief Sales Officer @ Clever Cloud), Steven Le Roux (CTO @ Clever Cloud), Alexandre Blin (Business Director SEMEA @ Cycloid) and Olivier de Turckheim (Solution Architect @ Cycloid) to understand how to align governance and operations without adding complexity.

Agenda

🔹 Why cloud modernisation goes beyond migration;plus à une migration;

🔹 Structuring and governance challenges in multi-cloud environments;

🔹 Operational challenges related to operations and maintenance;

🔹 How to align governance and operations without multiplying complexity;

🔹 A live Q&A session to ask your questions directly.

Why attend?

✅ Understand the root causes of complexity in cloud projects;

✅ Identify the levers to structure your usage and reduce vendor dependency;

✅ Gain a clearer understanding of operational and sovereignty challenges;

✅ Benefit from concrete real-world experience;

✅ Engage directly with experts.

Register now

🗓️ Tuesday 28 April 2026

⏰ 11:30 AM – 12:00 PM

💻 Online webinar on Livestorm

Facing these challenges? Join us on 28 April!

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

Built for production and scalability

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

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

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

Sovereign by design

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

Access details

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

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

Learn more

This transformation is taking place within a context of cost reduction, rationalization of existing infrastructures, and the pooling of IT resources.

In this constrained environment, the question is not only which provider or technology to choose, but which application execution model is best suited to the project at hand. PaaS (Platform as a Service) is one of the available options, provided its benefits, limitations, and applicable frameworks are clearly understood.

Challenges and issues specific to the public sector

Public organizations face structural constraints that directly influence their technical decisions. Budget pressure is constant, with explicit objectives to control or even reduce IT operating costs. Technical teams are often understaffed, with recruitment challenges for specialized roles such as system administrators, developers, cybersecurity experts, and cloud or DevOps engineers.

In addition, public organizations often rely on a heterogeneous and sometimes aging application landscape, built on technologies or environments that are no longer maintained or are difficult to evolve. Security, availability, and regulatory compliance requirements are high, while project timelines must remain aligned with the operational needs of administrations, local authorities, and public institutions.

How PaaS can address these challenges in the public sector

Using a cloud platform can address part of these challenges, without being a universal solution. One of its main benefits is the reduction of operational workload. In practice, this means that operating systems, application runtimes, deployment processes, restarts, and monitoring mechanisms are managed at the platform level. Technical teams no longer need to handle day-to-day infrastructure management and can focus on developing, improving, and maintaining applications.

From a security and update perspective, an application hosting solution also helps maintain technical environments more consistently up to date. In the public sector, where legacy management is a key concern, this reduces risks associated with obsolete systems, unmaintained dependencies, and delayed security patching. While this approach does not eliminate existing legacy systems, it helps structure their operation and supports gradual modernization without requiring a full overhaul of the information system.

In this context, a PaaS for public services can be a relevant lever, provided it is selected for clearly identified use cases.

Not all public projects fall under the same deployment framework

Public sector digital projects vary widely. An internal business application, a citizen-facing digital service, a data platform, or a research project do not involve the same constraints or levels of requirements.

Some contexts, particularly those related to defense or the processing of sensitive information, require enhanced guarantees in terms of security, control, and sovereignty. In such cases, specific qualification frameworks such as SecNumCloud may be required, limiting the available technical options. PaaS is therefore not suitable for all scenarios, and its use must be assessed based on data sensitivity and applicable regulatory requirements.

Existing public frameworks for deploying PaaS

Contrary to common belief, public sector organizations already have operational frameworks to access compliant cloud and application hosting services.

For administrations and public institutions, using UGAP provides access to a national purchasing body with pooled and legally secure contracts.

At a regional level, initiatives such as La Fabrique IA Territoriale, led by GIGALIS, offer local authorities and institutions in the Pays de la Loire region a structured framework to access digital and cloud services, with a focus on mutualization and support.

In the healthcare sector, hospitals can rely on Resah, which references solutions tailored to the specific requirements of healthcare environments.

These frameworks do not define technical use cases but provide concrete access points to services compliant with public procurement regulations.

When PaaS is particularly relevant

A managed cloud model is especially well suited when the goal is to build a new application without the need to handle system administration. It is also relevant for modernizing or refactoring existing applications, where the main objective is to simplify operations while improving reliability and security.

For application projects requiring fast deployment cycles, better cost predictability, and reduced administrative overhead, a cloud offering for public sector organizations can be a consistent choice, provided the functional and regulatory scope is clearly defined.

Key considerations before making this choice

Before choosing a PaaS, several factors must be carefully evaluated: the actual scope of platform responsibility, reversibility conditions, data location and protection, and alignment between data sensitivity and the guarantees provided. These elements determine whether the model is appropriate and sustainable over time.

Are you working on an application project within a public service and wondering whether a PaaS model is relevant in your context?

Identifying the right contractual framework helps save time and ensures compliance with public sector digital projects.

Or access Clever Cloud directly via public platforms:
UGAP for administrations and public institutions, La Fabrique IA Territoriale for organizations in the Pays de la Loire region, and Resah for healthcare institutions.

For years, cloud has been discussed primarily in terms of cost, scalability, and developer experience. Today, geopolitical risk is forcing a different conversation. Those dimensions matter. But geopolitical instability is forcing a different conversation — one about resilience, continuity, and control.

Geopolitical instability is now a cloud risk

Recent events in the Gulf have made this tangible. When regional tensions affect energy systems, logistics routes, and physical infrastructure, the consequences extend beyond ports and shipping lanes. They reach data centers, cloud platforms, and application availability. Both private and public actors may find their ability to operate significantly impaired.

Digital infrastructure is never purely virtual

The point bears repeating: digital infrastructure is physical. Cloud resilience starts with a simple fact: digital services depend on physical infrastructure, legal jurisdictions, supply chains, and people on the ground. Data centers, connectivity, power supply, and maintenance all depend on local conditions, local access, and local stability. When those conditions deteriorate, digital dependence becomes operational exposure.

Strategic digital autonomy deserves to be treated as a matter of preparedness, not ideology.

This does not mean isolation or withdrawal from international partnerships. It means ensuring that critical capabilities remain under trusted legal, technical, and operational control, particularly when the external environment becomes volatile.

For governments, regulated industries, and strategic enterprises, the question has evolved. It is no longer only about where workloads are hosted. It is about whether essential services can remain available when a region becomes unstable, when connectivity is degraded, when legal exposure shifts, or when infrastructure concentration creates systemic risk.

Resilience depends on control, not only scale

Scale brings clear advantages. But scale, resilience and control are not the same thing. Global platforms can also create dependencies that are easy to underestimate in stable times: single-provider concentration, single-region exposure, external jurisdiction, and logistical fragility. A major disruption does not need to take down an entire system. It only needs to affect enough of the stack to slow or paralyze operations.

In other words, cloud risk is no longer just a cybersecurity or procurement issue. It is also a matter of continuity, jurisdiction, and concentration. This is why sovereign and trusted cloud models should now be considered core elements of resilience planning.

In practice, that means protecting critical workloads on infrastructure that can be governed with confidence. It means reducing single-provider dependency, designing architectures that withstand degraded conditions, aligning legal jurisdiction with strategic interests, and investing in local skills, local operators, and local capacity.

In peacetime, these choices can appear redundant. In a crisis, they become the difference between disruption and continuity.

What is unfolding in the Gulf today confirms a broader trend: digital infrastructure now belongs to the same strategic tier as energy, logistics, and communications routes. The same geopolitical shock that disrupts supply chains and industrial activity can disrupt cloud availability in parallel.

What policymakers and executives should now assess

This should lead policymakers and executives to ask more direct questions. Who controls the infrastructure we depend on? Under which jurisdiction does it operate? How quickly can critical workloads be moved or isolated? Can essential services continue under degraded conditions? Do we genuinely control our continuity plan, or have we outsourced too much of it?

Cloud strategy is no longer an IT discussion. It is a matter of economic security and strategic independence.

For critical services, resilience must now be designed into the cloud strategy itself. The question is no longer whether to adopt the cloud. It is who remains operational when stability can no longer be taken for granted.

Cloudflare has just announced Vinext, a drop-in replacement for Next.js built on Vite. The project is vibecoded, experimental, but the promise is compelling: builds up to 4x faster, bundles 57% lighter, and 94% coverage of the Next.js API. We wanted to see how easy it would be to deploy it on Clever Cloud.

If you develop with Next.js, you know its strengths, but also its frustrations: sometimes slow builds, heavy bundles, and an ecosystem that can feel locked in. Vinext takes the approach of (almost) reimplementing everything — routing, server rendering, React Server Components, server actions, middleware — as a Vite plugin.

In practical terms, your existing Next.js code should work as-is. Your app/ and pages/ folders, your next.config.js: everything should be compatible. You just replace next with vinext in your scripts. While Cloudflare naturally highlights deployment on Workers, Vinext is not tied to their infrastructure. 95% of the code is pure Vite. The vinext start command launches a standard Node.js server, deployable anywhere. Including on our platform.

Deploying Vinext on Clever Cloud: as easy as it gets

There is no specific adaptation required. You simply need an application in a local Git repository, or a GitHub account linked to your Clever Cloud account, and push your code into a Node.js/Bun application. In our example, we used Bun, which is automatically detected and used.

So, if you have the Clever Tools and Git installed on your machine, all you need to do is:

# Clone the example repository 
git clone https://github.com/CleverCloud/vinext-example 
cd vinext-example

# Create the application, deploy it, open it in your browser
clever create -t node 
clever deploy 
clever open

That’s it. You get an application with a fully configured and up-to-date instance, a domain, and its SSL certificate already set up. Of course, you can easily change it and, with just a few settings, commands, or clicks in our Console, deploy this application in other countries through the infrastructures of our partners such as Ionos or OVHcloud, adjust the number or size of instances, and more.

An application created and deployed with AI

One of the goals of this project was also to see how far we could go by having a tool like Claude Code build and deploy this application by simply providing it with a few elements: the Vinext announcement blog post and the Node.js/Bun deployment documentation for Clever Cloud.

Overall, it went quite well. Between the initial prompt and the first production deployment of the application, only a few minutes passed.

Of course, not everything was perfect. Since Claude did not know Vinext, it initially added Next.js as a dependency to the project, and we had to ask it to remove it. We also suggested an optimization for running the build command, which it had triggered using the pre-run hook instead of post-build (right after downloading dependencies). We eventually defined it as a post-install script in the package.json. This change allows us to keep the full application in the build cache and therefore start a complete application, isolated in a virtual machine, in 15–20 seconds (30–40 seconds with the build).

For the rest, Claude Code read and analyzed the provided documentation, created the project, identified the correct Clever Tools options to create the application, and iterated on the demo page design based on our recommendations.

All of this happened in an interactive conversation where each choice could be discussed and adjusted. The AI proposes, the developer decides — it’s teamwork, made easier by the broad compatibility and speed of the Clever Cloud platform. Even part of this blog post was written that way. Can you guess which part?

Want to give it a try?

Even in version 0.0.5, the Vinext project looks promising. The build is fast, deployment works — now it’s time to challenge its Next.js compatibility to verify that it truly delivers, beyond the case of a simple application. The project is experimental, but it deserves close attention.

Deployment on Clever Cloud is immediate. One environment variable for the build, automatic Bun detection, and you’re in production. No Dockerfile, no CI/CD pipeline to configure. If your application listens on port 8080, it runs. You can even add Varnish cache, authentication, or other features via the Request Flow.

AI accelerates exploration. When facing a brand-new technology, having an assistant capable of reading documentation, writing code, and managing deployment in real time helps create proofs of concept (PoCs) and early iterations. We have put many initiatives in place to facilitate this, from our documentation automatically served in Markdown, with an LLMs.txt, a Skill, and a reference doc for the Clever Tools. Feel free to explore these possibilities and share your feedback with us — it will help us continue improving Clever Cloud and making developers’ lives easier, according to their needs.

The source code of the demonstration used in this project is available on GitHub. If you have any questions, our team is available to support you.

Identity and Access Management (IAM) has become a central component of any modern architecture. Authentication, user management, access control, regulatory compliance: these building blocks are critical, yet their implementation and long-term operation often remain complex.

To address these challenges, Clever Cloud launched IAM Keycloak as a Service in spring 2025, in partnership with Please Open It, a company specialized in Keycloak integration and expertise. This collaboration made it possible to design a managed service aligned both with open source best practices and with the real-world constraints of production environments.

Since its launch, Keycloak as a Service has evolved significantly to meet the concrete needs of businesses and the requirements of operating IAM at scale.

A Managed Keycloak, Built for Production

Keycloak as a Service is based on a simple approach: delivering the full functional richness of Keycloak without requiring teams to handle infrastructure, maintenance, or monitoring.

The service is natively integrated into the Clever Cloud Console. It therefore becomes a fully-fledged component of the platform, managed from a single control point, just like our other managed services.

Secured Multi Instances: High Availability and Scalability

One of the major evolutions is Secured Multi Instances. It enables Keycloak to be deployed in a clustered setup with multiple nodes, ensuring load distribution and high availability for a critical component such as IAM.

This architecture strengthens service continuity and the ability to handle increased traffic, while meeting the standards expected in production environments. Configuration and management of this architecture are directly accessible from the Clever Cloud Console.

A Dedicated Dashboard in the Console

A Keycloak dashboard is now available in the Clever Cloud Console. It centralizes the service’s essential information along with common administrative actions, making day-to-day management simpler and avoiding the need to juggle multiple tools.

Built-in Monitoring, Included

Monitoring is natively integrated into the service. Operational visibility is immediately available, with no additional configuration or external tools required.

This integrated approach simplifies operations while maintaining a high level of control over how your IAM runs.

Continuous Maintenance and Updates

Managed Keycloak is kept up to date. Recent Keycloak versions are made available as the product evolves, with no operational burden on the customer side.

This ensures access to security patches and functional improvements without heavy or risky upgrade projects.

Simplified addition to your applications

A more structural development concerns Request Flow, a technical foundation that makes it easier to use tools to secure access to your applications, including OAuth2-Proxy.

The latter is compatible with Keycloak, and its configuration is simplified on Clever Cloud. This allows you to implement authentication upstream of the application without modifying the application code. It is particularly well-suited for securing existing applications, back-offices, internal tools, or exposed services.

To Go Further

To present these evolutions in detail, share the technical choices behind them, and answer questions, a live session on Twitch and YouTube is scheduled for February 26 at 1:00 PM. It will be hosted by Horacio Gonzalez (Clever Cloud), joined by Mathieu Passenaud (Please Open It).

It will be an opportunity to take a concrete look at how our managed Keycloak works and to discuss real-world IAM use cases in production environments.

The bill extends to major local authorities the data protection obligations introduced by the SREN Act, thereby reinforcing the “cloud-first” doctrine. It also provides for derogation mechanisms for projects already underway or in cases of technical difficulties or significant additional costs. These provisions underline the need for pragmatic implementation while maintaining the central objective of effectively securing sensitive public data.

As an engaged actor within the French cloud ecosystem, we welcome this initiative, which aims to involve all stakeholders in the public debate on securing digital public procurement.

The Law Committee will examine the bill on 25 February. At the initiative of Philippe Latombe, Member of Parliament for Vendée (1st constituency) and rapporteur of the text, a roundtable discussion organised on 20 February will bring together several cloud providers operating in France, including Clever Cloud, OVHcloud, Orange Business Services, Scaleway, Outscale, Cloud Temple and Numspot.

Cloud obligations extended at the territorial level

Article 31 of the Act of 21 May 2024 on securing and regulating the digital space (SREN Act) already governs the use of cloud services by the State and its operators when processing sensitive data. It requires that such data be effectively protected against any access by foreign public authorities not authorised under European Union law.

The bill inserts Article 31-1 to make this mechanism applicable to regions, départements, municipalities with more than 30,000 inhabitants, urban communities, metropolitan authorities, and other major inter-municipal public establishments.

This provision builds upon Article 31 of the SREN Act and aligns with broader European developments, notably the entry into application of the Data Act in September 2025. It aims in particular to limit public authorities’ exposure to the effects of extraterritorial legislation, thereby extending to the territorial level a mechanism previously centred on the State.

A collective responsibility

Clever Cloud welcomes the opportunity to contribute to the parliamentary work on this bill.

“This hearing reflects a crucial awareness: the protection of public data can no longer be considered solely at the level of central government. Local authorities hold and process significant volumes of sensitive data that are essential to the continuity of public services and the protection of citizens. Supporting them in adopting solutions that ensure genuine legal security is not optional — it is a collective responsibility,” said Quentin Adam, CEO of Clever Cloud.

Clever Cloud intends to actively contribute to the legislative debate and to support local authorities in implementing technically reliable and legally secure solutions.

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.