BSL is not an open-source license as defined by the Open Source Initiative: it restricts commercial use deemed competitive with HashiCorp's offerings. Overnight, thousands of organizations that had built their infrastructure around Terraform found themselves in uncomfortable legal uncertainty.

The response was swift. Less than a month after the announcement, a manifesto calling for a return to an open-source license had gathered 33,000 GitHub stars and the support of nearly 140 companies. HashiCorp did not budge. The fork was published in September 2023, brought into the Linux Foundation, and renamed OpenTofu. Since January 2024, it has been in stable production. Since April 2025, it has been part of the Cloud Native Computing Foundation (CNCF).

Our Terraform provider is fully compatible with OpenTofu. No changes to your configurations are needed to use it.

What is OpenTofu?

OpenTofu is an open-source infrastructure as code (IaC) tool, forked from the last MPL 2.0-licensed version of Terraform (1.5.x), distributed under that same Mozilla Public License 2.0. It lets you describe, provision, and manage cloud infrastructure through declarative configuration files written in HashiCorp Configuration Language.

It is developed under the governance of the Linux Foundation, with a Technical Steering Committee made up of representatives from multiple organizations — Gruntwork, Spacelift, Harness, Env0, Scalr — so that no single company can control its direction. That governance model is precisely what convinced many teams to make the switch: a guarantee that the tool will remain truly open source, regardless of how its contributors evolve commercially.

In practice, OpenTofu works with the same .tf files, the same providers, the same modules, and the same CLI workflow as Terraform — init, plan, apply, destroy. For the vast majority of teams, migrating comes down to replacing the binary.

What's the actual difference with Terraform?

The main difference is the license, and everything it implies in the long run.

Terraform is now distributed under the BSL, which restricts commercial uses that could be considered competitive with HashiCorp — a deliberately vague notion that HashiCorp (now a subsidiary of IBM) may interpret differently in the future. OpenTofu is distributed under MPL 2.0, a true open-source license with no commercial restrictions.

Beyond the license, the two projects have started to diverge technically since the fork. The most notable differences to date:<ul> <li><strong>State encryption:</strong> OpenTofu natively supports client-side encryption of state files — a feature long requested by the community that Terraform has still not implemented.

• Governance: OpenTofu is steered by a multi-organization technical committee within the Linux Foundation. Terraform is controlled by IBM via HashiCorp, with a roadmap driven by commercial priorities.
• Compatibility: OpenTofu maintains syntactic and functional compatibility with Terraform. Existing providers, modules, and configurations work without modification for the vast majority of use cases.
• The .tofu extension: OpenTofu supports this extension alongside .tf, allowing module authors to provide OpenTofu-specific variants while remaining compatible with Terraform.
• Terraform Actions: HashiCorp introduced "actions" in Terraform 1.9+, a feature that lets you trigger custom behaviors during resource lifecycle events. OpenTofu does not yet support them — this is the inherent trade-off of any fork: new proprietary Terraform features are not automatically available, and their implementation in OpenTofu depends on the technical committee's priorities.

Why teams are migrating to OpenTofu

Three reasons come up consistently.

Legal risk. The BSL prohibits using Terraform in products that could compete with HashiCorp's commercial offerings. For teams building internal platforms, cloud products, or managed services, this uncertainty is a real operational risk — especially since the definition of "competitive" belongs to HashiCorp and can evolve. On top of that, there is a less visible but equally significant reality: in the Terraform registry, open-source providers get no special visibility. Getting an "official" badge requires negotiating directly with HashiCorp — and paying for it. In the OpenTofu registry, all providers are on equal footing, regardless of the size or resources of their maintainers.

Strategic autonomy over tooling. Your infrastructure as code is the foundation of everything else. Depending on a tool controlled by a US company subject to the Cloud Act means introducing an additional dependency that many organizations would rather avoid. OpenTofu, under Linux Foundation / CNCF governance, offers continuity independent of any commercial actor.

Features Terraform doesn't ship. Native state file encryption is the most frequently cited example: requested by the community for years, implemented within months by OpenTofu. It is also a signal about how quickly community-driven governance can respond to real needs, compared to a roadmap driven by commercial interests.

Migrating from Terraform to OpenTofu

For the vast majority of teams, migration takes a matter of minutes. All you need to do is make sure the state is clean, install OpenTofu, and replace terraform with tofu in your commands.

