For a new integration, OpenID Connect is the preferred choice when the application supports it; SAML 2.0 remains suitable for existing software or products that only support that protocol. Next, configure the OIDC redirect URIs or SAML assertion consumer service endpoints, then connect the application to the realm’s endpoints.

For IT departments, SSO addresses an everyday need: providing access to an entire application portfolio through a single login, with centralised security controls. Keycloak, an open-source identity and access management (IAM) solution, meets this need by centralising authentication.

Keycloak as a central identity provider

Keycloak sits between applications and their users. Users authenticate with Keycloak and, while their SSO session remains valid, can access connected applications without re-entering their credentials. Each application trusts the authentication information provided by Keycloak to establish its own session. This is how an identity provider (IdP) works.

Centralising login offers a tangible security benefit: according to the ENISA Threat Landscape 2025 report, the annual report published by the European Union Agency for Cybersecurity, phishing accounts for approximately 60% of the initial intrusion methods observed in the incidents studied. With Keycloak, multifactor authentication (MFA) policies can be enforced at the shared login point for connected applications. However, not all forms of MFA provide the same protection against phishing: passkeys and WebAuthn are phishing-resistant by design because the authentication key is bound to the domain for which it was created.

Each application maintains its own session. In a full OIDC integration, the application checks the session status with Keycloak and can therefore respond when that session ends. Some applications, however, only verify the JWT’s signature and validity period locally. In this case, a token that is still valid may continue to be accepted after the Keycloak session has ended. This is JWT-based authentication rather than full OIDC session management.

Keycloak supports OpenID Connect (OIDC) and SAML 2.0. Modern applications and existing software can therefore share the same single sign-on within a single realm.

Configure SSO with Keycloak, step by step

The Clever Cloud Keycloak documentation covers service access, realm management, IP address filtering, deployments in Secured Multi Instances mode, and metrics monitoring. For settings specific to OIDC and SAML clients, also refer to the Keycloak administration documentation.

To see the deployment process and interface in practice, watch the video demonstration on our Keycloak as a Service page.

OIDC or SAML 2.0 for SSO: which should you choose?

PoFor new development, choose OpenID Connect when the application supports it. Retain SAML 2.0 for applications whose integration already relies on that protocol or that do not support OIDC:

• OpenID Connect authenticates users of modern web and mobile applications; OAuth 2.0 and its access tokens control access to APIs.
• SAML 2.0 supports existing applications and enterprise software that do not offer OIDC integration.

Keycloak supports both protocols within a single realm. OIDC and SAML applications can therefore share the same single sign-on.

Configure SSO on a managed Keycloak instance

Configuring SSO is only part of the work: a Keycloak server then needs ongoing maintenance, updates, monitoring, and backups. A managed service takes on this operational workload.

Keycloak as a Service, Clever Cloud’s offering operated with the expertise of Please Open It, deploys a managed Keycloak instance hosted in France in just a few clicks. Teams retain control over all settings (realms, clients, and protocols) while Clever Cloud handles infrastructure operations, including ongoing updates, integrated monitoring, and regular backups. When the service is deployed in clustered Secured Multi-Instances mode, multiple nodes distribute the load and improve service continuity. Separately from this architecture, the 99.99% SLA, 24/7 on-call telephone support, and guaranteed response and resolution times are provided through the Premium offering for eligible services. Realm import and export make it easier to migrate an existing instance. Finally, to protect an application without built-in authentication, an authentication proxy such as OAuth2-Proxy adds a login step before users reach the application, without changing its code.

«Keycloak is a Red Hat product, but Red Hat does not provide an open-source LTS version of Keycloak, and security fixes are not backported. Staying on the latest version is therefore essential, and deploying Keycloak as a Service on Clever Cloud makes this much easier. A single realm, separate from master, is often sufficient; multiple realms are only justified when user populations are entirely independent, with no shared applications or with separate deployments. Keycloak also decouples the addition of authentication factors from applications, making it possible to offer the latest authentication factors across all integrated applications. »

— Loïc Mercier des Rochettes, Co-founder and CTO at Please Open It

Evaluating an IAM solution? Our checklist, 11 questions to ask before choosing an identity management solution, brings together the criteria to assess before making a commitment.

FAQ

Does Keycloak support SSO?

Yes. Keycloak is an open-source identity management solution that acts as a central identity provider: applications delegate login to it, and users authenticate only once. It supports OpenID Connect and SAML 2.0.

Should you use OIDC or SAML for SSO with Keycloak?

Both are suitable. OpenID Connect is designed for modern web applications, mobile applications, and APIs; SAML 2.0 remains the established standard for existing enterprise applications. Keycloak handles both protocols in parallel.

How do you connect an application to Keycloak?

Create a client in the relevant realm, then configure it according to the protocol used by the application. For OpenID Connect, this includes configuring its redirect URLs and providing the client ID, the realm’s discovery URL, and a secret only if the application can securely store it. For SAML 2.0, configure the application’s entity ID, its Assertion Consumer Service URL, and the metadata exchange with Keycloak.

Do you need to host Keycloak yourself to implement SSO?

No. A self-hosted Keycloak deployment requires you to manage installation, updates, security, and availability. A managed offering, such as Clever Cloud’s Keycloak as a Service, handles these operations; teams remain responsible for clients, users, permissions, and authentication policies.

