Migrer vers le cloud est une étape stimulante, mais les décisions prises en amont conditionnent durablement la suite.

La véritable pression se fait sentir à mesure que les usages augmentent et que les architectures sont soumises à des charges plus soutenues. Ce qui fonctionne lors de la migration initiale ne tient pas toujours lorsque les systèmes doivent évoluer à l’échelle de plusieurs régions, équipes et charges de travail.

Les ingénieurs des Professional Services et les Customer Success Managers d’OVHcloud mettent en lumière des décisions souvent sous-estimées, mais déterminantes pour la réussite des migrations et des déploiements dans le cloud public, en posant les bases d’une croissance à la fois évolutive et durable.

Ce qui est négligé au départ, mais qui façonne l’évolutivité par la suite

Le succès à long terme d’un projet cloud se joue généralement au cours des six à douze premiers mois. C’est durant cette période que les choix d’infrastructure ont le plus d’impact et que la préparation opérationnelle devient critique. Souvent relégués au second plan lors d’une migration, le réseau, l’architecture régionale et les fondations opérationnelles s’imposent rapidement comme des éléments clés à mesure que les environnements se développent.

Les premiers déploiements peuvent fonctionner avec succès en utilisant des interfaces publiques et des configurations par défaut. Mais à mesure que les services se multiplient, le trafic interne augmente entre les API, les bases de données et les couches de traitement en arrière-plan. Sans un modèle de réseau privé, cette couche de communication peut introduire de la latence, exposer des données sensibles et entraîner, à terme, des refontes complexes.

« La sécurité doit être la priorité. Un simple ’lift and shift’, sans conception préalable d’une landing zone sécurisée et évolutive, ne suffit pas. Il est essentiel de mettre en place dès le départ une infrastructure adaptée aux besoins futurs. » – Olivier Javaux, Professional Services, OVHcloud

Construire la résilience au-delà du déploiement initial

La stratégie régionale obéit à la même logique. Le choix entre un déploiement en zone de disponibilité unique ou multiple influence directement la résilience, les mécanismes de bascule et la complexité opérationnelle. Revenir sur ces choix après le déploiement s’avère particulièrement complexe, surtout lorsque des dépendances de données et du trafic en production sont déjà en place. En intégrant dès le départ les perspectives de croissance, les exigences de disponibilité et les besoins de continuité d’activité, les organisations peuvent inscrire l’évolutivité et la durabilité au cœur même de la conception de leurs systèmes, et ainsi éviter des ajustements coûteux par la suite.

Les landing zones et les dispositifs opérationnels sont également trop souvent relégués au second plan, alors qu’ils jouent un rôle clé dans les opérations quotidiennes, la gestion des incidents et la conformité à mesure que les systèmes évoluent. L’un des enseignements majeurs réside dans un changement de posture : les équipes cloud doivent passer d’une logique centrée sur le déploiement de l’infrastructure à une approche intégrant dès le départ la visibilité, la gouvernance et le pilotage opérationnel. Les services managés et les plateformes standardisées accompagnent cette transition en réduisant la charge opérationnelle, tout en améliorant la supervision à mesure que les environnements gagnent en complexité.

La dimension humaine, enfin, ne doit pas être sous-estimée. Une intégration structurée, associée à des formations adaptées et à un alignement clair entre les parties prenantes opérationnelles, permet de limiter les incompréhensions et d’accélérer l’adoption. À l’inverse, lorsque la conduite du changement est négligée dès les premières phases, même des plateformes cloud techniquement solides peuvent être perçues comme risquées, freinant les déploiements et renforçant les résistances internes.

« Une formation adaptée doit être mise en place afin que les équipes ne perdent pas la maîtrise de leur infrastructure. » – Olivier Picquenot, Customer Success Director, OVHcloud

💡 Conseil de mise en œuvre :

Réaliser une évaluation de maturité cloud ou un proof of concept ciblé permet de valider la conception réseau et les mécanismes de résilience, et de poser ainsi les bases nécessaires à une évolutivité durable.