# Make sure your state is clean before migrating terraform plan 

# → "No changes. Your infrastructure matches the configuration."

 # Install OpenTofu on macOS brew install opentofu 

# Install OpenTofu on Linux 

curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh 

# Resume your normal workflow 

tofu init 

tofu plan

tofu apply

Existing .tf files do not need to be modified. The OpenTofu registry mirrors all providers available on the Terraform Registry — including the Clever Cloud provider.

OpenTofu on Clever Cloud: nothing to change

Our official provider (CleverCloud/clevercloud, currently version 1.10) works identically with both Terraform and OpenTofu. The provider source, HCL syntax, and all available resources are exactly the same. A minimal example to deploy a Node.js application with a PostgreSQL database:

terraform {

  required_providers {

    clevercloud = {

      source  = "CleverCloud/clevercloud"

      version = "~> 1.10"

    }

  }

}

provider "clevercloud" {organisation}

resource "clevercloud_node" "app" {

  name       = "mon-app-node"

  region     = "par"

  min_flavor = "XS"

  max_flavor = "M"

}

resource "clevercloud_postgresql" "db" {

  name   = "ma-base-postgres"

  region = "par"

  plan   = "dev"

}

tofu init

tofu plan

tofu apply

The OpenTofu + Clever Cloud combination is a fully sovereign IaC stack: open-source tooling under Linux Foundation / CNCF governance, infrastructure hosted in our own data centers in France, outside the reach of the US Cloud Act. It is the choice increasingly made by teams who want full control over their entire toolchain — not just their data.

The Clever Cloud provider is available on the Terraform Registry and fully open source on GitHub.

Q&A

Is OpenTofu compatible with my existing Terraform configurations?

For the vast majority of use cases, yes. OpenTofu maintains syntactic and functional compatibility with Terraform. Existing .tf files, providers, and modules work without modification. Testing in a non-production environment before switching critical workloads is recommended.

Is OpenTofu production-ready? 

Yes. The first stable version was released in January 2024. The project has since surpassed 10 million downloads and is used in production by organizations of all sizes, including Fortune 500 companies. Its integration into the CNCF in April 2025 reinforced its credibility for enterprise environments.

What is the open-source alternative to Terraform? 

OpenTofu is the primary open-source alternative to Terraform. Distributed under MPL 2.0, maintained by the Linux Foundation, and a CNCF member, it is the direct continuation of Terraform in its original open-source state.

Is the Clever Cloud Terraform provider compatible with OpenTofu? 

Yes, with no configuration changes required. Our official provider (CleverCloud/clevercloud) works identically with both Terraform and OpenTofu.

How does OpenTofu work? 

In the same way as Terraform: you describe the target state of your infrastructure in HCL, OpenTofu computes the necessary changes (tofu plan) and applies them (tofu apply). It manages dependencies between resources, the state, and the full lifecycle of each resource. This is also where IBM's acquisition of HashiCorp introduces additional uncertainty: projects built around Terraform, such as CDK for Terraform, could be deprioritized or discontinued based on IBM's commercial decisions. With OpenTofu, the roadmap is public, discussed through open RFCs, and does not depend on decisions made behind closed doors by a single actor.

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.

They “push” their code, and we deploy it, while ensuring that the environment in which they operate is kept up to date and secure, with one clear objective: maintaining it in operational condition. Whatever the situation, their service responds.

Designing simple, robust and innovative services

We do this whilst minimizing the footprint on our servers, offering on-demand or automatic horizontal/vertical scaling. This means we can multiply instances or scale them up / down according to the load of your sites. This commitment to simplicity extends beyond applications, as we also offer a wide range of “as-a-service” database (DB) services, enabling you to deploy MongoDB, MySQL, PostgreSQL or Redis environments in a matter of seconds, with the same tools and guarantees.

However, over the past few years, we faced a number of recurring requests: not only did some of our customers wish to access other services, but they also regularly asked to take benefit of our infrastructure, spread over three datacenters, to obtain high-availability services. But when it comes to DB, this isn't always easy to implement while ensuring a high level of automation and data consistency. So we decided to develop our own range of products to achieve this.