Can you secure an existing application without changing its code?

Yes. An authentication proxy such as OAuth2-Proxy, connected to Keycloak, can require users to log in before forwarding requests to the application, without changing its code. This approach is particularly suitable for back-office applications and internal tools without built-in authentication, provided the application cannot be accessed directly by bypassing the proxy. Any application-specific authorisation rules still need to be defined.

Clever Cloud announces the opening of two new availability zones (AZs) in the Paris region, located at the ETIX Paris #3 data centre in Vélizy-Villacoublay and the Telehouse TH3 data centre in Magny-les-Hameaux. With these two sites brought into operation in 2026, the company now operates five AZs around Paris, up from three previously.

This expansion allows Clever Cloud to increase and renew its hosting capacity while, more importantly, strengthening the resilience of its infrastructure.

Five availability zones, one distributed infrastructure

This is the principle behind Clever Cloud's architecture. Computing resources are distributed across multiple availability zones, located in separate buildings some distance apart, but orchestrated through a single platform.

This approach enables workloads to be distributed across multiple physical infrastructures while reducing reliance on any single site. In the event of a hardware, power or network failure affecting one location, the other zones remain available and resources are automatically redeployed, helping to limit the impact of a localised failure on the platform as a whole.

Moving to five availability zones also strengthens Clever Cloud's distributed solutions, which can now withstand the simultaneous loss of two data centres while remaining available, compared with just one when operating across three zones. Resilience therefore depends less on the reliability of individual components and more on the infrastructure's ability to continue operating despite the loss of multiple sites.

Two new locations in the Paris region

The two new zones complement the three existing locations already operated by Clever Cloud around Paris.

The first has opened at ETIX's Paris #3 data centre in Vélizy-Villacoublay. The second is located at Telehouse's TH3 site in Magny-les-Hameaux, expanding Clever Cloud's longstanding presence with the operator, particularly at its TH2 data centre in Paris.

These openings also enable Clever Cloud to expand its hosting capacity to meet the growing demand driven by its business growth.

European equipment for greater infrastructure control

The choice of data centres is not the only important aspect of this expansion. Clever Cloud has also chosen to prioritise European manufacturers when equipping its new availability zones, including 2CRSI, a French server manufacturer based in Strasbourg, and Nokia, a Finnish technology company specialising in network infrastructure.

This decision forms part of a broader strategy to maintain control over its infrastructure, going beyond data location alone. Clever Cloud operates its own servers and network and develops the software technologies used to orchestrate its platform.

By working with European suppliers, the company also aims to support the development of a European industrial ecosystem capable of providing the equipment needed to operate digital infrastructure. This approach turns strategic autonomy into a tangible commitment, from the underlying hardware to the services delivered to customers.

"Our goal isn't simply to add more servers in new data centres. We designed Clever Cloud as a distributed infrastructure, capable of operating across multiple sites orchestrated together. With five availability zones around Paris, we're significantly strengthening our resilience. And as we invest in new equipment, we're also choosing to work with European manufacturers such as 2CRSI and Nokia. For us, strategic autonomy isn't just about hosting data in France: it's also about controlling the technologies we rely on and developing our own industry." Quentin Adam, CEO of Clever Cloud

FAQ

What is a cloud availability zone (AZ)?

An availability zone (AZ) is a set of computing resources hosted in a separate physical infrastructure within the same cloud region. Distributing resources across multiple AZs reduces reliance on any single site and strengthens service resilience in the event of hardware, power or network failures.

At Clever Cloud, the five availability zones in the Paris region are orchestrated through a single cloud platform.

Why do five availability zones improve resilience?

By distributing resources across five availability zones rather than three, Clever Cloud increases its ability to keep distributed services running despite infrastructure failures.

In particular, this architecture enables the distributed solutions concerned to withstand the simultaneous loss of two data centres, compared with one previously, subject to the replication and redundancy mechanisms specific to each service.

The five AZs also provide additional hosting capacity and enable workloads to be distributed more effectively across multiple physical infrastructures.

We challenged developers at Devoxx Belgium to build and deploy a real application, with a real database, in roughly 15 minutes. We gave them a little help from AI, a Belgian twist, and some LEGO as motivation. Here's what happened.

I've been attending Devoxx Belgium for almost 20 years. It's one of those conferences that means a lot to me, both personally and professionally. It's where I got the inspiration to create what would eventually become FinistDevs, where I started imagining myself as a conference speaker, and where, a few years later, I discovered that Developer Relations could actually be a job.

So when Clever Cloud decided to sponsor Devoxx Belgium this year, I was particularly happy.

But there was one question I wanted to answer before arriving in Antwerp: what could we do at our booth that would be genuinely interesting for developers?

Of course, we wanted people to discover Clever Cloud. That's why companies sponsor developer conferences in the first place.

But I didn't want to spend three days telling people how easy it is to deploy an application on our platform.

I wanted them to experience it.

And that's how the 15-minute Clever Cloud Challenge was born.

Stop Prompting. Start Shipping.

The idea was pretty simple.

Come to our booth. Open your laptop. Build a tiny application. Connect it to a real database. Deploy everything on Clever Cloud.

And do it in roughly 15 minutes.

There were only a few rules:

• Any stack. JavaScript, Python, Java, Go, whatever you prefer.
• Any AI. Claude, ChatGPT, Gemini, Copilot, or your favorite coding agent. We didn't care.
• A little Belgian flavor. Fries, beer, comics, cycling, Magritte, Devoxx itself. Anything vaguely connected to Belgium.
• A real database and a real deployment. Not a mockup, not a screenshot, not an application running only on your laptop. Something publicly accessible, with data that actually persists.

And because 15 minutes is a target, not a reason to punish someone for spending a little longer debugging, we weren't particularly strict about the stopwatch.

The important thing was to ship something.

We prepared a dedicated challenge page with instructions, a starter prompt people could copy into their favorite AI assistant, and a coupon giving them €200 in Clever Cloud credits, valid for six months.

The prompt suggested three small application ideas, helped the participant choose one, and guided them through development, database creation, and deployment.

We also added a little incentive: everyone who successfully completed the challenge could enter a daily LEGO draw. Because, well, LEGO.

But there was no jury, no ranking, and no prize for the most sophisticated application. A tiny, functional app had exactly the same chance of winning as an ambitious one.

We weren't organizing a hackathon, we were inviting developers to discover a platform by actually using it.

40 developers. 48 deployed applications.

And it worked.

Over the three days, 40 developers created and deployed an application with a real database on Clever Cloud.

I want to insist on that number for a moment.

Not 40 people who scanned a QR code, not 40 email addresses collected at a booth, not 40 coupons handed out.

40 developers who actually built something, provisioned a database, deployed their application, and came back to show us what they had shipped.

For me, that's a much more interesting result than the number of people who walked past our booth.

And the best part? What they built.

We deliberately kept the challenge open-ended. We didn't provide a template application or a predefined tutorial that everybody had to follow.

We gave people a goal, a few constraints, and the freedom to be creative.

The results were far more varied than I expected.

Some of my favorite applications

I couldn't possibly feature all 48 applications here, but I wanted to share a few that particularly caught my attention.

Not necessarily because they were the most technically sophisticated, but because they were fun, original, or made particularly good use of the challenge's constraints.

It's Raining Devs: Magritte meets Devoxx

Try It's Raining Devs

This one is probably among my favorites.

Take René Magritte's surrealist paintings, add a crowd of developers attending Devoxx, and turn the whole thing into an interactive, collaborative artwork.

Participants can create their own floating developer, choose what hides their face, give themselves a name, and join the painting.

And those developers aren't just temporary elements rendered in a browser. Each one is stored as a record in PostgreSQL on Clever Cloud.

There are even little interactions, a roll call, and postcards you can save or share.

I love this one because it combines something very Belgian, a genuinely playful idea, and a database that is an integral part of the experience.

It also illustrates something I really appreciate about these coding challenges: a tiny application doesn't have to be a boring application.

Roll for Waffle: let the dice decide your destiny

Roll your own Belgian waffle

What happens when you combine Belgian waffles with polyhedral dice, the kind you would normally use in a tabletop role-playing game?

You get Roll for Waffle, and I absolutely love it.

The concept is wonderfully simple: instead of choosing your waffle ingredients, you let the dice decide.

First, roll for your waffle base. Then roll for your primary topping. And finally, roll for a secondary topping. Each roll comes with a lovely animated polyhedral die, and the result is added to your creation.

Will you end up with a classic Liège waffle covered in speculoos spread and fresh strawberries? Or some completely improbable combination that no Belgian pastry chef would ever dare to serve?

That's the beauty of it. You don't get to choose. The dice have spoken.

And once your creation is complete, you can share your randomly generated masterpiece.

As someone who has spent a ridiculous number of hours rolling polyhedral dice over the years, this one immediately made me smile.

It's a perfect example of what I loved about the challenge: give developers a simple theme, a little freedom, and the opportunity to experiment, and they'll come up with ideas you would never have imagined yourself.

Now, if you'll excuse me, I have a waffle to roll.

Devoxx Bingo: because every conference has its clichés

Play Devoxx Bingo

If you've attended enough developer conferences, you know that some things are almost guaranteed to happen.

Certain expressions will be repeated. Certain technologies will be mentioned. Certain conference moments will feel strangely familiar.

Why not turn that into a bingo game?

Devoxx Bingo gives you a card of conference clichés to spot during the event. Mark them as you encounter them, and try to complete a row.

It's presented as an unofficial side quest, with absolutely no prizes and some very questionable bragging rights.

Exactly the kind of application that makes me smile.

And honestly, I can imagine people actually using it during a conference.

Devoxx YouTube Search: rediscovering conference talks

Explore Devoxx YouTube Search

Devoxx has an incredible collection of recorded conference talks on YouTube, accumulated over many years.

And as someone who has been attending Devoxx for almost two decades, I love the idea of making that knowledge easier to explore.

That's the idea behind Devoxx YouTube Search, another application created during our challenge.

What I particularly appreciate is the choice of subject. While many participants went for something playful or distinctly Belgian, this developer chose to build something directly connected to the conference and its content.

It's a lovely reminder that a challenge like ours doesn't have to produce just games and experiments. It can also inspire tools that address real needs within the developer community.

BelgiQ: how Belgian are you, really?

Try BelgiQ

BelgiQ describes itself as « Le quiz qui a la frite ».

