Aurélie Vache and Stéphane Philippart attended as dit 19 other OVHcloud employees. In this blog post, they share their thoughts and feedback from this 14th edition of Devoxx France.

Devoxx France 2026: The AI Edition

Devoxx France 2026 is one of Europe’s biggest independent developer conferences. Formerly focused centrally on Java, over the past few years, the conference has also focused on Architecture, Data & Analytics, Development practices, Front-end & UX, Java/JVM, Security & Privacy, Cloud and non-technical talks about people and culture.

Key figures from the 2026 edition:

• 4,980 attendees (The largest attendance on record)
• 307 speakers
• 259 talks
• 70+ sponsors

As might be expected, AI was the central theme of this edition, with a large number of the talks focused on AI topics. Indeed, there were 65 sessions out of 259 about AI and Agentic Systems, the most discussed topic!

Notably this year, and perhaps even more than in previous years, we could clearly see attendees arriving early to secure seats for their favorite talks. Even so, there ended up being a lot of disappointment – especially on the first day – as several sessions were already at full capacity minutes before they even started.

This was particularly true for sessions featuring multiple OVHcloud speakers 💪.

Keynotes

The keynote sessions (“plenary sessions”) were also heavily centered on Artificial Intelligence, but with a notably broader lens beyond pure technology. Rather than focusing only on tools or LLM implementation, the talks explored AI through the intersecting dimensions of power, governance, cybersecurity, human transformation, and geopolitics.

Some highlights from the keynotes:

• “In 50 years, AI has multiplied its power, along with the challenges of governance and cybersecurity” – Laurence Devillers (@lau_devil)

• Jean-Gabriel Ganascia (@Quecalcoatle) questioned the promise of AI as a force that could free humans from effort, raising deeper reflections on what this means for our relationship with work and meaning.

• Loup Cellard (@CellardLoup) examined the implications of foreign investments in AI infrastructure, shedding light on the geopolitical and strategic stakes behind these technologies.

Meet & Greet

Devoxx France consists of three days of conferences, sponsor booths to discover, and Thursday evening’s unmissable annual tradition: the Meet & Greet.

Thursday night’s Meet & Greet is a major community event built around networking and social sessions like BOFs (Birds of a Feather) and seed networking. It’s one of the signature traditions of the conference, beyond talks and sponsor booths.

This evening event is free, open to the public with pre-registration, and offers a genuine moment for connection, sharing, and conversation over a drink and a plate of charcuterie and cheese 😇.

It’s also the opportunity to discover the fun of “Voxx Jam”, the community-party, music-oriented side of Devoxx/Voxxed culture 🎸.

OVHcloud Presence

At the OVHcloud booth, we were a team of 8 speakers and 11 colleagues from Tech, HR, and Sales, and their dynamic presence really made a difference. Engaging in topics like AI, Public Cloud, Domain Names, Observability, Quantum technologies, and more, we had many insightful conversations throughout the event.

We also discussed AI topics at the booth, which was of course the main theme of the conference, but not the only one.

A lot of conversations also focused on sovereignty. Three years ago, people were saying: “I don’t care about sovereignty, I’ll just choose the cheapest option.” This year, the tone has clearly changed, “How can we use your sovereign products?”

There is a real shift happening, and once again, being present at events like this is essential to witness and take part in these evolving discussions.

It was truly a top-tier booth experience for all of us💪.

Of course, the goal of our booth was so attendees could discuss with our teams, but also so we could engage them through our very own video game, “Gaming Camp: Beat Cloud Villains!”. The specially designed video game’s description: “Join the fight against the villains of the cloud. Take on Hidden Cost, Jailor Stack, and Autonomous Zero, and prove yourself as a true Guardian of the Cloud.”

Players were welcomed to step into a two-player fighting game inspired by the style of Street Fighter, where strategy and skill are your best weapons. Game on!

We also wanted to say a word about the success of our Schrödinger cat (Quantum) swag – socks, keychains, badges – they were a huge hit, and often sparked great conversations throughout the event.

OVHcloud Speakers & Talks

Getting accepted to Devoxx France is not easy, so we were proud to be included with 8 speakers and 11 talks! We were the most represented company in terms of talks at Devoxx France 2026, and ranked in the top 3 by number of speakers 💪.

Congratulations to Benoit Masson, Fanny Bouton, Mathieu Busquet, Sébastien Ferrer, Théo Bougé, and Héla Ben Khalfallah, Stéphane Philippart & Aurélie Vache for their talks 👏. A large number of attendees joined, and the sessions were all very high quality.

Find here the topics of their talks:

“Question pour un cluster Kubernetes : Quiz sur Kubernetes & ses concepts”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “The Ultimate Kubernetes Challenge: An Interactive Trivia Game on concepts, components, usage…”

🎤 Speaker: Aurélie Vache

“Kubernetes est devenu le standard de facto pour déployer et exploiter des applications conteneurisées. Nous l’utilisons, ainsi que son ecosystème, au quotidien, mais le connaît-on si bien ?

Tout au long de ce talk, avec un mix de quiz et de démos en live, vous découvrirez (ou redécouvrirez) les concepts clés de Kubernetes (pods, secrets, services, namespaces…), les composants interne mais aussi les bonnes pratiques d’utilisation.

Un format original avec un quiz, du fun et des démos, qui conviendra aussi bien aux débutants qu’aux confirmés, afin d’apprendre, réviser et challenger vos connaissances du merveilleux monde de Kubernetes et de son écosystème, tout en s’amusant.

Soyez là ou le plus rapide pour tenter de gagner des cadeaux !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 Kubernetes has become the de facto standard for deploying and operating containerized applications. We use it, as well as its ecosystem, on a daily basis, but do we know them as well as we think we do?

With a mix of quiz and live demos, come learn and/or improve your knowledge. You will discover (or rediscover) the key concepts of Kubernetes (pods, secrets, services…), internal components but also best practices.

In this fun and dynamic talk, come compete throughout the quiz and explore the wonderful world of Kubernetes.
Icing on the cake: the first will win some swags.

🎥 Replay.

“QR Codes : suivez les points sans vous perdre !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “QR codes: follow the dots without getting lost!“

🎤 Speaker: Benoît Masson & Sébastien Chedor (OnePoint)

“Les QR Codes, tout le monde connaît et les utilise régulièrement. Mais savez-vous vraiment comment ils fonctionnent, pourquoi c’est aussi rapide et fiable, même avec une caméra de faible qualité ou un code en partie caché ou détérioré ?

Nous vous proposons de coder ensemble un lecteur de QR Codes, avec un minimum d’outils :
* capture et analyse de la vidéo issue de la webcam pour détecter la position du code, à l’aide d’OpenCV
* extraction et décodage du contenu, avec correction d’erreur grâce à l’algorithme de Reed-Solomon.

À la fin de cette session, vous devriez être capables de décoder un QR Code à l’oeil nu 🕵️ (et un brouillon…)”.

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Everyone knows QR codes and uses them regularly. But do you really know how they work, and why they are so fast and reliable, even with a low-quality camera or a partially hidden or damaged code?

We propose coding a QR code reader together, using a minimum number of tools:
* capturing and analysing webcam video to detect the position of the code, using OpenCV
* extracting and decoding the content, with error correction using the Reed-Solomon algorithm

By the end of this session, you should be able to decode a QR code with the naked eye 🕵️— and a rough sheet of paper…”

🎥 Replay.

“Noms de domaines : la grande histoire des petites extensions”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Domain names: the big story behind small extensions”

🎤 Speakers: Benoît Masson & Theo Bougé

“Derrière les quelques lettres qui suivent un point (.com, .fr, .ai…) se cache un univers riche de stratégies techniques, d’enjeux géopolitiques et de batailles commerciales.

À l’approche du nouveau round de l’ICANN prévu en 2026 qui va autoriser de nouvelles extensions, il est temps de revenir sur les fondations techniques du DNS, ainsi que sur les grands épisodes de cette aventure méconnue. Des TLD historiques aux extensions détournées, des dramas autour du .web aux ambitions du Web3, nous explorerons l’évolution d’un système devenu central dans les logiques de souveraineté numérique et d’innovation commerciale.

Une plongée dans les coulisses d’un Internet en perpétuelle transformation.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Behind the few letters that follow a dot — .com, .fr, .ai and others — lies a rich world of technical strategies, geopolitical issues and commercial battles.

As the new ICANN round planned for 2026 approaches, which will authorise new extensions, it is time to revisit the technical foundations of DNS, as well as the major episodes in this little-known story. From historic TLDs to repurposed extensions, from the drama around .web to the ambitions of Web3, we will explore the evolution of a system that has become central to digital sovereignty and commercial innovation.

A deep dive behind the scenes of an Internet in constant transformation.”

🎥 Replay.

“Informatique quantique, ce coup-ci on vous dit tout !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Quantum computing: this time, we tell you everything!”

🎤 Speaker: Fanny Bouton, Olivier Ezrati (Quantum Energy Initiative) & Guillaume Schurck (Alice & Bob)

“Informatique quantique pour développeurs : comprendre, coder, passer à l’échelle

L’informatique quantique sort du laboratoire et devient progressivement accessible aux développeurs via des SDK open source, des notebooks, des simulateurs et des QPU disponibles dans le cloud. En 2026, la question n’est plus « qu’est-ce que le quantique ? » mais « comment un développeur peut-il s’en emparer concrètement ? »