The “Materia” project was born, based on the FoundationDB open-source transactional engine used, for example, by Apple for its iCloud services and by Snowflake. We're contributing to it and adapting it to our needs, while taking advantage of its distributed and resilient aspect, notably due to its significant simulation capacity. It allows us to imagine a whole universe of serverless services, very simple to use, invoiced on a pay-per-use basis, with compatibility layers we're developing to enable our customers to “talk” to it using existing protocols such as GraphQL or PostgreSQL, for example.

Materia KV available to all

We started with the Redis protocol to introduce Materia KV, currently in Alpha testing phase. It's a key-value database synchronously replicated across our three Paris datacenters. When our servers respond, your data has been written three times. Above all, it's very easy to use: go to our Console, create a Materia KV add-on, and you'll instantly obtain a token that can be used with any Redis client or by sending commands to our servers directly through the TCP protocol.

Thus, you can now benefit from a high-availability, key-value data storage solution, without having to configure a single instance, and with no minimum monthly fee: you simply pay for what you use. Above all, we provide this service with compatibility to existing protocols. Today Redis, tomorrow GraphQL. The list of supported commands is available here.

Launched at Devoxx France mid-April, Materia KV made a big splash on site and during our demonstrations since then. We've therefore decided to make it available to all, to enable our customers and the interested public to give us feedback on how it works for them, and what their needs are. While billing will be on a per-use basis starting with the Beta phase, right now it's free! So give it a try and let us know what you think.

Already built-in our tools and interfaces

Materia KV is of course available as an addon-provider in our API, Terraform (or OpenTofu, for example), but also in our CLI, Clever Tools. To create an access token, simply run the following command:

clever addon create kv NAME

This add-on can be linked directly to a Clever Cloud application, injecting its environment variables. But you can also use it from any third-party service, command-line client (CLI) or with graphical user interface (GUI).

While Materia KV and its various interfaces will be developed over time, we've started to think about integrating it into Clever Tools. A test branch, available as a binary and documented, offers a clever kv command.

With it, you can directly send requests to Materia KV by having the environment variable configured locally, or by specifying an ID in your commands:

# With Bash and Zsh
source <(clever addon env ADDON_ID --export)
# With Fish
clever addon env ADDON_ID --export | source

clever kv PING # PONG
clever kv set yourKey theValue
clever kv get yourKey

As this demo version doesn't handle all the commands managed by Materia KV, you can send a “raw” command and it will return the answer :

clever kv redis_raw 'hset key field1 value1 field2 value2' # 2
clever kv redis_raw 'hget key field2'                      # value2
clever kv redis_raw 'hgetall key'                          # the full hash

To demonstrate the possibilities of such integration, you also have the option of directly querying a JSON object stored in a key :

clever kv set simpleJson '{"key": "value"}' # the set data
clever kv getJson simpleJson key            # value
clever kv set jsonKey '[{"key": "value"}, {"bigKey": {"subKey1": "subValue1","subKey2": "subValue2"}}]'
clever kv getjson jsonKey bigKey.subKey2    # subValue1
clever kv getjson jsonKey ''                # the full JSON

To show just how simple such implementations can be, we've written a Materia KV client in Go using Go-Redis. If you'd rather understand how you can send commands and receive responses from Materia KV directly in TCP, you'll find examples in both V or Ruby.

Feel free to create your own and let us know ;)

A demonstration of Materia KV on Twitch, a community space

Want to find out more? Horacio González, our head of DevRel, will be giving a demonstration on Twitch on Tuesday June 18 at 13h15 (Paris Time). Pierre Zemb, creator of Materia at Clever Cloud, will also be discussing with our CTO Steven Le Roux in a video published at the end of June on Clever Cloud's YouTube channel.

And to share your views, questions and requirements, go to the Materia-dedicated section of our GitHub community space.

Clever Cloud was founded nearly fifteen years ago, out of a desire to innovate in the field of web hosting and deployment, by offering a reliable range of services in a simple, straightforward way. As a result, we became Europe's leading provider of PaaS services, attracting developers and key accounts alike.

More importantly, we are unique in offering these solutions on our own infrastructure, as well as on-premise or through various partners around the world. We now do this with ISO 9001 and 27001:2022 certification, with HDS and SecNumCloud as our next targets.

Over the years, our company and its product range evolved and expanded. But we've never compromised with our original vocation: innovation. That's why, alongside the continuous improvement of our services, interfaces and integrations, we are massively investing in the development of our future, in solutions that will meet our customers' needs ever more effectively, and over which we have full control.