That's already a good start.

It's a Belgian-themed quiz, available in French, Dutch, and English, with a leaderboard.

But what makes this application particularly interesting is that its creator, Gwenaël Jakab, shared his experience on LinkedIn.

Gwenaël decided to build BelgiQ using Node.js, Express and PostgreSQL. He used ChatGPT to prepare his prompt, then handed implementation and deployment to ChatGPT Work.

15 minutes later, he had a working application. After another 10 minutes of reviewing the result, making adjustments and requesting some refactoring, he had a V2 he was happy with.

And he hadn't written the application code himself.

What I particularly appreciated about his post was his perspective on the developer's role. Even when an AI agent handles implementation, someone still needs to make architectural decisions, define requirements, review the code and validate the result.

That's an important distinction, and one that sometimes gets lost in discussions about AI-assisted development.

For me, his experience also illustrates exactly what we were hoping to achieve with the challenge: let developers focus on what they want to build, while discovering how straightforward it can be to deploy it on Clever Cloud.

And the best part? You can try BelgiQ yourself.

Friesdvisor: the important questions in life

Explore Friesdvisor

Forget restaurant recommendations.

We're in Belgium. We need to talk about fries.

Friesdvisor is a directory where you can search for a friterie or a town and add new places.

It's a wonderfully straightforward idea, and exactly the kind of Belgian connection we were hoping people would invent.

I particularly like that it's not just a joke. It's a concept that could grow into a genuinely useful little community application.

And, of course, it needs somewhere to store all those friteries.

48 applications, and plenty more creativity to discover

These are just a few of my personal favorites.

But one of the things I loved most about the challenge was the sheer variety of ideas. Give 40 developers the same starting point, the same constraints, and roughly 15 minutes, and you get 48 different interpretations of what a tiny application can be.

Some went for games. Others built practical tools. Some embraced Belgian culture, while others found inspiration in the conference itself.

And I couldn't possibly do justice to all of them in a single blog post.

That's why we created the Built at Devoxx Belgium gallery, where you can explore the applications that participants chose to share publicly.

👉 Explore the Clever Cloud Challenge Gallery

Have a look around. Try the applications. See what people came up with.

And if one of them makes you smile, or gives you an idea for something you'd like to build yourself, then I think our little experiment has already achieved something pretty cool.

What did we learn?

A few things stood out to me during those three days.

First, developers are remarkably creative when you give them just enough constraints.

The Belgian theme was deliberately vague. We didn't want people spending ten minutes wondering whether their idea qualified.

A Belgian dish? Great.

A reference to a Belgian artist? Perfect.

A joke about Devoxx? Absolutely.

That small creative constraint gave people somewhere to start without telling them exactly what to build.

Second, AI coding assistants make this kind of exercise much more accessible.

Not everybody arrived with a project idea, a favorite framework, or a clear understanding of how to provision and connect a database. But with a little guidance, they could go from an idea to something running online surprisingly quickly.

Gwenaël's experience with BelgiQ illustrates another important point: AI-assisted development doesn't remove the developer from the process. It changes what the developer spends their time doing.

The developer still makes decisions, defines requirements, reviews the results, and takes responsibility for what gets shipped. Meanwhile, the coding agent can handle much of the implementation work, and the platform takes care of the infrastructure.

Of course, the AI didn't magically eliminate every problem. There were still deployment questions, configuration issues, and moments when someone needed a little help. That's why we were there.

But the combination of AI-assisted development and a platform that takes care of the infrastructure made it possible to focus on the interesting part: building and shipping the application. And that's exactly what we wanted people to experience with Clever Cloud.

Finally, I was reminded of something fundamental about Developer Relations.

Showing people how something works is useful. Helping them discover it for themselves is even better.

I could have spent fifteen minutes explaining how Clever Cloud handles deployments, databases, environment variables, and application hosting. Instead, developers spent those fifteen minutes doing it. And at the end, they had something of their own to show.

That's a very different conversation to have at a conference booth.

What's next?

The challenge doesn't have to end at Devoxx.

Everyone who participated received €200 in Clever Cloud credits, valid for six months after activation. That gives them the opportunity to keep experimenting, improve their application, or start something completely different.

We're also thinking about how to extend the experience with additional small challenges, encouraging participants to explore more of the platform.

And I'd really like to repeat this experiment at other conferences.

The Belgian theme worked beautifully at Devoxx Belgium. Imagine what developers could come up with at conferences in other cities or countries.

We already have a few ideas.

Your turn. Stop prompting. Start shipping!

I've attended a lot of developer conferences over the years, on both sides of the booth. I've distributed stickers, handed out T-shirts, given demonstrations, answered technical questions, and had countless conversations about cloud platforms. I still love all of that.

But watching someone arrive at our booth with nothing more than an idea, then return a little later with a working application deployed on Clever Cloud? That was particularly satisfying.

And seeing the creativity of those 40 developers made the whole experiment worthwhile.

So, to everyone who participated in the challenge at Devoxx Belgium: thank you!

Thank you for taking the time to try Clever Cloud, for embracing the slightly ridiculous Belgian theme, and especially for showing us what you built.

Want to give it a try?

Good news: you don't need to attend Devoxx to take the challenge!