Nous commencerons par poser les bases essentielles pour comprendre le modèle de calcul quantique : qubit, superposition, intrication, et ce que ces concepts impliquent pour un développeur.
Nous passerons ensuite au code : écrire et exécuter des circuits quantiques, utiliser des SDK modernes, travailler dans des notebooks, tester sur simulateur puis sur de vrais QPU. Vous verrez à quoi ressemble un workflow quantique aujourd’hui.

Enfin, nous aborderons les cas d’usage concrets, illustrés par le retour d’expérience d’un grand compte : ce qui fonctionne déjà, les limites actuelles, et comment les équipes tech expérimentent le quantique de manière réaliste et industrielle.

Une session technique pensée pour les développeurs qui veulent anticiper la prochaine évolution majeure du calcul.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Quantum computing for developers: understand, code and scale up.
Quantum computing is moving out of the laboratory and becoming progressively accessible to developers through open source SDKs, notebooks, simulators and QPUs available in the cloud. In 2026, the question is no longer ‘What is quantum?’ but ‘How can developers make practical use of it?’

We will begin by laying out the essential foundations needed to understand the quantum computing model: qubits, superposition, entanglement, and what these concepts mean for developers.

We will then move on to code: writing and running quantum circuits, using modern SDKs, working in notebooks, testing on simulators and then on real QPUs. You will see what a quantum workflow looks like today.

Finally, we will address concrete use cases, illustrated by the experience of a large account: what already works, the current limitations, and how tech teams are experimenting with quantum computing in a realistic and industrial way.

A technical session designed for developers who want to anticipate the next major evolution in computing.”

🎥 Replay.

“Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Developing with AI: what if it were as simple as adding a library?”

🎤 Speakers: Mathieu Busquet & Stéphane Philippart

“Intégrer de l’intelligence artificielle (IA) dans nos développements peut nous paraître plus complexe que de les utiliser dans notre quotidien.

Dois-je apprendre un nouveau langage ou une nouvelle stack ?
Durant ce workshop nous vous proposons de vous donner tous les éléments pour intégrer l’IA sans quitter votre langage de prédilection : Java 😍. Ce sera l’occasion de découvrir les Frameworks du moments : LangChain4j, Quarkus, …

Nous vous invitons à découvrir toutes les facettes d’un chatbot avec l’IA générative (customiser un prompt, rajouter vos données (RAG), appeler des outils locaux ou distants (MCP) et créer des agents) mais aussi parce que l’IA ne se limite pas aux chatbots : faire de la transcription, créer de l’audio ou même faire un traducteur.

Et, toujours pour vous simplifier la vie, venez juste avec votre ordinateur et un navigateur Internet, on se charge du reste pour vous construire un environnement de développement aux petits oignons grâce aux CDE.

À la suite de ce talk vous repartirez avec une boîte à outils vous permettant d’intégrer simplement la puissance des modèles d’IA au sein de vos développements de tous les jours.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Integrating artificial intelligence into our developments can seem more complex than using it in our daily lives.

Do I need to learn a new language or a new stack?

During this workshop, we will give you all the tools you need to integrate AI without leaving your favourite language: Java 😍. It will be an opportunity to discover some of today’s key frameworks, including LangChain4j and Quarkus.

We invite you to explore all the facets of a chatbot with generative AI — customising a prompt, adding your own data with RAG, calling local or remote tools with MCP, and creating agents — but also to see that AI is not limited to chatbots: it can also be used for transcription, audio creation and even translation.

And to make your life even easier, just bring your computer and an internet browser. We will take care of the rest, building a polished development environment for you thanks to CDEs.

After this talk, you will leave with a toolkit that will allow you to integrate the power of AI models into your everyday development work.”

“Détectives de la prod : résoudre l’enquête avant le crash”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Production detectives: solve the case before the crash”

🎤 Speaker: Sébastien Ferrer

“Saviez-vous que, derrière les coulisses de vos outils de travail, se cachent des équipes prêtes à intervenir à tout moment ?

Ces équipes, souvent discrètes mais essentielles, gèrent des dizaines de projets avec des effectifs réduits. Mais quand une alerte survient, elles doivent réagir vite. Très vite. Comment réussir à diagnostiquer et résoudre un incident en pleine production, sans perdre une précieuse seconde ?

Dans ce talk je vous emmène au cœur de l’action, où je partage notre méthodologie pour transformer chaque crise en une enquête méthodique et efficace. Nous explorerons comment des outils bien pensés, une organisation affûtée, et un soupçon d’intuition transforment la gestion d’incidents en une véritable enquête… parfois aussi palpitante qu’une partie de Cluedo.

Au programme : bonnes pratiques de troubleshooting, logging et monitoring, pour que vous repartiez avec des clés concrètes pour dompter les incidents dans vos propres projets.

Vous verrez qu’en production, chaque problème cache une histoire… à résoudre en équipe !”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Did you know that behind the scenes of your work tools, there are teams ready to intervene at any moment?

These teams, often discreet but essential, manage dozens of projects with limited staff. But when an alert occurs, they need to react quickly. Very quickly. How can they diagnose and resolve a production incident without losing precious seconds?

In this talk, I will take you into the heart of the action, where I share our methodology for turning every crisis into a structured and efficient investigation. We will explore how well-designed tools, a well-honed organisation and a touch of intuition can transform incident management into a real investigation — sometimes as thrilling as a game of Cluedo.

On the agenda: troubleshooting best practices, logging and monitoring, so you leave with concrete keys to taming incidents in your own projects.

You will see that in production, every problem hides a story… one to solve as a team!”

🎥 Replay.

“Et si écrire du SQL redevenait cool ?”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “What if writing SQL became cool again?”

🎤 Speaker: Sébastien Ferrer

“On nous l’a répété maintes fois : “écrire du SQL dans du code source, c’est dépassé”.

Les ORMs sont partout. Ils ont facilité notre quotidien en nous permettant de manipuler nos bases de données sans nous soucier du SQL. Mais parfois, on aimerait un peu plus de contrôle, un peu plus de performance… sans pour autant revenir aux longues heures de mapping manuel et de requêtes préparées à la main.

SQLC offre une autre approche. Initialement conçu pour du Go, langage dans lequel cette technologie sera présentée dans ce talk, il permet d’écrire des requêtes SQL tout en générant du code type-safe et performant, sans ajouter de lourdeur ni de dépendances. Pas question ici de rejeter les ORMs, mais plutôt d’explorer un nouvel outil qui vient enrichir notre palette de solutions.

Dans ce talk, nous verrons comment SQLC fonctionne, dans quels cas il brille, et comment il s’intègre parfaitement dans un stack moderne. Vous aimez le SQL ? Vous voulez juste un peu plus de maîtrise sur vos requêtes ? Venez, vous risquez d’être agréablement surpris.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “We have been told many times: ‘Writing SQL in source code is outdated.’

ORMs are everywhere. They have made our daily lives easier by allowing us to manipulate databases without worrying about SQL. But sometimes, we would like a little more control, a little more performance — without going back to long hours of manual mapping and hand-written prepared queries.

SQLC offers another approach. Initially designed for Go, the language in which this technology will be presented during the talk, it allows you to write SQL queries while generating type-safe and high-performance code, without adding heaviness or dependencies. The goal here is not to reject ORMs, but rather to explore a new tool that enriches our range of solutions.

In this talk, we will see how SQLC works, where it shines, and how it integrates perfectly into a modern stack. Do you like SQL? Do you simply want more control over your queries? Come along — you may be pleasantly surprised.”

🎥 Replay.

“🤖 Apprendre à notre IA à … apprendre 🧠”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “🤖 Teaching our AI to… learn 🧠”

🎤 Speaker: Stéphane Philippart

“RAG, MCP, tooling, function calling, agents, fine tuning, training, …
Que de termes barbares mais qui ont tous le même objectif : faire en sorte que le modèle d’intelligence artificielle que vous utilisez réponde correctement à vos questions et attentes 😅.
Et pour ça il va falloir ajouter de la connaissance, des données (privée ou publiques, …).

Durant ce talk je vous propose d’y voir un peu plus clair dans cette jungle des acronymes puis, fort de connaître les différences, vous proposer comment l’implémenter en tant que développeuses et développeurs.

Chaque approche a ses spécificités, ses avantages et ses inconvénients.
A la fin de ce talk, non seulement vous saurez choisir la bonne approche, mais aussi ajouter dans vos développements quotidiens la dose d’IA utile.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “RAG, MCP, tooling, function calling, agents, fine tuning, training…

So many intimidating terms, but they all have the same goal: ensuring that the artificial intelligence model you use responds correctly to your questions and expectations 😅.

And to do that, you need to add knowledge and data — private, public or otherwise.

During this talk, I will help you see more clearly through this jungle of acronyms, and once you understand the differences, I will show you how to implement them as developers.

Each approach has its own specificities, advantages and disadvantages.

By the end of this talk, you will not only know how to choose the right approach, but also how to add the right dose of useful AI into your daily development work.”

🎥 Replay.

“Refactorer sans tout casser: anatomie des patterns de modernisation incrémentale”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “Refactoring without breaking everything: anatomy of incremental modernisation patterns”

🎤 Speaker: Héla Ben Khalfallah