This is where the independence and sovereignty of our offering comes in. That's why we've decided to build our own infrastructures, to choose a GNU/Linux system to which we actively contribute, and to use it on both our servers and our network equipment. It's also why we've spent the last few years developing a range of serverless, easy-to-use, pay-as-you-go products.

• What’s Clever in our cloud ?

Clever Functions: WASM stands for compatibility and efficiency

To achieve this, we didn't hesitate to create our own low-level virtualization and function execution layer. We wanted to maintain our strong isolation criteria by setting up virtual machines that we activate as close as possible to the CPU. We also wanted to be able to achieve good performance while opening up to a wide range of languages, rather than simply relying on v8 at the risk of focusing almost exclusively on JavaScript.

So we opted instead for a solution that leverages the capabilities of the WebAssembly standard (WASM/WASI), which can be used with a wide range of languages, from Go to Zig as well as C, Rust or AssemblyScript... and of course JavaScript.

After a successful first demo of our Tech Preview in Barcelona at the WASM.io conference last month, we'll be demonstrating again at Devoxx Paris, which takes place at the Palais des Congrès from April 17 to 19. Feel free to come and talk to us about it, and let us know if you're interested in taking part in the next stages of development of this product, which will be progressively opened up over the course of the year.

Materia KV: our distributed, multi-protocol, serverless revolution

Another major innovation from our team is the new Materia offering. To achieve this, we have designed our own serverless databases, built on the FoundationDB open source transactional engine, used, for example, by Apple for its iCloud services. We are also an active member of its community, participating in the development of its ecosystem.

Distributed and robust, notably thanks to its high simulation capacity, it has enabled us to design and build a whole range of services to meet the different needs expressed by our customers in recent years. Our approach is always open and resilient, with deployment across multiple availability zones, compatibility with existing protocols and clients, and pay-as-you-go billing.

The first to be publicly announced is Materia KV, which, as its name suggests, is a key-value database. To create one within your Clever Cloud account, you have no instance size to choose, no storage capacity to worry about. We simply provide you with a host address, a port and a token (based on the Biscuit technology to which we actively contribute), and you're ready to go!

You can then send us your keys and their contents. They will be synchronously replicated in our three Paris datacenters. So you don't have to set up any complex configurations to ensure high availability, or even activate any options. Materia KV is resilient by design! And it adapts to individual needs, as it's billed on a pay-as-you-go basis. It's the perfect solution for hobbyists, seasoned developers and key accounts alike.

Redis API compatibility… to start with

We didn't want this innovation to come at the cost of complex configuration, requiring the use of special clients and ORMs. That's why we've developed Materia KV's own compatibility layers.

To "talk" to it, you don't need a special API or tools specific to Clever Cloud. You can use it with existing solutions for GraphQL or Redis. The latter is the first of the compatibility layers available in our test phase. It enables customers using a Redis instance for their application to migrate to Materia KV with just a few clicks in their interface or via Clever Tools.

This solution will be publicly demonstrated for the first time at Devoxx Paris, which takes place at the Palais des Congrès from April 17 to 19. It will then be rapidly made available to all our customers in alpha. Feel free to come and talk to us about it, and the other serverless services we'll be offering later this year.

We'll also be demonstrating other upcoming new features, such as our Keycloak-as-a-Service solution in partnership with Please Open It, and celebrating the release of version 1.0 of our in-house, open source load balancer, developed in Rust: SŌZU!

To keep up to date with our regular developments, be sure to follow our Changelog (via its RSS feed), or this blog. But also follow us on LinkedIn or X/Twitter.

We are delighted to announce the arrival of our new support system: the Ticket Center. In order to continue to provide one of the best support services on the market, we remain attentive to our customers' feedback on our quality of service. In this context, we have received numerous requests to implement a system that better distinguishes each conversation.

We therefore considered how best to continue to provide a fast and quality service and the introduction of a ticketing system seemed to be the most appropriate solution to meet the needs and expectations of our users.

What's new

Ticket-oriented use

Now, the platform usage is more "ticket" than "chat" oriented. This allows for a unique authentication of each request to ensure better follow-up.             

Adding participants to the conversation

You can now choose to automatically add members of the relevant organisation when opening a ticket. This improves your Crisp experience by ensuring that the response from our support team is accessible to all your organisation team.

When you open a ticket :

• If you are an admin, the other admins in the organisation will be added
• If your role is different of admin, members of the organisation with the same role as you will be added