The original Devoxx Belgium Challenge is still online, and we've also created a generic version of Stop Prompting. Start Shipping. that anyone can try, anywhere.

The special €200 Devoxx coupon is no longer available, but every new Clever Cloud account comes with €20 in free credits, which is more than enough to build and deploy a small application with a database.

Pick a theme. Open your favorite AI coding assistant. Give yourself 15 minutes.

Build something fun, connect a database, and deploy it.

And if you do, I'd genuinely love to see what you come up with. Share your application with me!

Stop prompting. Start shipping.

When these exchanges require the ports of different services to be publicly exposed, the attack surface increases and the network configuration becomes more cumbersome to maintain. Creating a private network between applications directly addresses this problem without requiring you to deploy or manage VPN infrastructure.

This approach allows cloud services to communicate directly with one another, over any port, without exposing the ports required for these exchanges to the Internet. Data travels over an encrypted overlay network that is independent of the physical network. On Clever Cloud, Network Groups provide this functionality: they establish WireGuard tunnels between resources, with no low-level network configuration.

Why exposing your services to the Internet is a problem

When application components communicate over public ports, each exposed service becomes a potential entry point. This has three practical consequences:

• Larger attack surface: every public access point must be secured, monitored, and maintained.
• Unnecessary exposure of technical ports: some protocols require dedicated ports for internal communications, even though they are not intended to be publicly accessible. A private network lets you use them without creating new entry points from the Internet.
• Reliance on external tunnels: connecting services distributed across several zones usually requires you to configure and manage an additional network layer, often a VPN.

Connecting services within a private network allows their internal traffic to flow without exposing the ports used for these communications. However, this does not disable any public access that is already configured. If only an API gateway should provide access to the backends from the Internet, you must also block their public endpoints.

How a private network between applications works

The approach is based on an overlay network: a logical network layer built on top of the existing physical network. Resources have private connectivity to one another, and their communications are encrypted by default. Because the overlay is independent of the underlying physical network, it can connect resources distributed across multiple zones or datacenters.

Consider an application comprising a public API, several backend services, and a database: only the API is exposed to the Internet. The internal services and database communicate with one another over the private network, using the ports they require.

Creating a private network between applications on Clever Cloud

Network Groups provide this setup. Each resource attached to a Network Group receives a private IP address from a dedicated CIDR, as well as an internal domain name in the format "<memberID>.m.<ngID>.cc-ng.cloud". The resources can then connect directly to one another, over any port, with no network configuration required.

A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. Communications are encrypted using WireGuard, a protocol known for its simplicity and speed.

You can create and manage Network Groups from the Clever Cloud Console, Clever Tools (CLI), or the public API. For example, from the command line:

clever features enable ng
clever ng create monNG --link app_xxx,postgresql_xxx

Note: add-on compatibility depends on their generation. Add-ons deployed since 2024 are compatible; older ones may require a migration or restart. See the documentation for the current limitations.

When should you use a private network between applications?

Network Groups are not a standalone solution: they enable certain secure architectures rather than replace an existing product. Several use cases are common.

• Protect applications behind an API gateway: the backends remain unreachable from outside while still being accessible from the gateway.
• Deploy Keycloak for high availability: multiple Keycloak instances synchronise over the private network without being publicly exposed.
• Enable microservices to communicate: in a distributed architecture, services communicate continuously without opening public ports or configuring tunnels.
• Integrate external resources: connect a local machine or third-party server to your Clever Cloud applications over an encrypted channel.

Connect your services without the complexity of a VPN

With Network Groups, private connectivity becomes a platform capability rather than infrastructure that you have to build and maintain. You choose which resources need to communicate; Clever Cloud establishes the encrypted private network between them. This allows you to use the ports required for internal communications without exposing them publicly, whether your resources are in the same zone, distributed across several data centres or, where applicable, external to Clever Cloud.

FAQ

What is the difference between a VPN and a private network between applications?

The main difference is what you have to manage. With a traditional VPN, you generally need to deploy, configure, and maintain connectivity between the relevant machines or networks. With Network Groups, Clever Cloud manages this layer for you: you attach the resources to the group, and the platform establishes encrypted private connectivity using WireGuard.

Do you need to modify your application code to use Network Groups?

In most cases, no. You do not need to rewrite your application. The change is in the configuration, not the code: the calling application must target the destination service using its internal Network Group domain name (<memberID>.m.<ngID>.cc-ng.cloud) and the required port, usually through an environment variable. No specific library or application changes are required for the traffic to use the private network.

Does a private network between applications work with machines outside Clever Cloud?

Yes. A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. However, support for attaching an external peer is still being stabilised during the testing phase.

Does a private network make an application invisible from the Internet?

No, not by itself. Network Groups provide private access to resources, but they do not disconnect an application from the Internet. Restricting public exposure is handled by other platform mechanisms.

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

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

What is a skill?

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

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

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

Installation

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

npx skills add CleverCloud/clever-tools

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

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

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

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

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

A real session

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

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

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

The application and its database

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

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

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

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

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

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

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

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

Deployment

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

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

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

Checking, from the application down to the database

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

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

$ clever features enable kv
Experimental feature 'kv' enabled

$ clever kv todo-kv-store PING
PONG

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

Reading the logs

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

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

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

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

Takeaways

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

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

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

Skill or MCP server?

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

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

In short