Le travail essentiel qui transforme des objectifs stratégiques en décisions d’architecture

La migration et le passage à l’échelle s’appuient sur des objectifs bien identifiés : améliorer les performances, maîtriser les coûts et accompagner la croissance. C’est dans la traduction de ces objectifs en décisions d’infrastructure que la complexité se révèle.

« L’évolutivité doit être étudiée dès le départ, notamment en tenant compte des profils de charge. L’un des principaux avantages du cloud réside dans sa capacité à s’adapter à la hausse ou à la baisse en fonction de la charge. » – Olivier Picquenot

Comprendre dès le départ les dépendances applicatives, les pics de charge, les exigences de conformité ou encore les écarts de compétences au sein des équipes est déterminant. Sans cette visibilité, les décisions liées à l’évolutivité deviennent réactives, prises dans l’urgence et sur la base d’informations incomplètes.

Les équipes doivent donc expliciter leurs hypothèses dès le début, en se posant des questions concrètes :

• Comment le trafic interne entre les services se comportera-t-il sous charge ?
• À quels moments les pics d’activité surviennent-ils et comment les mécanismes d’adaptation permettront-ils d’y répondre ?
• Quelles contraintes de conformité ou de localisation des données influencent le déploiement des ressources ?
• Les équipes disposent-elles des compétences nécessaires pour exploiter des plateformes complexes dans la durée ?

L’automatisation et les services managés apportent une réponse concrète à ces enjeux. L’Infrastructure as Code, les bases de données managées ou encore les services intégrés permettent de réduire la charge opérationnelle, tout en recentrant les équipes sur la création de valeur plutôt que sur la maintenance de l’infrastructure.

💡 Conseil de mise en œuvre :

Associer les objectifs métier à des indicateurs techniques mesurables permet ensuite, grâce à l’automatisation et aux services managés, de les traduire en une architecture réellement évolutive.

Les risques liés au passage à l’échelle et les fondamentaux opérationnels

Une croissance rapide introduit des risques opérationnels capables de fragiliser même des environnements bien conçus. Certaines pratiques fondamentales permettent toutefois de limiter ces dérives.

« La réponse la plus importante est l’automatisation. Avec des outils comme Terraform ou OpenTofu, les organisations sont prêtes à passer à l’échelle. » – Olivier Javaux

L’automatisation du provisionnement, de l’adaptation à la charge et du monitoring garantit des déploiements reproductibles et prépare les équipes à évoluer efficacement. En parallèle, la clarification des responsabilités, la standardisation des environnements et la réduction de la dispersion des outils facilitent le diagnostic des incidents, renforcent la conformité et contribuent à une meilleure maîtrise des coûts. À mesure que les équipes et les plateformes se développent, la cohérence devient un véritable levier d’efficacité.

La transition d’applications monolithiques vers des architectures en microservices ou vers Kubernetes reste complexe. Une approche progressive permet toutefois de sécuriser cette transformation. Commencer par un service à faible risque permet de valider les processus de migration, d’ajuster les mécanismes d’adaptation et d’étendre progressivement le périmètre, tout en renforçant la confiance des équipes.

💡 Conseil de mise en œuvre :

S’appuyer sur la reproductibilité constitue un levier clé pour accompagner l’évolution des plateformes. L’automatisation, la standardisation et le déploiement progressif permettent d’en assurer la stabilité dans la durée.

Éviter les coûts cachés

Les hypothèses héritées des systèmes existants, tout comme le surdimensionnement, constituent des pièges fréquents lors des migrations vers le cloud. Sans remise en question des modèles de conception, les équipes risquent de générer des coûts inutiles et d’alourdir la complexité opérationnelle.

Or, les environnements cloud évoluent rapidement. Une révision régulière de l’architecture permet de tirer pleinement parti des nouveaux services et d’adopter des modèles plus efficaces.