How does the Ticket Center work?

Accessing the Ticket Center from an organisation

We have integrated a new button "Contact support team" in the console, at the top of an organisation. It will allow you to open the Ticket Center directly in the context of the organisation you are in. This allows support to know at a glance which organisation you are opening a ticket for.

Accessing the Ticket Center from the console's main menu

The button used until now, which was called "talk to a human" still exists, under the name "contact support". You can find it as before, at the bottom left of the main console menu. A "Select your organisation" page will then open to allow you to specify the organisation for which you wish to create a ticket.

Create a ticket

When you open the Ticket Center, you will find the history of your previous tickets. Please note that all your previous chat conversations with support have been converted into a single ticket, so you will be able to access all your former discussions if required.

Here you can also: get information on the status of your request, view the associated conversation and open a new ticket.

Giving your feedback

Once the ticket is closed, you will receive an email as usual to give your feedback, this is the time to give us your opinion on the service that was provided to you by the support.

What it allows

With the old way of working, conversations between support and a user often contained several different topics. Today, each request counts, in a unique way, which brings : 

• Better follow-up of requests.
• A more collaborative tool, by allowing you to add participants to the conversation
• A more efficient response thanks to the unique identification of each ticket.

We are confident this new Ticket Center will allow us to continue to provide a fast and quality service. Feel free to contact us and give us your feedback and ideas regarding this new system.

Keycloak is a modern and efficient way to deal with identity and access management. It allows for single sign-on, user federation across multiple user directories. It's also compliant with standard authentication protocols like OpenID Connect, OAuth2 or SAML. All details are available on its website. This blogpost will go through steps to deploy Keycloack and Grafana on Clever Cloud.

How to deploy Keycloak

Setup

Keycloak is written in Java, and gives a JAR file in their release, which means we will use a a JAVA runtime with a JAR deployment. It also requires a PostgreSQL Database, which means we will deploy a PostgreSQL addon.

# Get lastest Keycloak release
wget https://github.com/keycloak/keycloak/releases/download/17.0.1/keycloak-17.0.1.zip

# Extract the archive
unzip keycloak-17.0.1.zip

# Go to the folder
cd keycloak-17.0.1

# Create the jar application
clever create --type jar keycloak-server
export KEYCLOAK_DOMAIN=$(clever domain | xargs)

# Create the PG addon
clever addon create postgresql-addon --plan s_sml --addon-version 10 keycloak-postgres

# Link the addon
clever service link-addon keycloak-postgres

Configure

For now we will configure Keycloak through environment variables. Note that you can also do configure Keycloak through its CLI or through a file, as stated in its documentation.

Note: For the configuration through environment variables; the pattern to use is KC_ and the uppercase name of any configuration key, separated by underscores.

# Export env for templating purpose
export $(clever env | sed '/^#/d;s/\"//g')

clever env set CC_JAR_PATH lib/quarkus-run.jar
clever env set CC_JAVA_VERSION 11
clever env set CC_RUN_COMMAND "bin/kc.sh start --auto-build"

clever env set KC_DB postgres
clever env set KC_DB_USERNAME $POSTGRESQL_ADDON_USER
clever env set KC_DB_PASSWORD $POSTGRESQL_ADDON_PASSWORD
clever env set KC_DB_URL "jdbc:postgresql://$POSTGRESQL_ADDON_HOST:$POSTGRESQL_ADDON_PORT/$POSTGRESQL_ADDON_DB"
clever env set KC_HOSTNAME $KEYCLOAK_DOMAIN
clever env set KC_HTTP_ENABLED true
clever env set KC_PROXY passthrough
clever env set KC_PROXY_ADDRESS_FORWARDING true

Note: Consider setting KC_DB_POOL_MAX_SIZE at a lower value (default is 100) regarding the database size you ordered earlier. You can find the connection limit here. If you used the S_SML size that is in the command earlier, you can ignore this message. You can also fine tune the database connection pool using KC_DB_POOL_INITIAL_SIZE and KC_DB_POOL_MIN_SIZE

Now, you need to define KEYCLOAK_ADMIN and KEYCLOAK_ADMIN_PASSWORD :

clever env set KEYCLOAK_ADMIN <choose an admin username>
clever env set KEYCLOAK_ADMIN_PASSWORD <choose an admin password>

Deploy