“Cette session répond à un problème extrêmement courant mais rarement traité de façon structurée : comment moderniser un système legacy sans big bang, sans freeze de la prod, et sans multiplier les régressions. Plutôt que de parler “microservices” ou “rewrite from scratch” de manière abstraite, la session propose un playbook de modernisation incrémentale, articulé autour de patterns éprouvés : Strangler Fig, Parallel Change (Expand/Contract), Branch by Abstraction, décomposition par capacités métier / sous-domaines / transactions, et les patterns de conception (Facade, Adapter, Proxy, Mediator) utilisés comme briques concrètes de migration.

Le contenu est ancré dans la pratique : il synthétise à la fois des retours d’expérience industriels (Netflix, Khan Academy, etc.) et des travaux de recherche / rédaction. L’objectif n’est pas de présenter un catalogue de patterns, mais de montrer comment les combiner pour construire une trajectoire de migration observable, réversible et livrable en continu.

Vous repartirez avec une grille de lecture concrète pour garder des migrations observables, réversibles et compatibles avec le rythme produit.”

🏴󠁧󠁢󠁥󠁮󠁧󠁿 “This session addresses an extremely common problem that is rarely handled in a structured way: how to modernise a legacy system without a big bang, without a production freeze, and without multiplying regressions. Rather than talking abstractly about microservices or rewriting from scratch, the session offers an incremental modernisation playbook built around proven patterns: Strangler Fig, Parallel Change — Expand/Contract — Branch by Abstraction, decomposition by business capabilities, subdomains and transactions, as well as design patterns such as Facade, Adapter, Proxy and Mediator used as concrete building blocks for migration.

The content is rooted in practice: it brings together both industrial feedback from companies such as Netflix and Khan Academy, and research and written work. The goal is not to present a catalogue of patterns, but to show how they can be combined to build a migration path that is observable, reversible and continuously deliverable.

You will leave with a concrete framework for keeping migrations observable, reversible and compatible with the pace of product development.”

🎥 Replay.

📺 Devoxx France published the 232 videos (keynotes, conferences, tools in action, lunch talks & deep dives) on the Devoxx France YouTube channel.

Podcast

Devoxx France was also an opportunity for OVHcloud’s Aurélie Vache, Stéphane Philippart, and Magali De Labareyre to be interviewed in the Press space for the “Tech en Pratique” podcast.

The episodes will be available on YouTube starting in September! 🙂

Key Trends

• AI moved from hype to production
  The focus shifted toward agentic systems, RAG, observability, governance, and enterprise integration, with more emphasis on shipping useful AI than experimenting.

• Java evolved for modern AI and cloud workloads
  LangChain4j, GraalVM, native image, and JDK modernization reinforced Java’s role as a serious platform for AI-enabled enterprise systems.

• Platform engineering became a core priority
  CI/CD maturity, OpenRewrite, modernization, and developer productivity all reflected one goal: faster delivery without losing control.

• Security moved deeper into developer workflows
  Shift-left security, AppSec, authorization, Software Supply Chain Security and secure-by-design approaches gained importance, especially with AI-generated code increasing governance needs.

• Cloud & architecture focused on operational resilience
  Kubernetes, containers, observability, and scalable systems remained central, with a stronger focus on practical engineering over hype.

• Front-end discussions matured
  Accessibility, performance, reactivity, and maintainability took priority over framework wars.

• Open source and European digital sovereignty gained traction
  Open models, self-hosted tooling, privacy, and vendor independence became increasingly important themes.

• Developer experience (DX) became strategic
  Tooling, automation, terminal workflows, and reducing cognitive load were seen as key drivers of productivity and competitiveness.

Conclusion

This Devoxx France edition was a raging success for the speakers, sponsors, and attendees alike ♥️.

💬 Stay in Touch

Want to chat with us, share your thoughts, or just say hi? Here’s how to get in touch with us:

• 🟣 Discord: OVHcloud Discord server
• 🐦 X / Twitter: @OVHcloud
• 💼 LinkedIn: OVHcloud LinkedIn
• 🐙 GitHub: github.com/ovh

Après avoir configuré votre serveur manuellement, pas à pas, il est temps d’automatiser tout le processus.

L’idée est simple : décrire votre infrastructure dans des fichiers de configuration et laisser Terraform s’occuper de commander les ressources chez OVHcloud.

Voici un guide d’introduction à Terraform, avec de nombreuses informations utiles : https://support.us.ovhcloud.com/hc/en-us/articles/22648864003219-Using-Terraform-with-OVHcloud.
Ainsi que le lien vers le fournisseur officiel Terraform d’OVHcloud : https://registry.terraform.io/providers/ovh/ovh/latest

Il existe deux étapes à l’automatisation du déploiement :

• déploiement de l’instance Public Cloud ;
• déploiement de la partie applicative (vscode-server) et sa configuration.

1. Le cœur de l’automatisation : le script Cloud-init

Avant de parler de Terraform, il est nécessaire de comprendre comment le serveur s’auto-configure lors de son initialisation.
Pour cela, utilisez cloud-init, un standard qui permet d’exécuter des scripts dès le premier démarrage de l’instance.

Ce que vous allez automatiser dans ce script :

• la mise à jour du système (apt update/upgrade) ;
• l’installation de code-server via le script officiel ;
• l’installation et la configuration de Caddy (pour le SSL automatique) ;
• la configuration du pare-feu UFW.

Ce type de fichier possède une syntaxe bien particulière, le cloud-config.yaml sera à disposition plus bas.

Toutefois, l’important à retenir est : pourquoi utiliser ce format ?

• Idempotence : le cloud-init s’assure que tout est prêt dès le premier boot.
• Sécurité dès la naissance : le pare-feu ufw est activé immédiatement, réduisant la fenêtre d’exposition.
• Intégration Terraform : une seule ligne est nécessaire pour l’inclure : user_data = file("cloud-config.yaml")

2. Utilisation de Terraform pour le déploiement

Terraform permet d’obtenir un démarrage de l’instance bien plus aisé et rapide.
Sa configuration, quant à elle, comporte plusieurs avantages :

• persistance des données. Un terraform destroy de l’instance pourra conserver le volume de données (but fixé dans le chapitre 2) ;
• évolutivité. Si le projet grossit, la taille du volume et/ou la flavor peuvent être modulées ;
• portabilité. Le volume de données peut être démonté et remonté sur une autre machine.

Pour garder ce billet court, pas de copier-coller de code, mais un lien vers un repository GitHub avec tout le nécessaire pour déployer ceci en quelques minutes :
https://github.com/RemyAtOVH/blogpost-dev-server

Son utilisation :

Avant l’application du cloud-init (ou sans), on constate bien un volume secondaire /dev/sdb, de taille correspondant aux spécifications de Terraform :

C’est lui qui assurera la persistance des données.

Vous pourriez tout à fait effectuer manuellement la suppression de l’instance et des autres composants, sans toutefois le supprimer lui.
Pour éviter toute suppression en cas de « terraform destroy », un paramètre a été ajouté :

Lors du premier démarrage, les différents scripts d’installation pouvant prendre du temps, vous pouvez en vérifier les étapes d’un simple tail :

Une fois le cloud-init exécuté automatiquement, tout ce qui a pu être mis en place manuellement dans les chapitres précédents a été fait. Et ce, de façon automatique et reproductible !

Il sera donc possible, sous réserve de quelques minutes d’exécution, de déployer cet environnement de développement distant personnalisé si besoin et potentiellement le supprimer après quelques heures ou jours d’utilisation.

Dans cette série de chapitres, nous avons transformé une simple idée, disposer de son VS Code partout, en une infrastructure de niveau professionnel, automatisée et résiliente.
Retrouvez ci-dessous les étapes et le chemin parcouru.

• Chapitre 1 : premiers pas en installation manuelle pour comprendre la mécanique de code-server.
• Chapitre 2 : sécurisation, avec utilisation d’un Reverse Proxy (Caddy) et d’un pare-feu (UFW) pour naviguer sereinement en HTTPS.
• Chapitre 3 : cet article, utilisant Terraform et OpenStack, pour une meilleure reproductibilité.

L’automatisation que nous avons mise en place avec un déploiement chez OVHcloud en utilisant Public Cloud reposant sur OpenStack, constitue une base solide.

À partir d’ici, il est possible d’aller encore plus loin : ajouter une sauvegarde automatique de vos volumes (snapshotting), coupler cela à un pipeline CI/CD ou même explorer le déploiement de cet environnement via docker-compose, ou même Kubernetes.

Retrouvez prochainement une version vidéo de ces billets de blog, étape par étape, sur notre chaîne YouTube. Restez à l’écoute !

After manually configuring your server step by step, it’s time to automate the entire process.

The idea is simple: describe your infrastructure in configuration files and let Terraform take care of managing the resources at OVHcloud.

Here is an introductory guide to Terraform, with plenty of useful information: https://support.us.ovhcloud.com/hc/en-us/articles/22648864003219-Using-Terraform-with-OVHcloud.
As well as the link to OVHcloud’s official Terraform provider: https://registry.terraform.io/providers/ovh/ovh/latest

There are two steps to automating the deployment:

• Deployment of the Public Cloud instance
• Deployment of the application part (vscode-server) and its configuration

1. The heart of the automation: the Cloud-init script