« Un modèle de tarification prédictif et transparent, dans lequel les clients paient uniquement pour les ressources réellement consommées, comme le stockage, la puissance de calcul ou la bande passante, permet de mieux anticiper les projets. » – Amarjit Toor

Conseil de mise en œuvre :

Éviter de reproduire à l’identique les modèles hérités implique d’évaluer en continu les services utilisés et d’ajuster l’architecture en fonction des usages réels.

Concevoir pour l’évolutivité

Réussir le passage à l’échelle des projets cloud suppose de concevoir dès le départ en intégrant la croissance, la sécurité et l’efficacité opérationnelle. Tout commence par les fondamentaux : automatiser de manière systématique et s’appuyer sur des expertises pour construire des bases solides en matière de réseau, d’observabilité, d’automatisation et de préparation opérationnelle.

Des équipes confiantes, concentrées sur la création de valeur plutôt que sur la gestion des incidents d’infrastructure, soutenues par une plateforme résiliente, c’est ce qui fait la différence sur le long terme.

Si vous êtes en phase de croissance et souhaitez que le cloud ne soit plus une source de complexité, découvrez des solutions cloud évolutives adaptées aux entreprises en développement.

Migrating to the cloud is exciting, but early decisions define what follows.

Real pressure emerges as usage grows and architectures are tested under sustained load. What worked for initial migration doesn’t always hold up when systems need to scale across regions, teams and workloads.

OVHcloud Professional Services Engineers and Customer Success Managers highlight the often-overlooked decisions that drive successful public cloud migrations and deployments, setting the foundations for scalable, future-ready growth.

What gets overlooked early, but shapes scaling later

The long-term success of a cloud project is defined in the first six to twelve months, where early infrastructure decisions often have the biggest impact and operational readiness is crucial. Networking, regional design and operational foundations may feel secondary during migration, but they quickly become central as environments grow.

Early deployments may run successfully using public interfaces and default configuration, but as services expand, internal traffic increases between APIs, databases and background processing layers. Without a private network model, that communication layer can introduce latency, expose sensitive traffic, and require disruptive redesign later.

“Security must be the priority. A simple ‘lift & shift’, without first designing a scalable and secure landing zone, isn’t enough. Ensure the correct infrastructure is in place at the beginning to account for future needs.” – Olivier Javaux, Professional Services, OVHcloud

Building resilience beyond initial deployment

Regional strategy follows the same pattern. Choices between single- and multi-availability zone (AZ) deployments influence resilience, failover behaviour and operational complexity. Changing these configurations after deployment is challenging, particularly when data dependencies and production traffic are already in place. By factoring in growth, availability requirements and business continuity early on, organisations can embed scalability and sustainability directly into their system design, alleviating the pressures of having to retrofit later.

Landing zones and operational systems are also common afterthoughts despite being central to day-to-day processes, incident response and compliance as systems scale. The key lesson is a necessary shift in focus: cloud teams need to move from simply deploying infrastructure to establishing visibility, governance and operational control from the outset. Managed services and standardised platforms further support this shift by reducing operational burden while improving oversight as environments expand.

The human dimension cannot be overstated. Proper onboarding, training and alignment across operational stakeholders helps reduce confusion and accelerate adoption. When change management is overlooked in the early stages, even well-architected cloud platforms can feel risky, slowing delivery and increasing resistance.

“The correct training must be in place to ensure teams don’t feel like they’re losing grip on the infrastructure.” – Olivier Picquenot, Customer Success Director, OVHcloud

💡 Implementation tip:

Conduct a cloud maturity assessment or small proof-of-concept to validate network design and resiliency. These early choices become the difference that scales later.

The vital work turning high-level goals into architecture decisions

Migration and scaling begin with clear objectives: improve performance, control costs, and support growth. Translating these into infrastructure decisions is where complexity creeps in.

“Scalability must be studied from the start, including load patterns. One of the main advantages of the cloud is the capacity to scale up or down depending on the load.” – Olivier Picquenot

Understanding dependencies, peak load patterns, compliance requirements and team skills gaps early on is essential. Without this visibility, scaling decisions are made reactively using incomplete information.