Deploy Keycloak on Clever Cloud:

# Init a git repository
git init

# Add your files
git add .

# Create the first commit
git commit -m "clever init"

# Deploy the application
clever deploy

# Open Keycloak in your browser
clever open

Validate the configuration

You can follow the Keycloak documentation starting here to ensure Keycloak works as expected. It will take you through a realm (tenant) creation, user creation and client creation/test.

Create an Initial Keycloak configuration

In the keycloak UI, ensure you create a Realm called "myrealm" (hover "Master" on the top left corner). Ensure the realm "myrealm" is selected.

Then, go to Users > Add a User. Fill the Username, Email, First Name and Last Name fields, then hit save.

In the credentials tab of the user, add the password of your choice and deselect "Temporary", the set password.

You're all set.

A real world scenario

Let's see how we can use Keycloak in the real world: as an SSO Proxy for Grafana, using Oauth 2.

Setup Grafana on Clever Cloud

If you need a in-depth guide on how to use or deploy Grafana please read this article, the following is a helper to illustrate the usages of Keycloak.

Let's use the grafana-example on Clever Cloud's Github repository.

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

# Enter the directory
cd grafana-example

# Create a NodeJS Application
clever create --type node grafana
export GRAFANA_DOMAIN=$(clever domain | xargs)

# Configure Grafana
clever env set GRAFANA_VERSION 8.5.2
clever env set GRAFANA_PLUGINS "grafana-worldmap-panel"
clever env set GF_PLUGIN_DIR ./data/plugins

clever env set GF_SERVER_HTTP_PORT 8080
clever env set GF_SERVER_ROOT_URL "https://$GRAFANA_DOMAIN"

Note: In this section you need to set the GRAFANA_SHA_256 variable yourself. You can find the SHA256SUM required here, next to "Standalone Linux Binaries"

clever env set GRAFANA_SHA_256 <SHA256SUM>

Configure Keycloak for OAuth 2

Note: In this section, you need to replace $GRAFANA_DOMAIN with the value you exported in the last section. You can find this value by running the following command: clever domain

In the Keyloak UI, Go to Configure > Clients > Create

Create a new client with these configurations:

Client ID: $GRAFANA_DOMAIN
Client Protocol: openid-connect
Root URL: https://$GRAFANA_DOMAIN

Further make these configurations:

Access Type: confidentials // The OAuth client must use a client id and secret.
Root URL: ${authBaseUrl}
Valid Redirect URIs: https://$GRAFANA_DOMAIN/login/generic_oauth
Base URL: /login/generic_oauth

Clear Admin URL and Web Origins.

Click save and open the Credentials tab. Copy the Secret into a separate note, we will need it in the second and third part of this tutorial.

Open the tab Roles and click Add Role. Create a new role with name admin. This role defines the access level for Grafana.

Head over to Scope tab and set Full Scope Allowed to OFF. We do not want to share any other details about the realm in the client token.

Then, we are going to configure a client mapper for the roles property. We must ensure that Grafana can extract the access role from the JWT token. Open the Mappers tab and click on Create. Create an entry with these options:

Name: Roles
Mapper Type: User Client Role
Client ID: $GRAFANA_DOMAIN
Token Claim Name: roles
Claim JSON type: string

Finally, assign the client role to your Keycloak user: Go to Users > View All Users and click on the ID of your user. Click on the Role Mapping tab, then in the Client Roles selector, select $GRAFANA_DOMAIN. In the Available Roles section, select admin and click Add selected.

Configure Grafana for OAuth 2

# Configure appropriate env vars
clever env set GF_SERVER_DOMAIN $GRAFANA_DOMAIN
clever env set GF_SERVER_ROOT_URL "https://$GRAFANA_DOMAIN"
clever env set GF_AUTH_GENERIC_OAUTH_ENABLED true
clever env set GF_AUTH_GENERIC_OAUTH_NAME Keycloak
clever env set GF_AUTH_GENERIC_OAUTH_ALLOW_SIGN_UP true
clever env set GF_AUTH_GENERIC_OAUTH_CLIENT_ID $GRAFANA_DOMAIN