npx skills add CleverCloud/clever-tools

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

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

Developed with Please Open It, a specialist in SSO and identity management, the service lets you deploy a complete IAM solution on dedicated infrastructure in just a few clicks, while Clever Cloud and Please Open-It handle its operation, updates and ongoing maintenance.

As discussed when Keycloak as a Service became generally available, we have worked on a pricing model designed to make the service accessible to developers, solopreneurs, non-profit organisations, businesses and larger enterprises alike.

This pricing will come into effect on November 1, 2026. The first invoice reflecting the new pricing will therefore be issued in early December 2026.

We also recommend reviewing the number of active users across your instances to estimate the impact of the new pricing structure on your bill. This information will be added to the Keycloak dashboard before the new pricing takes effect.

Why the pricing is changing

Keycloak as a Service is more than simply hosting a Keycloak instance.

Each service relies on several dedicated resources — a Java application, a PostgreSQL database and a File System Bucket — as well as the operation and ongoing maintenance of the service.

This includes:

• tracking Keycloak versions and validating updates before making them available;
• handling security vulnerabilities, which is particularly critical for an authentication component;
• pre-configuring and simplifying many aspects of the service, including themes, plugins, metrics, and realm imports and exports;
• backups, observability and associated support;
• features developed around the service, including Secured Multi Instances, IP filtering, metrics and Grafana dashboards;
• continued product development with Please Open-It.

During the launch phase, part of this managed service was not billed separately. The introduction of this new pricing model now makes it possible to account for the service as a whole and to continue its development.

This change also comes with an increase in the minimum size of Keycloak as a Service instances. The base price, previously €37.25 per month for the minimum configuration, will therefore increase to €47 per month from November 1, 2026.

What is changing in the billing model

Until now, Keycloak as a Service billing was based primarily on the various technical resources used by the service: the Java runtime, PostgreSQL database and storage.

The minimum configuration was therefore previously billed at €37.25 per month. From November 1, 2026, the minimum instance size will increase and the base service price will rise to €47 per month.

From 1 November, billing will follow a model that is more directly tied to the Keycloak service itself and how it is used.

It consists of two components:

• a monthly price per service, set at €47 excl. VAT, including up to 100 active users per month;
• an additional charge per active user, with lower per-user rates at higher user volumes.

An active user is a user who has had at least one active session during the month, for example following a login or token refresh.

When does this pricing take effect?

It is important to distinguish between the date from which usage begins to be metered and the date on which it appears on your invoice.

In practical terms, the first invoice affected will be the one issued in early December 2026, covering your usage for November.

The variable portion of the price remains directly linked to your actual use of the service.

How can you prepare for the change to your invoice?

No action is required to continue using Keycloak as a Service: your existing services will continue to operate as normal.

However, you can use the coming weeks to review the instances that are currently active within your organisation, particularly any test or staging environments that are no longer in use.

We also recommend checking the number of active users across your instances to estimate the impact of the new pricing structure on your invoice.

If you would like a more precise estimate, our teams can review your configuration and usage levels with you to produce a simulation.

Contact us to review your situation with our teams.

For an IT department, SAML 2.0 addresses a practical question: how can an employee be given access to dozens of applications with a single authentication process, while centralising authentication policies through an identity provider?

What is SAML 2.0?

This centralisation of authentication is precisely what SAML standardises. Version 2.0 of the standard was approved by OASIS (Organization for the Advancement of Structured Information Standards) in March 2005 at its highest level of ratification. It brought together three earlier initiatives: SAML 1.1, the Liberty Alliance ID-FF 1.2 profile and contributions from the Shibboleth project. It was also adopted as an international recommendation by the International Telecommunication Union (ITU-T X.1141).

Technically, the SAML protocol is based on assertions: XML security tokens that describe a user, the “principal", and their authentication. These assertions are exchanged between two roles:

• The Identity Provider (IdP), which authenticates the user.
• The Service Provider (SP), which is the application the user wants to access.

More than twenty years after its ratification, SAML 2.0 is not a legacy protocol. It remains widely deployed in businesses, the public sector and academia, where it continues to provide a foundation for identity federation.

How does SAML authentication work?

SAML authentication involves three parties: the user, the Identity Provider (IdP) and the Service Provider (SP). In the most common scenario, known as “SP-initiated” authentication, the exchange works as follows:

Trust between the IdP and the SP cannot be established automatically. It must be configured beforehand through an exchange of metadata, including certificates, endpoints and identifiers. This allows each party to verify the authenticity of the other party’s messages. The assertion’s cryptographic signature guarantees that it came from the expected identity provider and has not been altered.

Components of the SAML 2.0 standard

The SAML 2.0 standard consists of several complementary components:

• Assertions: the statements themselves, which can contain three types of information: authentication information, attributes such as a role, department or email address, and, less commonly, an authorisation decision.
• Protocols: the request and response messages used to carry assertions.
• Bindings: the methods used to transport these messages over the web, for example through an HTTP redirect or an HTTP POST request.
• Profiles: predefined combinations of components for a particular use case. The best-known example is the Web Browser SSO Profile.
• Metadata: the technical description exchanged between the IdP and SP to establish trust.

Although SAML can carry authorisation decisions, its main uses remain Single Sign-On and attribute exchange. Fine-grained authorisation is generally handled by other mechanisms.