Before we move onto Terraform, we need to understand how the server self-configures during its initialisation.
To do this, use cloud-init, a standard that allows scripts to be executed from the first boot of the instance.

What you will automate in this script:

• The system update (apt update/upgrade)
• The installation of code-server via the official script
• The installation and configuration of Caddy (for automatic SSL)
• The configuration of the Uncomplicated Firewall (UFW)

This type of file has a very particular syntax; the cloud-config.yaml will be available further down.

However, the important point to remember is: why use this format?

• Idempotence: cloud-init ensures that everything is ready from the first boot.
• Security from the outset: the UFW is activated immediately, reducing the exposure window.
• Terraform Integration: a single line is required to include this: user_data = file("cloud-config.yaml")

2. Using Terraform for deployment

Terraform allows for a much easier and quicker instance startup.
Its configuration also has several advantages:

• Persistent data: a terraform destroy of the instance can retain the data volume (goal set in chapter 2)
• Scalability: if the project grows, the size of the volume and/or the flavour can be adjusted
• Portability: the data volume can be unmounted and remounted on another machine.

To keep this post brief we won’t copy-paste the code here, but this link to a GitHub repository contains everything needed to deploy this in a few minutes:
https://github.com/RemyAtOVH/blogpost-dev-server

Its usage:

Before applying cloud-init (or without it), there is a secondary volume /dev/sdb, sized according to Terraform specifications:

This is what will ensure data persistence.

You could manually delete the instance and other components, without deleting it.
To prevent any deletion in the event of “terraform destroy”, a parameter has been added:

During the first startup, the various installation scripts may take time. You can check their steps with a simple tail:

Once cloud-init has been executed automatically, everything that could have been set up manually in the previous chapters has been done automatically, in a way that can be reproduced!

It will therefore be possible to deploy this customised remote development environment if needed (with a few minutes of execution) and potentially delete it after a few hours or days of use.

In this series of chapters, we have transformed a simple idea – having access to VS Code wherever you are – into a professional-grade, automated and resilient infrastructure.
Below are the steps involved and the progress so far.

• Chapter 1: first steps in manual installation to understand the mechanics of code-server.
• Chapter 2: making it secure, using a Reverse Proxy (Caddy) and a firewall (UFW) to navigate smoothly in HTTPS.
• Chapter 3: this article, in which we’ll use Terraform and OpenStack for better reproducibility.

The automation we have implemented with an OVHcloud deployment using an OpenStack-based Public Cloud provides a solid foundation.

From here, you can go even further: add automatic backups of your volumes (snapshotting), couple this with a CI/CD pipeline, or even explore deploying this environment via docker-compose or even Kubernetes.

A step-by-step video version of these blog posts will soon be available on our YouTube channel. Stay tuned!

In the previous chapter, we started the VSCode Server on a remote instance.

That’s a win. However, as it stands, your installation is vulnerable, or at least not optimally secured. Traffic is being sent in clear (HTTP) and port 8080 is exposed to anyone scanning our IP address.

To transform this prototype into a daily working tool, we need to set up a Reverse Proxy.
Its role is simple: to intercept secure connections (HTTPS) on the standard port 443 and redirect them locally to our service.

1. Prerequisites: securing the network part

First and foremost, we need to instruct code-server to no longer listen for connections from outside, but only to those coming from the machine itself (the proxy).

Modify your configuration file: nano ~/.config/code-server/config.yaml

Change the line “bind-addr” as follows: 

bind-addr: 127.0.0.1:8080

Then restart the service.

This will ensure that vscode-server will indeed only “listen” locally and cannot be contacted directly from outside.

2. Implement the reverse proxy

Here, you have two choices:

• NGINX, which has been the standard choice for many years
• Caddy, which has a more simplistic (but comprehensive) and newer approach.

For this blog post, we have selected Caddy for the example and to familiarise ourselves if we have not already!

Caddy natively manages SSL certificate renewal – which can be done through OVHcloud!

Installation (Debian/Ubuntu)

You will find more comprehensive documentation for other systems or installation methods in the official documentation: https://caddyserver.com/docs/install.

Configuration: modify the file /etc/caddy/Caddyfile (clear it and replace it with this):

Replace “dev.your-domain.uk” with your own domain name, with the subdomain of your choice pointing to the IP of the instance.

• Simple configuration only on HTTP port (80)

• Recommended configuration on HTTPS port (443), using a domain hosted with OVHcloud.

For creating OVHcloud API tokens, you can refer to this page: https://eu.api.ovh.com/createToken/.

For further details regarding SSL certificate management, consult the official Caddy documentation.
Application:

If you have opted for the recommended configuration in HTTPS, your environment is now protected by robust SSL encryption.

You are no longer at risk of having your password intercepted on public Wi-Fi, which is a considerable step towards our goal.

3. Network and firewall

Now that the access point is unique via the HTTPS URL configured just above, the rest of the ports, except for SSH, can be closed.

Now, implement the basic rules in the firewall. On Ubuntu, the standard tool is UFW (Uncomplicated Firewall).

Start by opening the ports related to the functional services.

Activate the firewall:

Check the implementation of the rules.

You can also add stricter rules to explicitly reject anything unauthorised in incoming traffic while generally authorising outgoing traffic.

From now on, if someone attempts to access the IP on port 8080, the connection will be outright rejected.

Only the domain name in HTTPS is the legitimate entry point.
This handy little development server now feels more like a fortress. 

But what happens if you decide to delete this instance to move to a more powerful one and/or stop it for an indefinite period, as your project is on hold?

This is what you will find out in the next part: how to isolate your data and configurations on a persistent storage volume to make your environment completely interchangeable, but also how to automate the deploymen of this development environment!

The ultimate goal is for a simple terraform apply command to to be enough to generate a development environment that’s ready to use in under two minutes.

Dans le chapitre précédent, nous avons démarré VSCode Server sur une instance distante.

C’est une victoire. Mais en l’état, votre installation est vulnérable, ou du moins non sécurisée de façon optimale. Le trafic circule donc en clair (HTTP) et le port 8080 est exposé à quiconque scanne notre adresse IP.

Pour transformer ce prototype en un outil de travail quotidien, il est indispensable de mettre en place un Reverse Proxy.

Son rôle est simple : intercepter les connexions sécurisées (HTTPS) sur le port standard 443 et les rediriger localement vers notre service.

1. Prérequis : verrouiller la partie réseau

Avant toute chose, il est nécessaire de demander à code-server de ne plus écouter les connexions venant de l’extérieur, mais uniquement celles venant de la machine elle-même (le proxy).

Modifiez votre fichier de configuration : nano ~/.config/code-server/config.yaml

Modifiez la ligne « bind-addr » comme suit :

bind-addr: 127.0.0.1:8080

Puis redémarrez le service.

Ceci aura pour effet d’avoir la certitude que vscode-server « écoutera » bien uniquement en local et ne pourra pas être contacté directement de l’extérieur

2. Implémenter le reverse proxy

Ici, vous avez deux choix :

• nginx constitue le choix standard depuis de nombreuses années ;
• Caddy, avec une approche plus simpliste (mais complète) et récente.

Pour ce billet de blog, nous avons sélectionné Caddy pour l’exemple et se familiariser si ce n’est pas déjà le cas !

Caddy sait nativement gérer l’implémentation du renouvellement de certificats SSL. Le tout, avec OVHcloud !