clever env set GF_AUTH_GENERIC_OAUTH_SCOPES profile
clever env set GF_AUTH_GENERIC_OAUTH_AUTH_URL "https://$KEYCLOAK_DOMAIN/realms/myrealm/protocol/openid-connect/auth"
clever env set GF_AUTH_GENERIC_OAUTH_TOKEN_URL "https://$KEYCLOAK_DOMAIN/realms/myrealm/protocol/openid-connect/token"
clever env set GF_AUTH_GENERIC_OAUTH_API_URL "https://$KEYCLOAK_DOMAIN/realms/myrealm/protocol/openid-connect/userinfo"
clever env set GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH "contains(roles[*], 'admin') && 'Admin' || contains(roles[*], 'editor') && 'Editor' || 'Viewer'"

Note: In this section, you need to define GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET yourself, using the value in Keycloak UI, under Client > $GRAFANA_URL > Credentials

clever env set GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET <KEYCLOAK_CLIENT_SECRET>

You can now deploy Grafana:

# Deploy grafana
clever deploy

# Open grafana and try the Login with Keycloak button !
clever open

Now hit login with Keycloak, and use the username and password you defined for the user you created Earlier in Keycloak.

Using the same procedure describe earlier to create the first user, you can now create more users and roles. Create the roles "editor" and/or "viewer" and assign them to your new users within Keycloak. Try to connect with those on Grafana and you will see the roles are propagated to Grafana.

Sources:

• https://janikvonrotz.ch/2020/08/27/grafana-oauth-with-keycloak-and-how-to-validate-a-jwt-token/
• https://www.keycloak.org/getting-started/getting-started-zip

Over the last few months, we have started a major but gradual redesign of our web interface, the Console. Under the leadership of Hubert Sablonnière, whose team is welcoming new developers, the modules are refined and managed in an increasing way through Web Components (see this talk).

An editor accepting JSON format

The last change released is related to the environment variables management. Until now it was proposed with a Simple or Expert mode. We have added a third, using JSON format. You can read/write in it, and so export or paste a complete configuration:

The Simple editor (left) and the new JSON one (right)

The first one displays environment variables as name/value fields, you can add or remove them depending on your needs. The other two uses editable fields, but with a text or JSON format, accordingly. When the content is modified, checks are run to inform you if there are any formatting or variable management errors.

These checks are now more strict, with one exception: in some applications, such as those in the Java ecosystem, variables name may contain a dot. In this case, they will be injected as properties and not as environment variables. The rules are detailed here. The reference of our environment variables is documented there.

The Config Provider is now using a Web Component

Please note that the new editor has been designed as a Web Component. It is thus reused to display the environment variables of add-ons and has just replaced the one used for the Config Provider which was a simple multi-lines text editing field. 

As a reminder, this add-on allows you to create a list of environment variables that can be shared by different applications. To use it, you just need to integrate the Config Provider as a service dependency in their settings.

The Config Provider with the Web Component editor (left) vs the previous basic editor (right)

Dans cet incroyable épisode, il est question de l'accord entre Elastic et Amazon, du nouveau site de MDN, de Mozilla et du WEB3, de JS, de compression Zstd avec PostgreSQL, de Java et de React 18, de la série à regarder JS idiomatique… Pour enfin finir en grande musique avec Pierre et le Loup, pour s'ukrainiser civilement le neurone symphonique.

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d'anciens épisodes c'est par ici !

Timecodes & liens :

00:00:00 : Introduction et présentation de l’invité
https://twitter.com/fcamblor
https://www.bdxio.fr/
http://bordeauxjug.org/
https://vitemadose.covidtracker.fr/

00:07:00 Elastic and Amazon Reach Agreement on Trademark Infringement Lawsuit
https://www.elastic.co/blog/elastic-and-amazon-reach-agreement-on-trademark-infringement-lawsuit

00:09:44 : A new year, a new MDN
https://hacks.mozilla.org/2022/03/a-new-year-a-new-mdn/
https://en.wikipedia.org/wiki/OpenSearch

00:19:26 : Mozilla s’attaque au web3?
https://hubs.mozilla.com/

00:23:03 : Les résultats du State of JS 2021 (et début 2022 :)) sont sortis
https://2021.stateofjs.com/en-US/

00:34:17 : PostgreSQL Begins Working On Zstd Compression Support
https://www.phoronix.com/scan.php?page=news_item&px=PostgreSQL-ZStd-Start

00:38:35 : Java 18 Final RC (GA prévue le 22/03)
https://openjdk.java.net/projects/jdk/18/
https://www.loicmathieu.fr/wordpress/informatique/java-18-quoi-de-neuf/