SAML 2.0, OAuth 2.0 and OpenID Connect: what are the differences?

These three standards are often confused, even though they do not address the same question:

• SAML 2.0 deals with authentication and Single Sign-On. It is based on XML and is widely established in enterprise environments, cross-organisational federations and the public sector.
• OAuth 2.0 deals with authorisation. It delegates access to a resource (for example, “Can this application read my calendar?”) and does not handle authentication on its own.
• OpenID Connect (OIDC) adds an authentication layer to OAuth 2.0, allowing an application to establish a user’s identity, particularly through an ID token in JWT format. It is suitable for web and mobile applications, while API access relies on OAuth 2.0 access tokens.

In practice, SAML 2.0 and OpenID Connect coexist. SAML remains the standard for existing enterprise applications, while OpenID Connect is generally used for new developments. The choice between SAML, OAuth 2.0 and OpenID Connect depends on the type of application, its authentication requirements and how access to APIs must be delegated.

Implementing SAML 2.0 with Keycloak

The most common way to deploy SAML 2.0 without reimplementing the protocol is to use an Identity and Access Management (IAM) solution. Keycloak, a leading open-source solution in this field, can act as a SAML 2.0 identity provider. It also supports OpenID Connect, allowing legacy SAML applications and newer OIDC developments to share the same authentication service.

Clever Cloud offers Keycloak as a Service: a fully managed Keycloak service hosted in France and operated with the expertise of Please Open It, a partner specialising in Keycloak. This approach removes the burden of operating the identity server, including updates, availability and backups, from internal teams, while allowing them to retain control over SAML and OIDC settings.

« SAML 2.0 remains essential in enterprise environments because of its long history (2005) but also because of its network simplicity: everything passes through the user’s browser, with no direct connection required between the application and the identity server. In contrast, the modern OpenID Connect standard requires direct server-to-server communication to remain secure. OIDC’s ‘100% browser-based’ mode, the Implicit Flow, has now been abandoned because it is considered too vulnerable. »

— Mathieu Passenaud, Co-founder at Please Open It

FAQ

Is SAML 2.0 still used in 2026?

Yes. Ratified in 2005, SAML 2.0 remains widely deployed in businesses, the public sector and academia for Single Sign-On and identity federation. It coexists with OpenID Connect, which is often preferred for new web and mobile projects.

What is the difference between SAML and SSO?

SSO, or Single Sign-On, is a principle: users authenticate once to access multiple applications. SAML is one of the protocols that can implement this principle across domains. OpenID Connect is another.

Does SAML handle authentication or authorisation?

It can handle both, but it is mainly used for Single Sign-On and attribute exchange. The protocol can carry authorisation decisions, although this capability is rarely used in practice.

Should I choose SAML 2.0 or OpenID Connect?

The choice primarily depends on the protocol supported by the application. SAML 2.0 is suitable for services designed to use SAML federation, while OpenID Connect is generally appropriate for authenticating users in web and mobile applications. OAuth 2.0 access tokens are used to control access to APIs. Both approaches can coexist behind the same identity provider, such as Keycloak.

Does Keycloak support SAML 2.0?

Yes. Keycloak can act as a SAML 2.0 identity provider and also supports OpenID Connect, allowing both protocols to be used together.

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

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

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

The four startups joining the sixth UP Programme cohort

Kernel: simplifying access to online care pathways

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

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

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

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

Nijal AI: deploying AI agents without giving up autonomy

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

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

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

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

Qiplim: turning content into interactive learning experiences

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

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

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

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

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

Arkan: from developing AI solutions to building its own products

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

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

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

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

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

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

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

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

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

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

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

The UP Programme: turning cloud infrastructure into a growth enabler

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

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

Selected startups can benefit from:

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

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

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

Want to join the next UP Programme cohort?

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

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

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

What Is a French Managed Kubernetes Service?

A French Kubernetes service is a managed Kubernetes service provided by a French company. Depending on the offering, the infrastructure may be located in France or elsewhere in Europe and may run on a public cloud, a private cloud or dedicated machines.

Why Choose a French Kubernetes Provider?

Greater Digital Sovereignty

Entrusting orchestration to AWS, Google Cloud or Azure exposes organisations to a proprietary ecosystem and a non-European legal framework. Choosing a domestic provider reduces this dependency and supports a broader digital sovereignty strategy that goes beyond technical portability alone.

Clear Infrastructure Location and Responsibility

Knowing exactly where the control plane and worker nodes are running—and who is responsible for operating them—has become a key selection criterion for regulated industries and public-sector buyers alike.

Easier European Compliance

Infrastructure operated in Europe can simplify certain compliance processes relating to data location and transfers outside the European Union.

Local Support and Contract Management

Having a provider in the same time zone, billing in euros and documentation available in French can shorten resolution times and streamline contractual relationships.

French Managed Kubernetes Providers

The descriptions below reflect the offerings available at the time of writing. These services evolve rapidly, so always check the provider’s official website before making a decision.

OVHcloud Managed Kubernetes Service (MKS)

OVHcloud offers MKS, its managed Kubernetes service for the public cloud, in two tiers. MKS Free provides a free managed control plane. MKS Standard, launched in September 2025, adds a 99.99% SLA, with a control plane distributed across a three-availability-zone region (initially Paris, followed by Milan) dedicated etcd storage of up to 8 GB, and a choice of CNI plugins, including Cilium. The service integrates with the OVHcloud Public Cloud ecosystem.