Teams should clarify assumptions from the start by asking practical questions early:

• How will internal traffic between services behave under load?
• What are the peak times, and how will scaling respond?
• Which compliance or data residency requirements affect where resources are provisioned?
• Does the team have the skills to operate complex platforms long term?

Automation and managed services help bridge the gap. Infrastructure-as-code, managed databases and integrated systems reduce operational overhead and frees teams to focus on building value, rather than maintaining infrastructure.

💡 Implementation tip:

Map business goals to measurable technical outcomes. Automation and managed services turn intent into scalable architecture.

Scaling risks and operational fundamentals

Rapid growth introduces operational risks that can destabilise even well-designed environments. Foundational practices can prevent these issues.

“The most important answer is automation. Using tools like Terraform or OpenTofu, organisations are ready to scale.” – Olivier Javaux

Automating provisioning, scaling and monitoring ensures repeatable deployments and prepares teams to scale efficiently. Meanwhile, defining ownership, standardising environments and reducing tool sprawl simplify troubleshooting and improve compliance as costs lower. Consistency becomes a force multiplier as teams and platforms grow.

Moving from monolithic applications to microservices or Kubernetes is complex, however, a phased migration approach helps to avoid failure. Starting with a low-risk service allows teams to validate the migration process, tune scaling and gradually expand while building confidence.

💡 Implementation tip:

Scale through repeatability. Automation, standardisation and phased delivery create stability as platforms grow.

Avoiding hidden costs

Legacy assumptions and over-provisioning are common traps in cloud migration. Without rethinking design patterns, teams risk creating unnecessary cost and operational complexity.

Cloud environments evolve rapidly. Reviewing architecture regularly ensures teams benefit from improved services and efficient patterns.

“A predictive, transparent pricing model where customers are charged only for the resources they consume, such as storage, compute power or bandwidth, allows for greater confidence in forecasting projects” – Amarjit Toor

💡 Implementation tip:

Avoid lifting legacy patterns unchanged. Continuously assess services and adjust architecture to match real-world demand.

Designing for scale

Scaling cloud projects successfully means designing for growth, security and operational efficiency from day one. Start with the fundamentals – automate relentlessly and leverage expertise when building the foundations for networking, observability, automation and operational readiness.

This is the difference that scales, resulting in a resilient platform and a confident team focused on value, rather than troubleshooting infrastructure.

If you’re navigating growth and want cloud to be one less thing to worry about, explore scalable cloud solutions for growing businesses.

Over the past few years, the speed at which teams can build infrastructure has changed dramatically. Models that once took weeks to train can now be iterated in days. Tooling has improved, workflows have matured, and the overall friction in getting from idea to working output has reduced significantly.

But this acceleration often stops the moment teams try to deploy — and this can make AI deployment frustrating. In this blog, you will learn how Facets can help teams accelerate migration to OVHcloud by making deployment more structured, repeatable and predictable.

What first begins as a fast, iterative process slows down when it enters the infrastructure layer. The work is no longer about models or code. It shifts to provisioning environments, configuring pipelines, managing permissions, setting up networking, and ensuring that everything works reliably outside a controlled development setting. This phase is not inherently complex, but it is fragmented, and that introduces delay.

As a result, there is now a visible gap between how quickly teams can build and how slowly they can move to production. The model may be ready in hours, but the surrounding system required to run it still takes days, weeks, or in some cases even months, to put together.

AI deployment is slow because infrastructure is inconsistent, not because AI is limited

It is tempting to assume that deployment delays are still a technical limitation but, in most cases, that is no longer true. The bottleneck is not the model itself. It is everything around it.

Infrastructure is rarely standardised across teams. Each project tends to define its own setup, its own pipeline, and its own configuration. Even when teams use the same tools, the way those tools are applied differs just enough to create inconsistency.

Over time, these differences accumulate. Environments are recreated, pipelines are reconfigured, dependencies are re-evaluated, and access is managed manually. What should be a repeatable process becomes a fresh effort every time.