Installation (Debian/Ubuntu

Vous pourrez trouver une documentation plus complète pour d’autres systèmes, ou méthodes d’installation dans la documentation officielle : https://caddyserver.com/docs/install.

Configuration : modifiez le fichier /etc/caddy/Caddyfile (videz-le et remplacez par ceci) :

Remplacez « dev.votre-domaine.fr » par votre propre nom de domaine avec le sous-domaine de votre choix pointant vers l’IP de l’instance.

• Configuration simple uniquement sur le port HTTP (80)

• Configuration recommandée sur le port HTTPS (443), en utilisant un domaine hébergé chez OVHcloud.

Pour la création des tokens API OVHcloud, vous pouvez vous référer à cette page : https://eu.api.ovh.com/createToken/.

Pour davantage de détails concernant la gestion des certificats SSL, vous pouvez consulter la documentation officielle de Caddy.
Application:

Désormais, si vous avez opté pour la configuration recommandée en HTTPS, votre environnement est protégé par un chiffrement SSL robuste.

Vous ne risquez plus de voir votre mot de passe intercepté sur un Wi-Fi public, ce qui est un pas en avant non négligeable vers notre but.

3. Réseau et pare-feu

Maintenant que le point d’accès est unique via l’URL en HTTPS configuré juste au-dessus, le reste des ports, sauf le SSH, évidemment, peut être coupé.

Implémentez maintenant les règles basiques, dans le pare-feu. Sur Ubuntu, l’outil standard est UFW (Uncomplicated Firewall).

Commencez par ouvrir les ports relatifs aux services fonctionnels.

Activez le firewall :

Vérification de la prise en compte des règles.

Vous pouvez également ajouter des règles plus strictes pour rejeter explicitement tout ce qui n’est pas autorisé en entrée et laisser la sortie globalement autorisée.

Désormais, si quelqu’un tente d’accéder à l’IP sur le port 8080, la connexion sera purement et simplement rejetée.

Seul le nom de domaine en HTTPS constitue la porte d’entrée légitime.
Ce petit serveur de développement, bien pratique, ressemble désormais davantage à une forteresse. 

Mais que se passe-t-il si vous décidez de supprimer cette instance pour en prendre une plus puissante et/ou la stopper pour une durée indéterminée, car votre projet est en pause ?

C’est ce que vous découvrirez dans la prochaine partie : comment isoler vos données et vos configurations sur un volume de stockage persistant pour rendre votre environnement totalement interchangeable, mais également comment automatiser le déploiement de cet environnement de développement !

L’objectif final : qu’une simple commande terraform apply suffise à faire surgir un environnement de développement, prêt à l’emploi en moins de deux minutes.

Un environnement de développement est indispensable au quotidien, mais il peut vite devenir complexe à gérer. Nous allons voir ensemble, dans un billet de blog en 3 parties, comment améliorer son confort et sa productivité !

Réunions incessantes, environnements Docker différant légèrement sur chaque machine, mises à jour système intempestives : garder un poste de développement fiable et cohérent devient vite un combat quotidien.

À chaque nouveau projet, il faut ré-installer les mêmes outils, les mêmes CLI, reconfigurer les mêmes SDK ou frameworks. Et surtout, espérer que la machine locale tienne la charge quand les tests, le linter et la base de données fonctionnent en même temps. Le tout, avec des situations de télétravail ou de mobilité dans lesquelles les personnes se retrouvent à développer depuis un ordinateur portable parfois proche de l’obsolescence, derrière un VPN capricieux.

Dans cette série d’articles, l’objectif est de transformer cette réalité en s’appuyant sur un environnement de développement complet hébergé dans le cloud et accessible depuis n’importe quel navigateur grâce à VS Code Server.

L’idée est de disposer d’une « station de travail » distante, puissante et, si besoin, reproductible et indépendante.

Ce premier chapitre montre comment déployer simplement et manuellement une instance Public Cloud et y installer VS Code Server. Les chapitres suivants traiteront de sa sécurisation et de son automatisation.  

1. Déploiement de l’instance

Pour les premiers tests, afin de prendre en main l’environnement et de le tester, il peut s’avérer judicieux d’opter pour une instance assez modeste, de type Discovery. Une instance d2-2 sera ici utilisée. 1vCPU et 2 Go de RAM peuvent être suffisants.

2. Installation de la partie applicative

La source de vérité pour les étapes suivantes est le GitHub du projet vscode-server : https://github.com/coder/code-server

Plusieurs possibilités existent pour l’installation. Dans ce chapitre, pour simplifier le déploiement et pour les personnes peu habituées à Docker, l’installation se fera via le script d’installation « natif », sans utiliser de conteneurs.

Cette étape suffit à installer le nécessaire. Activez maintenant le service et vérifiez son bon fonctionnement.

3. Validation de la configuration

À ce stade, le service est opérationnel, il reste à en finaliser la configuration, notamment la création du dossier qui contiendra le code ainsi que l’authentification.

Il est ici nécessaire de placer un mot de passe sécurisé et de vérifier que la bind-addr correspond à la configuration souhaitée.

Si vous souhaitez tester directement le service en l’état, utilisez 0.0.0.0:8080. Relancez ensuite le service et accédez à l’interface via http://<IP_PUBLIQUE>:8080.

Après avoir fourni dans la fenêtre d’authentification le mot de passe présent dans le config.yaml, vous accédez directement à VS Code dans le navigateur.

Partant de ce déploiement, vous pouvez donc ici répondre, partiellement en l’état, à la problématique d’un environnement de développement stable.

À ce stade, il est possible de cloner directement vos repositories GitHub ou d’utiliser le dossier workspace pour les cloner.

C’est d’ailleurs ce qui est recommandé pour davantage de pérennité, comme vous pourrez le voir dans le second chapitre.

Pour réaliser un commit de test via l’interface vscode-server, vous devez configurer git en local (juste une fois) pour que l’authentification du remote repository s’effectue correctement.

Dès cette étape, vous pouvez utiliser l’environnement de développement distant avec vscode-server. Et ce, en profitant de quasiment toutes les fonctionnalités dont vous pourriez disposer en local, mais avec les avantages d’un environnement dédié à cet usage.

⚠️ Rappel : en l’état, le déploiement fait ici n’est pas en statut « production ready » !

Le but de ce premier chapitre est de découvrir le service, les manipulations vous étant proposées pour vous permettre de vous familiariser avec l’environnement. Ainsi, veillez à ne pas opérer le service tel que déployé ici plus que quelques heures !

Il sera nécessaire de sécuriser l’environnement, puisqu’il est exposé directement sur Internet. C’est l’objet des chapitres suivants.

Ce premier chapitre se termine avec un environnement de développement opérationnel, déjà capable de supporter un vrai projet applicatif !

L’instance est en ligne, VS Code Server répond dans le navigateur, l’espace de travail est prêt et le premier dépôt a été cloné et ouvert comme sur un poste local. Cette base montre qu’il est possible de s’abstraire du matériel pour gagner en portabilité et partager plus facilement une configuration commune au sein d’une équipe ou d’un poste de développement nomade.

Dans les prochains chapitres, cet environnement au minimum viable sera progressivement renforcé avec du stockage persistant, des mécanismes de sauvegarde ainsi qu’un accès sécurisé en HTTPS. Il sera ensuite entièrement automatisé via de l’Infrastructure as Code, afin de passer d’un simple test technique à une véritable plateforme de développement prête pour la production interne.

If you find yourself in need of shared persistent storage for applications running on OVHcloud Managed Kubernetes Service (MKS), then OVHcloud Enterprise File Storage (EFS) with Trident CSI offers you a practical way to provision and manage it.

This blog post explains how to create and connect OVHcloud EFS to your MKS cluster using Trident CSI, so you can dynamically provision persistent storage for Kubernetes workloads.

OVHcloud Enterprise File System (EFS)

EFS is a high-performance, fully managed file storage solution powered by NetApp ONTAP in an active-active architecture. It is designed for enterprise workloads requiring high availability, predictable performance, and seamless integration with cloud-native environments.

The service is available in multiple regions, including Roubaix, Gravelines, Strasbourg, Limbourg, and Beauharnois, with a strong SLA of 99.99% uptime. Storage capacity ranges from 50 GB up to 29 TB.

EFS delivers guaranteed performance with 4,000 IOPS and 64 MB/s throughput per TiB, scaling linearly with volume size thanks to NVMe SSD infrastructure.

Built for modern infrastructures, EFS integrates natively with Kubernetes via Trident CSI (compatible with MKS) and supports ReadWriteMany (RWX) access. It operates within a single availability zone (1AZ) and provides low-latency NFS storage over OVHcloud’s secure vRack network, ensuring strong security and compliance.

NetApp Trident CSI

Trident is an open-source, fully supported storage orchestration project maintained by NetApp. It is designed to help Kubernetes applications consume persistent storage using standard interfaces such as the Container Storage Interface (CSI).

Trident runs directly inside Kubernetes clusters as a set of Pods and enables dynamic provisioning and management of storage for containerized workloads. It allows applications to easily access persistent storage from NetApp’s ecosystem, including ONTAP systems (like the OVHcloud EFS).

Let’s do it!

EFS creation

We already have a MKS cluster, in GRA11 region, running inside a private network and a subnet, with a gateway.
We also already have a vRack and our Public Cloud Project attached to this vRack.
So in this blog post we will only create a new EFS in eu-west-rbx region, attached to a vRackServices, inside the same subnet that our existing MKS cluster.

Here you can see the architecture of all the services:

⚠️ EFS and MKS regions may differ; be aware that latency between different regions may impact your storage workloads performance. It’s highly recommended to keep your storage and compute as close as possible.

We will deploy the EFS in eu-west-rbx instead of in eu-west-gra region to show you that it is possible.

To deploy the EFS, we will use the Terraform OVHcloud EFS module.

The module we will use can deploy all the components necessary to use EFS with a MKS cluster (like you can see in the schema).

But in this blog post we will assume that we already deployed:

• a vRack
• a Private Network
• a Private Subnet
• a Gateway
• a MKS cluster

So using the Terraform module we will fill the existing resources information and ask Terraform to create:

• an OAuth2 credential
• an IAM policy
• an EFS
• a vRack Services

Let’s deploy our components with Terraform!

Create a provider.tf file and fill it with the information:

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = ">= 2.12.0"
    }
    null = {
      source  = "hashicorp/null"
      version = ">= 3.0.0"
    }
  }

  required_version = ">= 1.7.0"
}

provider "ovh" {
}

If you don’t define the provider information inside this file, as was shown in this example, you can instead set the environment variables with your credentials:

# OVHcloud provider needed keys
export OVH_ENDPOINT="ovh-eu"
export OVH_APPLICATION_KEY="xxx"
export OVH_APPLICATION_SECRET="xxx"
export OVH_CONSUMER_KEY="xxx"
export OVH_CLOUD_PROJECT_SERVICE="xxx"

Create a variable.tf.template file and fill it with these information:

# Existing services
variable "service_name" {
  default = "$OVH_CLOUD_PROJECT_SERVICE"
}

variable "vrack_id" {
  default = "pn-1234567" #ID of your existing vRack
}

variable "vlan_id" {
  default = "666" #ID of your VLAN
}