Scaleway Kubernetes Kapsule

Kapsule is a CNCF-certified managed Kubernetes service for the public cloud. Its shared control plane is free, with a dedicated control plane available as an option for mission-critical workloads, while autoscaling is supported natively. The service integrates with Scaleway’s services and emphasises digital sovereignty and GDPR compliance for the European market.

Clever Kubernetes Engine (CKE)

CKE is Clever Cloud’s managed Kubernetes service. It runs on infrastructure located in France, with no dependency on a foreign hyperscaler. Each cluster runs on its own virtual machines, with no infrastructure shared between customers. The control-plane architecture can be configured according to the selected topology, ranging from an all-in-one bundle to one VM per component. The experience remains true to standard Kubernetes, with no lock-in mechanisms or need to rewrite manifests. Cluster state is stored in Materia etcd, an implementation of the etcd protocol developed in France and built on FoundationDB. CKE integrates with managed databases, S3-compatible object storage, IAM, observability services and private networking through Network Groups. The product is currently in public beta.

Comparing French Managed Kubernetes Services

French Kubernetes offerings are based on different architectures and operating models. The most useful comparison criteria are infrastructure location, hosting model, availability guarantees, level of integration with cloud services and compatibility with the standard Kubernetes ecosystem.

None of these offerings is inherently superior to the others. The right choice depends on the required operating model and the level of assurance expected.

French Kubernetes vs AWS EKS, Google GKE and Azure AKS

AWS EKS, Google GKE and Azure AKS remain the most comprehensive managed Kubernetes services in terms of their wider service portfolios and global reach. In return, they increase dependency on their respective ecosystems. A French offering addresses the same orchestration requirements while keeping the control plane and data subject to European law.

French providers host their infrastructure in France or elsewhere in Europe, under European law and with locally operated integrations. Hyperscalers offer a broader service portfolio and global reach, at the cost of greater dependency on their ecosystems.

The general criteria for selecting a managed cluster (irrespective of the national dimension) also warrant careful consideration. These include version policies, autoscaling, storage and the responsibility model.

Key takeaways

The best French Kubernetes service ultimately depends on your specific context. Some organisations will prioritise a generally available offering backed by strong contractual guarantees, while others will seek close integration with their cloud platform or existing environment. OVHcloud, Scaleway and Clever Cloud currently offer different approaches to managed Kubernetes. The choice primarily depends on operational, governance and compliance requirements, as well as the expected level of maturity.

FAQ

Are There Any French Managed Kubernetes Providers?

Yes. Several French companies offer managed Kubernetes services, including OVHcloud with Managed Kubernetes Service, Scaleway with Kubernetes Kapsule and Clever Cloud with Clever Kubernetes Engine. These solutions differ in their infrastructure models, level of managed service and integration with each provider’s cloud ecosystem.

What Is the Difference Between French and European Kubernetes?

A French Kubernetes service is provided by a French company, while a European Kubernetes service is provided by a company established in the European Union. In both cases, it is important to examine the infrastructure’s actual location, the entity that operates the service and the law applicable to the data.

Does a French Provider Guarantee Digital Sovereignty?

No. A provider’s nationality alone is not enough to guarantee sovereignty. Sovereignty also depends on the infrastructure operator, any subcontractors involved in the hosting chain and the legal frameworks to which they are subject.

Can You Use Helm and Terraform with a French Kubernetes Service?

Yes, provided that the service uses a standard Kubernetes implementation. The services offered by OVHcloud, Scaleway and Clever Cloud remain compatible with widely used ecosystem tools such as kubectl, Helm and Terraform, as well as GitOps practices.

How Do French Kubernetes Services Compare with AWS EKS?

AWS EKS benefits from an extensive portfolio of cloud services and a global presence. French offerings generally emphasise operations carried out in Europe, local support and integration with locally operated infrastructure. The right choice depends on each project’s technical, regulatory and organisational constraints.

What Is the Difference Between Managed and Self-Hosted Kubernetes?

The main difference lies in operational responsibility. With managed Kubernetes, the provider operates the control plane and handles part of the platform’s maintenance. With self-hosted Kubernetes, the organisation remains responsible for installing, updating, monitoring and securing the cluster, as well as ensuring its availability. Managed Kubernetes reduces the operational burden, while self-hosting provides greater control over the infrastructure.

Can You Migrate from One Kubernetes Provider to Another?

Yes, provided that a standard Kubernetes implementation is used. YAML manifests, Helm charts and deployment tools generally remain portable from one provider to another. However, certain provider-specific dependencies, such as storage, networking and managed services, may require adaptations.

Which French Kubernetes Service Is Best for an SME?

The right choice depends on the project’s requirements. An SME may prefer an offering with a free control plane for its initial deployments or seek closer integration with a particular cloud ecosystem. In all cases, compatibility with standard Kubernetes makes it easier to move to another offering if requirements change.

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

From AI experimentation to industrialization

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

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

When AI also transforms software quality

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

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

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

Rust, legacy, and new software development practices

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

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

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

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

What role is left for developers and CIOs?

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

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

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

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

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