This is where deployment slows down. Not because teams cannot build quickly, but because the systems around deployment are not structured for reuse.

Faster deployment starts with reusable infrastructure

Teams that deploy faster do not necessarily rely on fundamentally different tools. They change how infrastructure is organised.

Instead of treating infrastructure as something that needs to be set up for every project, they define it once and reuse it. Environments are created from standard definitions rather than being handcrafted. Deployment workflows follow consistent patterns instead of being recreated each time. Access, policies and guardrails are built into the system rather than handled separately.

This does not eliminate complexity, but it contains it. Systems become easier to understand, easier to operate and easier to extend. Most importantly, they become predictable.

Once infrastructure behaves predictably, deployment stops being a recurring source of delay.

AI improves operations only when infrastructure is already structured as a system

There is growing interest in applying AI to DevOps and infrastructure management, but its role is often misunderstood.

AI does not fix fragmented systems. If the underlying setup is inconsistent, AI will only automate that inconsistency. It may reduce effort in specific tasks, but it does not create structure on its own.

AI becomes valuable when it operates on top of a well-defined system. It can help teams understand system state, identify issues faster, assist with debugging, and reduce manual operational work. But it works best when the infrastructure beneath it is already standardised, reusable and consistent.

Infrastructure needs to shift from project-level setup to a standardised system

As AI accelerates development, the limitations of infrastructure become more pronounced. Teams are able to build faster than they can deploy, and that imbalance introduces friction.

This is not a temporary phase. As development continues to speed up, deployment will remain the limiting factor unless the underlying structure changes.

A different approach is needed. Instead of treating infrastructure as a series of isolated setups, teams need systems that standardise how infrastructure is created, managed and reused.

Facets turns infrastructure into a reusable deployment system

Facets is designed around this model. It brings infrastructure, CI/CD, environments, workflows and guardrails into a single operating system for deployment. It brings infrastructure, CI/CD, environments, workflows and guardrails into a single operating system for deployment. Teams can create environments on demand, follow predefined deployment workflows and retain operational context within the platform instead of relying on scattered documentation or individual knowledge.

This changes how teams interact with infrastructure. The focus shifts from repeatedly setting things up to using a system that is already structured to work.

Choosing the right cloud matters once infrastructure is standardised

Once infrastructure is structured as a system, the choice of where to run it becomes more important.

For AI workloads, teams need reliable compute, predictable cost structures and control over how environments are configured. OVHcloud provides a strong foundation for this, with access to GPU infrastructure, cost predictability, and flexibility in how environments are managed.

However, infrastructure alone does not remove friction. The real advantage comes when teams can move to that infrastructure quickly and operate it consistently without rebuilding their setup.

OVHcloud + Facets: Accelerating Deployment Through Standardisation

OVHcloud provides reliable, on-demand infrastructure for modern workloads. Facets helps teams make that infrastructure deployment-ready.

Together, they address both sides of the problem. OVHcloud provides the cloud foundation, while Facets defines how environments, workflows, policies and guardrails are created and operated on top of it.

Facets.cloud introduces reusable infrastructure blueprints that can be applied across projects. These blueprints define environments, workflows and operational guardrails in advance, allowing teams to deploy standardised systems instead of assembling infrastructure manually each time.

This shifts deployment from a configuration-heavy process to a repeatable, system-driven approach. Teams can reduce the time spent on setup, avoid recreating the same deployment patterns and move workloads onto OVHcloud with greater consistency.

The result is a faster path from migration planning to production-ready environments — helping teams migrate in days, not weeks.

AI speed is ultimately limited by how fast infrastructure can be deployed and operated

AI has already compressed the time it takes to build. The next bottleneck is AI deployment.

And that bottleneck is not solved by adding more tools or more people—it is solved by changing how infrastructure is structured. Because in practice, the speed of AI is defined not by how quickly models are built, but by how quickly they can be deployed and run.

Discover Facets.cloud

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.