variable "private_network_id" {
  default = "d111cb65-1234-5678-9012-dac2e93b8944" #ID of your private network
}

variable "private_subnet_id" {
  default = "d8dc2469-1234-5678-9012-1f86551d3466" #ID of your subnet
}

variable "vrackservices_subnet_service_range_cidr" {
  default = "192.168.168.248/29" #CIDR of your private network
}

variable "private_subnet_cidr" {
  default = "192.168.168.0/24" #CIDR of your subnet
} 

variable "mks_region" {
  default = "GRA11" #Region of your existing MKS cluster
}

variable "mks_cluster_id" {
  default = "7c3e1e6e-1234-5678-9012-4fb5a5b145e7" #ID of your existing MKS cluster
}

# Services to create

variable "oauth2_client_name" {
  default = "efs-trident-client-example"
}

variable "oauth2_client_description" {
  default = "OAuth2 client for EFS Trident integration"
}

variable "iam_policy_name" {
  default = "efs-trident-policy-example"
}

variable "iam_policy_description" {
  default = "IAM policy for EFS Trident access"
}

variable "vrackservices_attach_to_efs" {
  description = "Whether to attach the EFS service endpoint to vRack Services. Set to false before destroying."
  type        = bool
  default     = true
}

variable "efs_region" {
  default = "eu-west-rbx"
}

variable "efs_name" {
  default = "my-efs-storage"
}

variable "efs_plan" {
  default = "enterprise-file-storage-premium-1tb"
}

⚠️ In the file, replace the IDs, CIDR & MKS region with your existing resources information.

Replace the value of the OVH_CLOUD_PROJECT_SERVICE environment variable in the variables.tf file:

envsubst < variables.tf.template > variables.tf

Create a efs.tf file and fill it with the information:

module "ovh_efs_trident" {
  source = "ovh/efs/ovh//modules/efs-trident"

  # OVH region for EFS and vRack Services
  region = var.efs_region

  # Public Cloud region for MKS and private network
  public_cloud_region = var.mks_region

  # VLAN ID must be the same for vRack Services and Public Cloud private network
  vlan_id = var.vlan_id

  # Set to false before destroying to detach endpoint first
  vrackservices_attach_to_efs = var.vrackservices_attach_to_efs

  # EFS creation
  storage_efs_name      = var.efs_name
  storage_efs_plan_code = var.efs_plan

  # --- vRack ---
  create_vrack       = false
  vrack_service_name = var.vrack_id

  # --- Cloud Project ---
  create_cloud_project        = false
  cloud_project_id            = var.service_name
  bind_vrack_to_cloud_project = false # Set to false if already bound

  # --- Private Network ---
  create_private_network      = false
  private_network_id = var.private_network_id

  # --- Private Subnet ---
  create_private_subnet      = false
  private_subnet_id = var.private_subnet_id

  # --- Gateway ---
  create_gateway = false  # Set to false only if existing network has gateway

  # --- MKS Cluster ---
  create_mks_cluster = false
  mks_cluster_id     = var.mks_cluster_id # mks-priv-gra11
  create_node_pool   = false # Set to false if using existing node pool

  # OAuth2 and IAM
  oauth2_client_name        = var.oauth2_client_name
  oauth2_client_description = var.oauth2_client_description
  iam_policy_name           = var.iam_policy_name
  iam_policy_description    = var.iam_policy_description

  # Network (shared between vRack Services and Public Cloud)
  private_network_subnet_cidr             = var.private_subnet_cidr
  vrackservices_subnet_service_range_cidr = var.vrackservices_subnet_service_range_cidr # EFS gets IPs here
}

Create an output.tf file with the following content:

output "client_id" {
    value = module.ovh_efs_trident.client_id
}

output "client_secret" {
    value = module.ovh_efs_trident.client_secret
    sensitive = true
}

output "efs_id" {
  value       = module.ovh_efs_trident.efs_id
}

The Terraform configuration is ready. Let’s init it:

terraform init

The output should be like this:

$ terraform init

Initializing the backend...
Initializing modules...
Initializing provider plugins...
- Reusing previous version of hashicorp/null from the dependency lock file
- Reusing previous version of ovh/ovh from the dependency lock file
- Using previously-installed hashicorp/null v3.2.4
- Using previously-installed ovh/ovh v2.13.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Apply it:

terraform apply

The output should be like this:

$ terraform apply

module.ovh_efs_trident.data.ovh_me.my_account: Reading...
module.ovh_efs_trident.data.ovh_cloud_project_kube.existing[0]: Reading...
module.ovh_efs_trident.data.ovh_cloud_project.existing[0]: Reading...
module.ovh_efs_trident.data.ovh_me.my_account: Read complete after 1s [id=xx12345-ovh]
module.ovh_efs_trident.data.ovh_cloud_project.existing[0]: Read complete after 0s
module.ovh_efs_trident.data.ovh_order_cart.cart: Reading...
module.ovh_efs_trident.data.ovh_order_cart.cart: Read complete after 0s [id=d582ab7c-1234-5678-9012-4a6e702ea4c5]
module.ovh_efs_trident.data.ovh_cloud_project_kube.existing[0]: Read complete after 5s [id=7c3e1e6e-1234-5678-9012-4fb5a5b145e7]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # module.ovh_efs_trident.null_resource.config_validation will be created
  + resource "null_resource" "config_validation" {
      + id = (known after apply)
    }

  # module.ovh_efs_trident.ovh_iam_policy.iam_policy will be created
  + resource "ovh_iam_policy" "iam_policy" {
      + allow       = [
          + "storageNetApp:apiovh:get",
          + "storageNetApp:apiovh:serviceInfos/get",
          + "storageNetApp:apiovh:share/accessPath/get",
          + "storageNetApp:apiovh:share/acl/create",
          + "storageNetApp:apiovh:share/acl/delete",
          + "storageNetApp:apiovh:share/acl/get",
          + "storageNetApp:apiovh:share/create",
          + "storageNetApp:apiovh:share/delete",
          + "storageNetApp:apiovh:share/edit",
          + "storageNetApp:apiovh:share/extend",
          + "storageNetApp:apiovh:share/get",
          + "storageNetApp:apiovh:share/revertToSnapshot",
          + "storageNetApp:apiovh:share/snapshot/create",
          + "storageNetApp:apiovh:share/snapshot/delete",
          + "storageNetApp:apiovh:share/snapshot/edit",
          + "storageNetApp:apiovh:share/snapshot/get",
        ]
      + created_at  = (known after apply)
      + description = "IAM policy for EFS Trident access"
      + id          = (known after apply)
      + identities  = (known after apply)
      + name        = "efs-trident-policy-example"
      + owner       = (known after apply)
      + read_only   = (known after apply)
      + resources   = (known after apply)
      + updated_at  = (known after apply)
    }

  # module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client will be created
  + resource "ovh_me_api_oauth2_client" "api_oauth2_client" {
      + client_id     = (known after apply)
      + client_secret = (sensitive value)
      + description   = "OAuth2 client for EFS Trident integration"
      + flow          = "CLIENT_CREDENTIALS"
      + id            = (known after apply)
      + identity      = (known after apply)
      + name          = "efs-trident-client-example"
    }

  # module.ovh_efs_trident.ovh_storage_efs.efs[0] will be created
  + resource "ovh_storage_efs" "efs" {
      + created_at        = (known after apply)
      + iam               = (known after apply)
      + id                = (known after apply)
      + name              = "my-efs-storage"
      + order             = (known after apply)
      + ovh_subsidiary    = "FR"
      + performance_level = (known after apply)
      + plan              = [
          + {
              + configuration = [
                  + {
                      + label = "region"
                      + value = "eu-west-rbx"
                    },
                  + {
                      + label = "network"
                      + value = "vrack"
                    },
                ]
              + duration      = "P1M"
              + plan_code     = "enterprise-file-storage-premium-1tb"
              + pricing_mode  = "default"
            },
        ]
      + product           = (known after apply)
      + quota             = (known after apply)
      + region            = (known after apply)
      + service_name      = (known after apply)
      + status            = (known after apply)
    }

  # module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0] will be created
  + resource "ovh_vrack_vrackservices" "vrack-vrackservices-binding" {
      + id             = (known after apply)
      + service_name   = "pn-1234567"
      + vrack_services = (known after apply)
    }

  # module.ovh_efs_trident.ovh_vrackservices.vrackservices[0] will be created
  + resource "ovh_vrackservices" "vrackservices" {
      + checksum        = (known after apply)
      + created_at      = (known after apply)
      + current_state   = (known after apply)
      + current_tasks   = (known after apply)
      + iam             = (known after apply)
      + id              = (known after apply)
      + order           = (known after apply)
      + ovh_subsidiary  = "FR"
      + plan            = [
          + {
              + configuration = [
                  + {
                      + label = "region_name"
                      + value = "eu-west-rbx"
                    },
                ]
              + duration      = "P1M"
              + plan_code     = "vrack-services"
              + pricing_mode  = "default"
            },
        ]
      + resource_status = (known after apply)
      + target_spec     = {
          + subnets = [
              + {
                  + cidr              = "192.168.168.0/24"
                  + service_endpoints = [
                      + {
                          + managed_service_urn = (known after apply)
                        },
                    ]
                  + service_range     = {
                      + cidr = "192.168.168.248/29"
                    }
                  + vlan              = 666
                    # (1 unchanged attribute hidden)
                },
            ]
        }
      + updated_at      = (known after apply)
    }