00:47:53
React 18 va-t-il apporter (enfin!) un support des custom elements ?
https://twitter.com/dan_abramov/status/1483892375223414785
https://custom-elements-everywhere.com/

00:54:44 : React Query v4 alpha, connection mode
https://react-query.tanstack.com/

01:03:50 : La série JS Idiomatique de Delicious Insights (Christophe Porteneuve) qui reprend les bases d’un certain nombre de features EcmaScript
https://www.youtube.com/playlist?list=PLPoAfTkDs_Jad8tGdMkixD1r7lMjpRstB

01:07:20 : Le Choix musical de Frédéric Camblor : Pierre & le Loup (Sergueï Prokofiev)
https://youtu.be/eN4Iyb8HKjM?t=596

Surprise as it often happens: the report that was made on your company two months ago is going to be programmed tomorrow evening. Or, in the middle of a hot topic, your product is going to be the subject of an item during the 8 o'clock news.

The TV appearance is always a bad match for the web: because when you size your IT infrastructure, it's more to manage your growth over 3 years. On a nice upward curve, usually linear. And when the traffic peaks by 800%, your architecture will be on its knees.

Except with Clever Cloud. Configuring your applications to absorb a traffic spike can be done with a few clicks in the interface:

Only, managing site traffic is easy when you are already hosted by Clever Cloud. But if this is not the case, there is no fatality.

Yesterday, M6 broadcast the show "Who wants to be my partner? And the young company BioDemain, which helps agricultural producers during the three years of their organic transition, took part. Hosted on a traditional architecture, the risk of the service falling down is great. So we helped BioDemain migrate their site to Clever Cloud in less than 24 hours!

How Clever Cloud handles these traffic spikes

First of all, managing site traffic will be done on the Clever Cloud side by load-balancers before reaching your application. These load-balancers (formerly HAProxy instances, and now instances of Sōzu, an in-house software) are going to distribute the traffic among themselves. Just like if you had Amazon ELBs (Elastic Load Balancer), except that here it's included by default, and already configured.

Your application will then receive the traffic. Depending on your scaling configuration, your application will be able to trigger alerts to our monitoring system if CPU and RAM increase. And therefore multiply the number of instances. Load-balancers and multiple instances in a few seconds: and you are ready to handle the traffic.

The migration itself

To move to Clever Cloud so quickly, we were put in touch with the BioDemain team. And it was the formidable support organisation that was at their side to migrate their site (here a Wordpress) from a shared solution to Clever Cloud. Despite a rather… tight schedule.

The recipe for success was a very quick migration. Indeed, there are two ways to deploy your Wordpress on Clever Cloud:

• Quickly, with a simple FTP transfer.
• More elegantly, using git for the code, Cellar for the media and Composer for the plug-ins.

Obviously we went for the first solution.
After contacting the developer of BioDemain, the first step was to transfer the files between the old host and Clever.
Several tens of thousands of files, so in FTP it takes time.

While waiting for the end of the file transfer, our team and BioDemain were able to deploy two other instances: MySQL and Redis. Then came the configuration of the PHP application itself (still during the transfer).
Here we had to:

• Activate ProxySQL to mutualize the application connections
• Configure proxySQL via simple environment variables:
  • CC_ENABLE_MYSQL_PROXYSQL=true for activation
  • CC_MYSQL_PROXYSQL_MAX_CONNECTIONS =15 to set the maximum number of connections to be managed
  • CC_MYSQL_PROXYSQL_USE_TLS=true if needed
• Make a dump of the original MySQL database and import this dump into the new one
• Enable the Redis session in PHP via environment variable].

Extra tech tips

• You can also enable the Varnish built into Clever Cloud if you feel like it:
• Put in a CDN: if you don't have time to optimize your SQL queries, caching strategies, minifications etc., CDNs are there to offload some of the traffic to them.
• Before anything else, lower the TTL of your CNAME and A records of your domain name. At the time of migration, if you are short of time and the changes to the domain name are propagated over 24 hours, you will find it a shame.
• And if you ever have a down, redirect your home page to an application that displays a contact form: users can then leave an email to be contacted again.

Finally, evaluate the performance. The fateful moment of the TV pass does not suffer from a single oversight. To do this: JMeter locally (beware, it requires resources), or great online services like gatling.io

You have all the cards in hand for the next step :) Good luck!