Plan: 6 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + client_id     = (known after apply)
  + client_secret = (sensitive value)
  + efs_id        = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.ovh_efs_trident.null_resource.config_validation: Creating...
module.ovh_efs_trident.null_resource.config_validation: Creation complete after 0s [id=8553589333890826101]
module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client: Creating...
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Creating...
module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client: Creation complete after 0s [id=EU.xxxxxxxxxxxxx]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m20s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m30s elapsed]
...
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [03m40s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [03m50s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Creation complete after 3m52s [id=c2d759de-cd63-4e28-aaab-a7599aad2ca8]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Creating...
module.ovh_efs_trident.ovh_iam_policy.iam_policy: Creating...
module.ovh_efs_trident.ovh_iam_policy.iam_policy: Creation complete after 0s [id=a434d1a4-1234-5678-9012-cf54251eee52]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [00m20s elapsed]
...
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [01m20s elapsed]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Creation complete after 1m30s [id=vrs-a00-b11-c22-d33]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Creating...
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [00m20s elapsed]
...
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [01m40s elapsed]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Creation complete after 1m43s [id=vrack_pn-1234567-vrackServices_vrs-a00-b11-c22-d33]

Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

Outputs:

client_id = "EU.xxxxxxxxxxxxx"
client_secret = <sensitive>
efs_id = "c2d759de-cd63-4e28-aaab-a7599aad2ca8"

Save the OAuth2 credentials in environment variables:

export EFS_CLIENT_ID=$(terraform output -raw client_id)
export EFS_CLIENT_SECRET=$(terraform output -raw client_secret)

Trident CSI Installation

Install the Trident operator in your MKS cluster:

helm repo add netapp-trident https://netapp.github.io/trident-helm-chart

helm install trident-operator netapp-trident/trident-operator \
  --version 100.2502.1 \
  --create-namespace \
  --namespace trident \
  --set tridentSilenceAutosupport=true \
  --set operatorImage="ovhcom/trident-operator:25.02.1-linux-amd64" \
  --set tridentImage="ovhcom/trident:25.02.1-linux-amd64"

You should have a result like this:

$ helm install trident-operator netapp-trident/trident-operator \
  --version 100.2502.1 \
  --create-namespace \
  --namespace trident \
  --set tridentSilenceAutosupport=true \
  --set operatorImage="ovhcom/trident-operator:25.02.1-linux-amd64" \
  --set tridentImage="ovhcom/trident:25.02.1-linux-amd64"

NAME: trident-operator
LAST DEPLOYED: Tue Apr 28 14:01:19 2026
NAMESPACE: trident
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing trident-operator, which will deploy and manage NetApp's Trident CSI
storage provisioner for Kubernetes.

Your release is named 'trident-operator' and is installed into the 'trident' namespace.
Please note that there must be only one instance of Trident (and trident-operator) in a Kubernetes cluster.

To configure Trident to manage storage resources, you will need a copy of tridentctl, which is
available in pre-packaged Trident releases.  You may find all Trident releases and source code
online at https://github.com/NetApp/trident.

To learn more about the release, try:

  $ helm status trident-operator
  $ helm get all trident-operator

Once the installation is complete, verify that all Trident pods are in Running state in the trident namespace before proceeding:

$ kubectl get pods -n trident

NAME                                  READY   STATUS    RESTARTS      AGE
trident-controller-5bf6c8d6f6-g95jq   6/6     Running   0             119s
trident-node-linux-4xtjr              2/2     Running   1 (82s ago)   119s
trident-node-linux-6w5ff              2/2     Running   1 (82s ago)   119s
trident-node-linux-r7hxp              2/2     Running   0             119s
trident-operator-859f59c58b-2z2ts     1/1     Running   0             2m31s

Trident Backend Creation

The Trident backend connects NetApp Trident to the OVHcloud EFS service using the IAM credentials previously created.

1. Secret Creation

Create a Kubernetes Secret containing the connection information that allows Trident to access the OVHcloud API. Create a trident-secret.yaml.template file with the following content:

apiVersion: v1
kind: Secret
metadata:
  name: ovh-efs-secret
type: Opaque
stringData:
  clientID: "$EFS_CLIENT_ID"         # your clientId
  clientSecret: "$EFS_CLIENT_SECRET" # your clientSecret

Replace the clientID and clientSecret values by the OAuth2 client we created with Terraform:

envsubst < trident-secret.yaml.template > trident-secret.yaml

Apply the secret in your cluster:

kubectl apply -f trident-secret.yaml -n trident

Check that the secret has been correctly created:

$ kubectl get secret ovh-efs-secret -n trident

NAME             TYPE     DATA   AGE
ovh-efs-secret   Opaque   2      3s

2. Trident Backend Creation

Create your backend with the command below:

cat <<EOF | kubectl create -n trident -f -
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ovh-efs-rbx
spec:
  version: 1
  backendName: backend-ovh-efs
  defaults:
    exportRule: "192.168.168.0/24"    # CIDR of your network for NFS ACLs
  storageDriverName: ovh-efs
  clientLocation: ovh-eu
  location: eu-west-rbx         # Location of your EFS service
  serviceLevel: premium
  nfsMountOptions: rw,hard,rsize=65536,wsize=65536,nfsvers=3,tcp
  credentials:
    name: ovh-efs-secret
  volumeCreateTimeout: "60" 
EOF

⚠️ The ovh-efs storage driver must be used. Replace exportRule, location, and other parameters with values matching your environment.

Verify that the backend has been created correctly with the command below:

$ kubectl get TridentBackendConfig -n trident

NAME          BACKEND NAME      BACKEND UUID                           PHASE   STATUS
ovh-efs-rbx   backend-ovh-efs   ace12d67-70ea-44e1-abd8-20d016f7f030   Bound   Success

Use EFS in your MKS cluster

This section describes how to expose Enterprise File Storage to Kubernetes workloads using Trident.

1. StorageClass

In a sc_efs.yaml file, define a StorageClass to enable dynamic provisioning via the Trident CSI driver:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ovh-efs-premium
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ovh-efs"
  fsType: "nfs"
allowVolumeExpansion: true

Apply the StorageClass:

kubectl apply -f sc_efs.yaml

Check that the StorageClass has been created:

$ kubectl get sc ovh-efs-premium

NAME              PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ovh-efs-premium   csi.trident.netapp.io   Delete          Immediate           true                   3h13m

This StorageClass allows volumes to be provisioned on demand and expanded dynamically.

2. Volume Creation (PVC)

Create a PersistentVolumeClaim with ReadWriteMany (RWX) access mode. Create a pvc_efs.yaml file with this content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: premium-pvc-efs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: ovh-efs-premium

Apply it:

kubectl apply -f pvc_efs.yaml

Verify that the PVC has been created with the command below:

kubectl get pvc premium-pvc-efs

At this point, the EFS is creating a volume, attach the correct ACL to it and mount it in the PVC

After a little time, the output should show the PVC in Bound state:

$ kubectl get pvc

NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
premium-pvc-efs   Bound    pvc-faca364d-ad76-44ec-9bc9-959c0d33c515   100Gi      RWX            ovh-efs-premium   <unset>                 3m43s

The volume has been created through the PVC and you can now mount it in a Pod 🎉.

Conclusion

In this blog, we’ve explained how to create an EFS and use it in a MKS cluster through Trident CSI. This will give you a flexible, production-ready approach to persistent shared storage in Kubernetes.

We recommend you also take a look at our Cloud Roadmap & Changelog for an overview of all the coming features for OVHcloud Public Cloud products.

• 👤 Invitée : Thierry CHANTIER
  • Bluesky : @titimoby
  • LinkedIn : https://www.linkedin.com/in/thierrychantier/
• 🗓️ Date d’enregistrement : 30 avril 2026
• 🎧 Lien vers l’épisode

👤 Présentation de Thierry – ⏱️ 1″15s

• https://mixteen.org/
• https://www.ingenieuses.fr/
• https://tontoncodeur.fr/
• https://www.emaxilde.net/#reseaux
• https://techcafe.fr/
• https://lescastcodeurs.com/

📰 News Techs 

🤖 Intelligence Artificielle – ⏱️ 43″35s

Anthropic Claude Code leak

https://www.reddit.com/r/ClaudeAI/comments/1s9d9j9/claude_code_source_leak_megathread/

Qwen 3.6

• https://openrouter.ai/compare/qwen/qwen3.6-plus/anthropic/claude-sonnet-4.6
• https://rits.shanghai.nyu.edu/ai/qwen3-6-27b-a-dense-27b-model-that-beats-a-397b-moe-on-coding/

Quantization from the ground up

https://ngrok.com/blog/quantization

MCP is dead. Long live the CLI

https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

👩‍💻 Développement – ⏱️ 1h07″26s

Thoughts on OpenAI acquiring Astral and uv/ruff/ty

https://simonwillison.net/2026/Mar/19/openai-acquiring-astral

SpaceX is working with Cursor and has an option to buy the startup for $60B

https://techcrunch.com/2026/04/21/spacex-is-working-with-cursor-and-has-an-option-to-buy-the-startup-for-60-billion/

☁️ Cloud – ⏱️ 1h15″15s

OVHcloud Kubernetes Review: Europe’s Quiet Powerhouse

https://www.eucloudcost.com/blog/ovhcloud-cluster

Discovering the External Secrets Operator (ESO) OVHcloud provider to manage your Kubernetes secrets

https://blog.ovhcloud.com/discover-the-external-secret-operator-eso-ovhcloud-provider-to-manage-your-kubernetes-secrets-%f0%9f%8e%89/

Secure your Software Supply Chain with OVHcloud Managed Private Registry (MPR)

https://blog.ovhcloud.com/secure-your-software-supply-chain-with-ovhcloud-managed-private-registry-mpr/

🎤 Conférences / meetup – ⏱️ 1h21″25s

https://developers.events/

Le prochain Riviera Dev

https://www.rivieradev.fr

💡 Retrouvez l’ensemble des autres épisodes ici : https://smartlink.ausha.co/tranches-de-tech 💡

A development environment is an essential day-to-day system, but it can quickly become complex to manage. In this three-part blog post, we will explore how to become more comfortable and productive with it!

Endless meetings, slightly differing Docker environments on each machine, and untimely system updates: maintaining a reliable and consistent development workstation can quickly become a daily struggle.

With each new project, you have to reinstall the same tools, the same CLIs, and reconfigure the same SDKs or frameworks. And above all, hope that the local machine can handle the load when tests, the linter, and the database are all running simultaneously. Meanwhile, with remote work or working while travelling, individuals find themselves developing with a temperamental VPN, from a laptop that is sometimes close to obsolescence.

In this series of articles, we aim to transform this reality by building on a complete development environment hosted in the cloud and accessible from any browser via VS Code Server.

The idea is to have a remote, powerful, and, if necessary, reproducible and independent “workstation”.

This first chapter demonstrates how to easily deploy a Public Cloud instance manually and install VS Code Server on it. The following chapters will improve its security and automation.  

1. Deploying the instance

For the initial tests it may be wise to opt for a smaller, Discovery-type instance so that you can familiarise yourself with the environment and test it. A d2-2 instance will be used here. 1 vCPU and 2 GB of RAM should be enough.

2. Installing the application element

The fountain of knowledge for the following steps is the GitHub for the vscode-server project: https://github.com/coder/code-server

There are several options for the installation. In this chapter, to simplify the deployment and for those who are not very familiar with Docker, the installation will be done via the “native” installation script, without using containers.

This step is enough to install the essentials. Activate the service now and check that it is running correctly.

3. Validate the configuration

At this stage, the service is operational; the configuration still needs to be finalised, particularly creating the folder that will contain the code as well as the authentication.

You need to set a secure password here and verify that the bind-addr corresponds to your desired configuration.

If you wish to directly test the service in its current state, use 0.0.0.0:8080. Then restart the service and access the interface via http://<IP_PUBLIQUE>:8080.

After providing the password found in the config.yaml in the authentication window, you will gain direct access to VS Code in the browser.

From this deployment, you can then partially address the issue of getting a stable development environment.

At this stage, it is possible to directly clone your GitHub repositories or to use the workspace folder to clone them.
This is recommended for greater longevity, as you will see in the second chapter.

To perform a test commit via the vscode-server interface, you must configure git locally (just once) so that the authentication of the remote repository runs correctly.

From this step onwards, you can use the remote development environment with vscode-server, while enjoying nearly all the features you might have locally, but with the advantages of having an environment dedicated to this use.

⚠️ Reminder: in its current state, the deployment made here is not “production ready”!

The aim of this first chapter is to introduce the service, with the instructions here to help you familiarize yourself with the environment. Therefore, please ensure that you do not operate the service as deployed here for more than a few hours!

The environment will need to be secured, as it is directly exposed on the Internet. We’ll talk about this in the following chapters.

By now, you have an operational development environment that is already capable of supporting a real application project!

The instance is online, VS Code Server is responding in the browser, the workspace is ready, and the first repository has been cloned and opened as if on a local machine. This foundation demonstrates that it is possible to abstract from the hardware to gain portability and more easily share a common configuration within a team or a remote development workstation.

In the upcoming chapters, this minimum viable environment will be gradually enhanced with persistent storage, backup mechanisms, and secure access via HTTPS. It will then be fully automated through Infrastructure as Code, in order to transition from a simple technical test to a genuine development platform ready for internal production.

For IT leaders, the important question is not whether blockchain is “the next big thing.” 

The question is actually much simpler: where and how does this technology solve real problems better than conventional architectures?

To answer that, let’s begin with the fundamentals.

What blockchain really is, and how it works

A blockchain is a distributed database made up of blocks of data linked together in chronological order. Each new block contains information about transactions or events, along with a cryptographic reference to the previous block. This creates an auditable chain of records that is extremely difficult to alter retrospectively.

Unlike a traditional database, which is generally administered by one organisation, a blockchain is maintained collectively by participants in the network. Copies of the ledger are distributed across multiple systems, helping to ensure synchronisation, resilience and transparency.

When a transaction is submitted to a blockchain network, it is checked according to the rules of that network. Once validated, it is added to a block and propagated across the network so that participants agree on the updated state of the ledger. This agreement process is known as consensus.

The result is a system designed to support tamper-resistant, highly available and traceable record-keeping.

Public, private, permissioned and permissionless blockchains

Not all blockchains work in the same way. For business leaders, one of the most important distinctions is the difference between public and private networks, and between permissioned and permissionless models.

Public blockchains are open networks. In general, anyone can access them, and they are often designed for broad transparency and participation. These networks are especially relevant where openness, interoperability and shared trust are important.

Private blockchains are restricted to a specific organisation or group of participants. They are usually designed for tightly controlled business processes, where governance, confidentiality or performance requirements call for more control.

A second distinction concerns permissions.

In a permissionless blockchain, participants can typically join the network and interact with it without prior approval, provided they follow the network’s technical rules.

In a permissioned blockchain, roles and actions are controlled more tightly. Specific participants may be allowed to read, write, validate or administer the network based on predefined permissions.

These models are not interchangeable. The right choice depends on the use case, the governance model, the sensitivity of the data, and the degree of openness required.

How infrastructure factors in

Blockchain discussions often focus on tokens, protocols or applications. But for IT decision-makers, infrastructure is just as important.

A blockchain environment depends on reliable underlying systems to ensure performance and trust. Three requirements stand out in particular: security, speed and uptime.

1. Security

Security is indispensably foundational. Blockchain networks are designed to preserve data integrity, but they still need to be protected at the infrastructure and operational levels.

This includes safeguarding validator or node environments, protecting sensitive data during processing, enforcing strict identity and access controls, and defending services against network attacks such as DDoS events. In some blockchain contexts, security solutions must also be tailored carefully so that legitimate high-volume traffic is not mistaken for malicious traffic.

2. Speed and low latency

Many blockchain applications are highly sensitive to latency. Validation, data propagation and user-facing responsiveness all depend on fast, stable connectivity.

This is especially relevant for environments such as decentralised finance, exchanges, validator operations, RPC services and analytics pipelines, where milliseconds can affect performance and user experience. The network layer matters a great deal: bandwidth, routing quality, geographic distribution and private interconnection can all influence outcomes.

3. High availability and resilience

Blockchain systems are expected to operate continuously. Downtime can mean missed transactions, degraded service, failed validations or loss of trust.

That makes blockchain’s resiliency critical. Distributed hosting, strong service-level commitments, redundancy, and multi-regional design can all play an important role in keeping blockchain workloads available and synchronised.

For IT leaders evaluating providers or architectures, blockchain should therefore be treated as both an application question and an infrastructure question.

Blockchain goes beyond cryptocurrency

Perhaps the biggest misconception for blockchain is that it begins, and ends, with crypto.

Cryptocurrency is just one application of blockchain, and it is far from the only one. The technology can also support a wide range of business and public-sector use cases where transparency, traceability, automation or shared trust are needed.

Examples include:

• Digital identity and access models, where blockchain can help verify claims or credentials while preserving control and traceability
• Supply chain tracking, where organisations need reliable visibility into provenance, handling and transfers across multiple parties
• Smart contracts, which can automate actions when predefined conditions are met
• Decentralised applications, where services run on distributed infrastructure rather than a single central backend
• Enterprise recordkeeping, where multiple stakeholders need a shared, verifiable source of truth

The key point is that blockchain is valuable beyond the fact that it is decentralised. It is valuable when decentralisation, immutability and shared verification solve a real business or operational challenge together.

A practical view for IT leaders

For IT leaders, blockchain should be approached with the same discipline as any other architecture decision.

And that means asking:

• What trust problem are we solving?
• Do we need a shared ledger across multiple parties?
• What governance model fits the use case?
• What are the performance, security and compliance requirements?
• Which infrastructure will support this reliably at scale?

In some cases, a conventional database will still be the right answer. In others, blockchain offers a stronger foundation for transparency, resilience and distributed trust.

The important thing is to move beyond the hype. Used in the right context, blockchain is a practical architectural model with applications that extend well beyond cryptocurrency.

As adoption grows, IT leaders who understand both the technology and its infrastructure requirements will be those best placed to identify where it can deliver meaningful business value.

This article is based on the guide “The Blockchain Blueprint”, available to download for free.