A newly disclosed Linux kernel zero-day, CVE-2026-31431, “Copy.Fail”, is one of the most serious privilege-escalation vulnerabilities in recent years.

Discovered by Theori and publicly disclosed on April 29, 2026, Copy.Fail is a Linux kernel zero-day that roots every distribution since 2017. Unlike many local privilege-escalation flaws that depend on race conditions, kernel address leaks, or distribution-specific behavior, Copy.Fail is alarmingly reliable: it works consistently across mainstream Linux distributions with only a standard user account.

Why the CVE-2026-31431 is dangerous?

Copy.Fail abuses a logic flaw in the Linux kernel’s algif_aead crypto module, introduced through a 2017 optimization. By manipulating the kernel’s AF_ALG crypto interface, an attacker can write controlled data into the Linux page cache (the in-memory representation of trusted system binaries).

This allows attackers to temporarily hijack binaries like /usr/bin/su without modifying the file on disk.

In practical terms:

• A normal user can become root
• A compromised container can escape to the host
• A malicious CI job can root its runner
• Shared infrastructure becomes vulnerable across tenants
• Disk forensics may show no file tampering because only RAM is altered

This makes Copy.Fail especially dangerous for:

• Kubernetes clusters
• CI/CD systems
• Shared development environments
• Cloud notebook platforms
• Multi-tenant container infrastructure

How to patch it easily in your MKS clusters?

OVHcloud is preparing patched MKS versions including the upstream kernel fix. Patched versions are expected to be available 30 April 2026, at 16:00 UTC+2.

While waiting for the next MKS release, here is a DaemonSet manifest that you can apply in your MKS clusters in order to mitigate the vulnerability.

Create a patch-copy-fail-cve file with the following content:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: patch-copy-fail-cve
  labels:
    app: patch-copy-fail-cve
  namespace: default
spec:
  selector:
    matchLabels:
      app: patch-copy-fail-cve
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        app: patch-copy-fail-cve
    spec:
      hostPID: true
      priorityClassName: system-node-critical
      volumes:
        - name: root-mount
          hostPath:
            path: /
            type: Directory
      initContainers:
        - image: mks.kubernatine.ovh/docker.io/library/busybox:1.36.1
          name: patch-copy-fail-cve
          command: ["/bin/bash", "-c"]
          args:
            - |
              tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'
              rmmod algif_aead 2>/dev/null
              update-initramfs -u
          securityContext:
            privileged: true
            runAsUser: 0
          volumeMounts:
            - name: root-mount
              mountPath: /
      containers:
        - image: "mks.kubernatine.ovh/registry.k8s.io/pause:3.10.1"
          name: pause     

Apply it:

kubectl apply -f patch-copy-fail-cve.yaml

⚠️ This mitigation has been tested on OVHcloud internal test clusters. Applying it to your own service remains under your responsibility.

If the vulnerability has already been exploited on your cluster, this mitigation will not remediate any pre-existing compromise.
The recommended remediation remains the official security release, which will be made available as soon as possible.

Read more about the mitigation: https://github.com/rootsecdev/cve_2026_31431#mitigation

Every month, the OVHcloud Developer Advocate team creates content, shares knowledge, and connects with the tech community. Here’s a look at what we did in April 2026. 🚀

🎙️ “Tranches de Tech” – Our monthly podcast

A new episode of our French-language podcast Tranches de Tech 🥑 just dropped!

🎧 Episode 27: Tranches de Tech 26 – Poppy au service des autres

This episode of Tranches de Tech features Annabelle Koster, who shares her journey from tech recruiter to community ambassador, highlighting how she overcame impostor syndrome by actively learning and engaging with developers. She emphasizes the importance of community, conferences, and volunteering in building meaningful connections and personal growth. The discussion also explores the evolving role of AI as a productivity tool in her daily work. Ultimately, the episode underlines that, despite technological advances, human interaction, sharing, and mutual support remain at the heart of the tech ecosystem.

📺 Live on Twitch

We streamed live on Twitch this month! Here’s what we covered:
🎥 Rémy Vandepoel discussed with Antonin Anchisi and Aurélie Vache about our Manages Kubernetes Service (MKS) and some feedbacks about the KubeCon Europe 2026.
Catch the replay on YouTube ▶️.

🎤 Conference Talks

The team hit the road (and the stage) at several conferences this month:

🇫🇷 MiXiT – Lyon, France 🇫🇷

Aurélie Vache gave a talk: Comprendre Kubernetes de manière visuelle

Stéphane Philippart gave a workshop: Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

🇫🇷 Devoxx France – Paris, France 🇫🇷

Aurélie Vache gave a talk: Question pour un cluster Kubernetes : Quiz sur Kubernetes & ses concepts

Stéphane Philippart gave a talk and a workshop (with Mathieu Busquet):
– 🤖 Apprendre à notre IA à … apprendre 🧠
– Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

📝 Our latest blog posts

Here are the articles our team published on the OVHcloud Blog this month.

📝 Extract Text from Images with OCR using Python and OVHcloud AI Endpoints — by Stéphane Philippart

This blog post explains how to perform OCR (Optical Character Recognition) using a vision-capable language model via AI Endpoints and Python. It shows that, instead of traditional OCR tools, developers can send images directly to a multimodal model using the OpenAI-compatible API to extract text while preserving layout. The tutorial walks through a simple Python script, including environment setup, image encoding in base64, and API calls. Overall, it highlights how modern vision LLMs simplify OCR workflows, making text extraction more flexible and easier to implement.

📝 Discover the External Secret Operator (ESO) OVHcloud Provider to manage your Kubernetes secrets 🎉 – by Aurélie Vache

This blog post introduces a new provider for the External Secrets Operator (ESO) that integrates directly with OVHcloud Secret Manager, simplifying how secrets are handled in Kubernetes. It explains how ESO works by synchronizing secrets from external systems into Kubernetes and automatically updating them when changes occur. The tutorial walks through the full setup, including creating a secret in OVHcloud, configuring authentication, and deploying resources like ClusterSecretStore and ExternalSecret. Overall, the article highlights how this new provider streamlines secret management and improves integration between OVHcloud services and Kubernetes environments.

📝 KubeCon + CloudNativeCon Europe 2026 in Amsterdam: feedback and highlights by Aurélie Vache and Rémy Vandepoel

The post highlights KubeCon + CloudNativeCon Europe 2026 as strongly shaped by the rise of AI, pushing cloud-native toward an “AI-native” paradigm. OVHcloud emphasizes sovereign cloud principles, focusing on openness, reversibility, and performance. The event featured rich technical discussions, demos, and exchanges around Kubernetes and demanding workloads. It also underscored the importance of open-source collaboration within the CNCF ecosystem. Finally, OVHcloud’s booth and activities aimed to make these topics more accessible and tangible.

🗓️ Coming up next

Here’s a sneak peek at what’s coming next.

🗓️ – May, 6 & 7 – Devoxx UK, in London

🎤 Stéphane Philippart is giving one talk (Wednesday the 6th at 6PM): 🧰 Dev Containers: the ultimate toolbox for developers?

🗓️ – May, 13 – 1h PM CET – Very Tech Talk Twitch about Human Resources

📺 OVHcloud Twitch channel

🗓️ – May, 19 & 20 – Kubernetes Community Days in Helsinki

🎤 Aurélie Vache is giving one talk (Wednesday the 20th at 2h30 PM): The Ultimate Kubernetes Challenge: An Interactive Trivia Game on concepts, components, usage…

🗓️ – May, 21 & 22 – Devops days in Geneva

🎤 Stéphane Philippart is giving one workshop (Thursday the 21th at 2h55 PM): Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

🗓️ New “Tranches de Tech” podcast episode

🎧 All episodes are available on Ausha and all your favorite podcast applications!

💬 Stay in Touch

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

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

See you next month! 👋

Aurélie Vache and Rémy Vandepoel attended alongside 26 other OVHcloud employees. In this blog, they share their thoughts about this second KubeCon set in the land of tulips.

KubeCon Europe 2026: the maturity milestone

Back from Amsterdam, the buzz of the RAI halls still echoes in our ears. This 2026 edition of KubeCon + CloudNativeCon Europe wasn’t just another Kubernetes conference. It marked a turning point for this event: the point of maturity. And this is evident just by looking at the numbers: 13,500 attendees for this edition! The largest attendance ever recorded!

While previous years were about exploration and expansion, 2026 was the year of massive industrialization, with one non-negotiable pre-requirement: digital sovereignty.

Key figures from the 2026 edition:

• 13,500+ attendees (46% first-time attendees)
• 100 countries represented
• 3,474 unique organizations/companies
• 891 sessions
• 230 projects in the CNCF landscape with 19.9 million contributors

CNCF Contributors by Geography (Last 12 Months)

• Europe: 38.8% of contributions (ahead of the United States)
• United States: 36.29%
• Germany: 9.82% (leading in Europe)
• France: 4.68%
• Switzerland: 2.49%
• Strong signals for digital sovereignty, a key theme of this year’s keynotes 💪

Colocated events

KubeCon + CloudNativeCon Europe 2026 traditionally kicks off with a full day dedicated to co-located events. This year was no exception, with an impressive lineup of 16 events, including well-known favorites such as ArgoCon, BackstageCon, CiliumCon, Platform Engineering Day, Kubernetes on Edge Day, and Observability Day.

Among the newcomer events, Open Sovereign Cloud Day was a stand out, as it highlighted the growing importance of cloud sovereignty in Europe.

During CiliumCon, we were proud to see the spotlight on our MKS Standard offer 🚀.

OVHcloud Presence

OVHcloud had a strong presence at the event, with two different booths serving two different purposes.

One was located in the Activation Zone, designed as an interactive space to engage with attendees through a video game “Gaming Camp: Beat Cloud Villains!”, described as “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. Winners won exclusive t-shirts.

The second booth had a more corporate focus, highlighting OVHcloud’s broader portfolio, strategic positioning, and enterprise offerings. It provided a space for deeper conversations around demos, use cases, and cloud strategies.

The opportunity was too good to pass up, so we took the chance to interview key players in the ecosystem, as well as customers of our solutions.

We conducted five interviews and had many discussions, and we can’t wait to share them with you soon!

Here’s a sneak peek featuring Sudeep Goswami, CEO of Traefik Labs:

These interviews will soon be available on YouTube, so stay tuned!

Aurélie Vache’s talk

Getting accepted to KubeCon is not easy, and Aurélie, our Developer Advocate and CNCF Ambassador, rose to the challenge by once again presenting a new talk.

“The Ultimate Kubernetes Challenge: An Interactive Trivia Game”:

“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.“

During this talk, attendees tested their Kubernetes knowledge through an interactive quiz, with results presented via illustrated slides and live, hands-on demos.

Giving a talk at 5 p.m., during the final session of the second day, was an ambitious way to finish up. But thanks to the interactive format of her talk, attendees were able to enjoy testing their knowledge while discovering tips about Kubernetes and its concepts and features.

Three OVHcloud MKS clusters were created especially for the occasion, one with 3 nodes, one with zero nodes, and one with 3 nodes across 3 Availability Zones:

Watch the talk here:

Keynotes: Toward “Agent-Based” and Autonomous AI

Plenary sessions at the event were dominated by a convergence of Kubernetes and Artificial Intelligence. This term, already ubiquitous in tech news, was bound to be a major focus here. Jonathan Bryce, the Executive Director of Cloud & Infrastructure at the Linux Foundation and an iconic figure in the ecosystem, made a strong point by reminding the audience that while Kubernetes is everywhere (82% adoption rate), AI in production remains a major challenge.

In November, during the latest KubeCon + CoudNativeCon NA at Atlanta, the CNCF launched the “Certified Kubernetes AI Conformance Program to Standardize AI Workloads on Kubernetes“.  5 months later, several companies including the OVHcloud Managed Kubernetes Services (MKS) platform, succeeded this new program with their own certified Kubernetes AI platform.

During the keynotes we even saw a real plane!

And to top it off, seeing Michelin present the Top End User Award to SNCF was a real highlight for us. Cocoricoooo! 🇫🇷

Key Trends

Find below the most frequently discussed technical pillars that will remain prominent in the coming months and years:

* Agent-based AI: The focus is shifting from training to inference. The announcement of Dapr Agents 1.0 shows that Kubernetes will now orchestrate agents capable of making real-time decisions on the infrastructure.

* GPU Standardization (DRA): Thanks to NVIDIA’s widespread adoption of Dynamic Resource Allocation (DRA) drivers, GPU scheduling is becoming as simple and granular as CPU scheduling. A boon for cost optimization.

* Sovereignty: Sovereignty is no longer a legal concept; it is an architecture. We have seen a rise in encryption tools for data in transit and at rest (Confidential Computing) natively integrated into CNIs such as Cilium.

* FinOps 2.0: With 67% of AI compute dedicated to inference by the end of 2026, precise monitoring of GPU consumption via projects like Kepler has become essential for the economic viability of projects.

The Gateway API is becoming the standard

As we announced in our blog post “Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?”, the ingress-nginx controller, the most widely used ingress controller, has now been archived.

Now, after 8 years of development, 275 released versions, and nearly 20k GitHub stars, the maintainers of the Kubernetes Gateway API introduced ingress2gateway v1.0, a tool designed to simplify migration. It automatically converts Ingress resources including annotations into Gateway API resources. The recommended approach remains pragmatic: first migrate the controller while keeping existing Ingress objects, then gradually transition to the Gateway API. Attempting a full migration in a single step is considered risky and unnecessary.

Additionally, Gateway API version 1.5 represents a major milestone: five features have moved from experimental status to the Standard channel in a single release.

Amongst them:

• ListenerSet: delegates TLS listener management outside of the Gateway 
• TLSRoute: SNI-based routing in either termination or passthrough mode
• Client certificate validation for mTLS at the ingress layer
• Native CORS filter for HTTPRoute

The Kubernetes Gateway API is now establishing itself as much more than just a successor to Ingress: it is evolving into Kubernetes’ unified network control plane.

Favorite talk

As usual, Aurélie wasn’t able to attend many talks, but among the 2-3 she did see, there was one that really had a “wow” effect on her:

« An immersive and visual journey into kubernetes networking ».

Benoit, a DevSecOps engineer at Feesh in Switzerland with extensive expertise in Kubernetes networking, created a video game using Godot with four levels: “pod-to-pod basics”, “pod-to-pod advanced”, “service mesh sidecar”, and “service mesh with ambient mode”.

Across these four levels, he explains Kubernetes networking in a vanilla setup, then with Cilium and Istio, all from the perspective of a TCP packet, represented as a fish.

Networking and I don’t exactly get along, and I’ll admit I’ve always struggled with it. Even now, although I’ve had no choice but to work with Kubernetes and service mesh, I still find it challenging. But seeing the fish swim from frontend to backend, enter a building underwater (the node), interact with an eBPF program… it really makes things more visual and intuitive.

On Thursday morning, after the keynote, the room with 2000 seats was packed!

Explaining networking by building a 3D game from scratch specifically for the occasion: hats off to you!

Benoit had an issue on stage, because he had built the game in 4K and it didn’t display properly on the projection screen. Luckily, about 30 seconds before showtime, the production team and he managed to fix it. He went on stage without showing any of that stress 💪.

Replay:

KubeCon in 45 seconds

To keep memories of these 3-4 amazing days, we created a “KubeCon Europe 2026 in 45 seconds movie:

Conclusion

KubeCon Amsterdam proved once again that the strength of open source lies in its community.

From the halls of the RAI to the technical sessions, the excitement was palpable. We’re leaving with our heads full of ideas, but above all with the certainty that collaboration remains the key to solving the complex challenges of modern IT. This was particularly evident in the packed conference rooms and the crowded aisles of the exhibition hall.

One thing is certain: the future of Cloud Native is being written together, and we at OVHcloud look forward to contributing to it with you by helping you get the most out of Kubernetes through our managed platform. Because we’re convinced that for businesses in 2026, the challenge will no longer be how to run Kubernetes, but how to use it to innovate faster and better than the competition.

With the OVHcloud Startup Program, you can enhance your cloud expertise and accelerate your growth. How?

The Startup Program provides you with access to dedicated cloud resources, including technical consultation sessions with our engineers. These sessions can help you navigate the complexities of cloud infrastructure and optimize your cloud strategy.

Now you can also get access to dedicated cloud training. As a Startup Program member, you can obtain cloud solutions certifications which will make you stand out from the crowd and, also, be better prepared to navigate your cloud strategy.

We’ve opted for a flexible training model because we trust our customers. This means that you can train independently through e-learning, whenever you want, choosing the courses that are relevant to your business and the people who need to be trained, according to their role. This saves you time and money and, thanks to the expertise you’ll gain through training, you’ll be able to deploy more cost-effective and efficient cloud solutions.

Our training courses and certifications give you a more qualified workforce.

In addition to validating your technical skills, our certifications can help you develop your expertise. Plus, you can demonstrate this with our certification badges, which help you gain recognition.

Finally, OVHcloud offers a wide range of solutions. Our training courses will help you discover the scope of these solutions and when and how to use them. Each course is designed to help you deliver a great experience for your customers. Simply by having the right knowledge to effectively identify the best solution to meet their needs.

Once trained, you are also likely to have ideas for new projects.

Get certified and give your expertise a headstart.

Discover our Training Portal’s catalog to boost your expertise.

https://startup.ovhcloud.com/Get started with the OVHcloud Startup Program and accelerate your growth today. Apply now and discover how our program can help you achieve your goals: https://startup.ovhcloud.com/

1) We are introducing three new Web Hosting ranges

Our offers will be organized into three distinct ranges, each designed to match different needs and usage profiles. Whether you are launching a simple website, running a growing business, or managing multiple client projects, you can now more easily find the plan that fits your situation.

Eco range: affordable and straightforward hosting

This range is designed for professionals looking for a cost-effective solution. It focuses on essential features to get a website online quickly and easily, without unnecessary complexity. All plans include the core services: disk space, email accounts, a domain name, and built-in security.

It is ideal for simple websites, first projects, portfolios, or small business sites that need to be reliable and easy to manage from day one. You get everything you need to launch and run your site, at a price that stays accessible over time.

In short, we provide a straightforward, dependable hosting solution that covers the essentials, so you can focus on your project, not on technical setup.

If you already own a domain name with OVHcloud, you can activate your free hosting right away. Every domain includes 100 MB of hosting, so you can get your first web pages online at no additional cost. This free plan comes with one email account, the performance of our infrastructure, and the same high level of security as all our other products.

Business range: performance and flexibility

The Business range is built for professionals who need more performance, flexibility, and resources to support their growth.

As your website evolves, so do your requirements: more traffic, more content, more integrations. This range provides faster loading times, more generous resources (databases, storage, email accounts), and additional technical capabilities to adapt your environment to your needs.

Whether you are running a business website, an e-commerce platform, or multiple projects, you benefit from a hosting solution designed to keep up with your growth while giving you more control.

For more demanding use cases, our Pro and Performance plans provide higher CPU and RAM allocations designed to handle traffic spikes smoothly, ensuring your websites remain responsive even during peak activity.

In short, this is the right balance between performance, flexibility, and cost-efficiency for growing projects.

Agencies range: built for managing multiple clients efficiently

The Agencies range is designed for professionals managing several websites across multiple clients.

When you operate multiple projects, efficiency becomes key. This range allows you to host, manage, and scale multiple websites within a single environment, helping you centralize operations and reduce costs.

It is particularly suited for agencies, freelancers, and service providers who need to deploy, maintain, and monitor many sites while keeping their workflow simple and scalable.

In short: a solution built to help you manage more projects and clients, more efficiently, while saving both time and costs, without multiplying hosting plans.

2) More capacity to grow your projects

After a full renewal of our compute infrastructure in 2025, our Web Hosting plans are now up to 3x faster, with 2x more compute power allocated.

In 2026, we are upgrading our storage technology. All our Web Hosting plans are progressively moving to SSD storage to ensure faster access times and better resilience during incidents or maintenance operations. The result: improved service quality and higher availability for your websites.

In addition, we are increasing both the number of databases and the storage capacity per database included in our Web Hosting plans.

What’s changing

Many customers begin with a single website, then expand to additional projects such as blogs, landing pages, test environments, or client websites. Because our Web Hosting plans are designed to be multi-site, you can host multiple projects within a single plan. As your projects grow, database requirements naturally increase due to additional content, users, plugins, and data.

Our goal is simple: instead of requiring an immediate upgrade to a higher plan, we are including additional resources directly in your existing plan. This allows you to group multiple websites under the same hosting account, each with its own database. In practice, this reduces costs, simplifies management, and gives you the flexibility to scale your projects without unnecessary complexity.

What this means for you

Run multiple websites without additional hosting plans
You can create and manage several websites under the same account, each with its own database, without needing to upgrade immediately.

Install multiple CMS environments easily
Whether you use WordPress, Joomla!, PrestaShop, or another CMS, you can deploy separate projects independently, without database limitations.

Create staging and test environments
You can duplicate websites to safely test updates, themes, or plugins before deploying them to production.

Support long-term website growth
As your traffic and content increase, larger databases provide additional capacity without the risk of quickly reaching storage limits.

By expanding both database capacity and quantity, we are providing more room for your projects to grow without requiring an immediate plan upgrade.

3) Pricing update: lower entry price and long-term savings

As part of this evolution, our pricing structure is also changing. It has been designed with two clear objectives: maintain a very accessible entry price for new projects and deliver stronger overall value for customers choosing longer durations.

A highly competitive first year for new subscriptions

For any new subscription, the first-year price is intentionally kept very low.

For example, the Pro plan now starts at €1.99/month for the first year.

This approach makes it easier to launch a new idea, test a concept, or start a business without significant upfront costs. Customers launching new projects benefit from one of the most competitive entry prices available.

All core hosting features remain included: generous email accounts, a domain name included during the first year, multi-site capability, expanded database resources, and enhanced support services. In short, you keep everything that makes your hosting complete, with additional resources and improved assistance.

Better pricing with longer durations

We are introducing 24- and 48-month prepaid plans to help you secure the best possible rate! Most websites are long-term projects that grow in visibility, traffic, and business value, and we want your hosting plan to support that long-term development.

By selecting a longer duration, you can benefit from significant savings:

• Choosing 24 months can represent savings equivalent to 5 to 6 months compared to annual renewals.
• Choosing 48 months can represent savings equivalent to 16 to 18 months compared to annual renewals.

This approach is simple: the longer your duration, the lower your monthly price and the more predictable your hosting budget becomes.

4) Renew now and keep your current price

If you are already a customer, we want to ensure your loyalty continues to be rewarded. Many of you have trusted us to host your projects for years, and we want to give you the opportunity to maintain your current pricing conditions.

If you wish to retain your existing pricing, you can renew your hosting plan before 1st June 2026. This allows you to secure your current rate while continuing to benefit from all plan improvements. Renewal can be completed in just a few clicks from your Control Panel.

By renewing in advance, you can:

• Lock in your current rate for the duration you choose
• Extend your subscription for up to 4 additional years
• Continue benefiting from upgraded features, including additional databases and improved support

For long-term projects, renewing now provides cost stability and better visibility on future hosting expenses.

5) A redesigned and strengthened support experience

For many of you, running a website is more than a hobby. It can generate revenue, support clients, or represent your business online. When an issue occurs, you do not want to simply open a ticket. You expect clear guidance and fast resolution. We have listened to this feedback and are strengthening our support services to be easier to reach, faster to respond, and more helpful when you need expert advice.

Here is how your day-to-day support experience will evolve:

Support whenever you need it
We are progressively rolling out 24/7 availability, with expanded contact channels so you can reach us at any time, whether you are launching a new site, managing an urgent issue, or looking for guidance.

Faster responses
An improved live chat experience will allow you to connect quickly with our teams and receive clear answers with reduced waiting times.

Simplified human interaction
You will be able to call us directly from your browser and request a callback from one of our agents, allowing you to receive assistance in the way that suits you best.

Stronger guidance and follow-up
We are adopting a more proactive support approach, focused not only on resolving issues but also on advising you and helping you move your projects forward with confidence.

Our objective is straightforward: make it easier and faster for you to get help when you need it. Whether you are launching a new website, managing updates, or troubleshooting an issue, we are continuously investing to deliver a smoother customer experience.

These improvements reflect our commitment to supporting both beginners and advanced users with reliable and accessible assistance. They are currently being prepared and will be progressively deployed to ensure quality and stability.

6) Dedicated offers for Partners and Agencies (coming soon)

Some customers go beyond managing their own websites. They design, deploy, and resell complete web environments for their clients, including hosting, domain names, email services, and other solutions, sometimes under their own brand. Resellers and agencies often operate across the entire OVHcloud ecosystem and require solutions adapted to multi-client and multi-service environments.

Managing a Web Cloud portfolio typically involves:

• Coordinating updates across multiple customer environments
• Ensuring availability and performance across all hosted projects
• Responding quickly when customer services are impacted
• Optimizing costs and margins across service portfolios

We are preparing a dedicated offer designed specifically for these use cases.
This upcoming partner offering will include:

• Premium and prioritized support with clearer escalation paths for business-critical situations
• Preferential pricing tailored to multi-product portfolios
• Management tools designed for agencies to simplify deployment, monitoring, and maintenance across multiple services for your multiple customers. 

More details will be shared soon. We look forward to developing this offer in collaboration with our partner ecosystem.

7) New features

We are continuously improving our Web Hosting platform, and several major enhancements are already underway.

We have recently completed a full renewal of our compute infrastructure to deliver improved performance and reliability across all hosted websites. Read more about it on our dedicated blog article.

We are also currently replacing our storage infrastructure with the same objective: delivering improved performance, resilience, and long-term data reliability.

These infrastructure upgrades are part of a broader and transparent product roadmap. We openly share our development priorities so you can track ongoing and upcoming improvements.

Beyond infrastructure, upcoming enhancements include:

• Simplified WordPress management through Managed Hosting for WordPress (currently available in beta), providing increased automation and easier daily administration.
• Our new video hosting solution designed to deliver media content without relying on third-party platforms. Discover the Video Center!
• New AI-powered features to help manage, optimize, and secure your websites

Our commitment to you

Whether you are running a personal website, launching a business, or managing multiple projects, our objective remains unchanged: deliver a powerful, reliable, and cost-efficient platform that supports your growth over time and continuously improve your hosting experience with practical features that simplify daily management while strengthening performance and reliability. 

This reference architecture demonstrates how to deploy a Large Language Model (LLM) inference system using vLLM on OVHcloud Managed Kubernetes Service (MKS). The solution leverages NVIDIA L40S GPUs to serve the Qwen3-VL-8B-Instruct multimodal model (vision + text) with OpenAI-compatible API endpoints.

This comprehensive guide shows you how to deploy, to scale automatically, and how to monitor vLLM-based LLM workloads on the OVHcloud infrastructure.

What are the key benefits?

• Cost-effectiveness: Leverage managed services to minimise operational overhead
• Real-time observability: Track Time-to-First-Token (TTFT), throughput, and resource utilisation
• Sovereign infrastructure: Keep all metrics and data within European datacentres
• Scalable by design: Automatically scale GPU inference replicas based on real workload demand

Context

Managed Kubernetes Service

OVHcloud MKS is a fully managed Kubernetes platform designed to help you deploy, operate, and scale containerised applications in production. It provides a secure and reliable Kubernetes environment without the operational overhead of managing the control plane.

How does this benefit you?

• Cost-efficient: Pay only for worker nodes and consumed resources, with no additional charge for the Kubernetes control plane
• Fully managed Kubernetes: Certified upstream Kubernetes with automated control plane management, provided upgrades and high availability
• Production-ready by design: Built-in integrations with OVHcloud Load Balancers, networking, and persistent storage
• Scalable and flexible: Scale workloads easily, node pools to match application demand
• Open and portable: Based on standard Kubernetes APIs, enable seamless integration with open-source ecosystems and avoid vendor lock-in

In the following guide, all services are deployed within the OVHcloud Public Cloud.

Architecture overview

This reference architecture demonstrates a basic deployment of vLLM for vision-language model inference on OVHcloud Managed Kubernetes Service, featuring:

• High-availability deployment with 2 GPU nodes (NVIDIA L40S)
• Optimised GPU utilisation with proper driver configuration
• Scalable infrastructure supporting vision-language models
• Comprehensive monitoring using Prometheus, Grafana, and DCGM
• Full observability for both application and hardware metrics

Data flow:

1. Inference request:
   • User → LoadBalancer → Gateway → NGINX Ingress → “Qwen3 VL” Service → vLLM Pod → GPU
   • Response follows reverse path with streaming support
2. Metrics collection:
   • vLLM Pods expose /metrics endpoint (port 8000)
   • DCGM Exporters expose GPU metrics (port 9400)
   • Prometheus scrapes both endpoints every 30 seconds
   • Grafana queries Prometheus for visualization
3. Load distribution
   • NGINX Ingress uses cookie-based session affinity
   • vLLM Service uses ClientIP session affinity
   • Anti-affinity ensures 1 pod per GPU node

Prerequisites

Before you begin, ensure you have:

• An OVHcloud Public Cloud account
• An OpenStack user with the Administrator role
• Hugging Face access – create a Hugging Face account and generate an access token
• kubectl already installed and helm installed (at least version 3.x)

🚀 Now you have all the ingredients, it’s time to deploy the recipe for Qwen/Qwen3-VL-8B-Instruct using vLLM and MKS!

Architecture guide: Native GPU deployment of vLLM on MKS with full stack observability

This reference architecture describes a Large Language Model deployment using vLLM inference server and Kubernetes, to enjoy the benefits of a service that’s both highly available and monitorable in real time.

Step 1 – Create MKS cluster and Node pools

From OVHcloud Control Panel, create a Kubernetes cluster using the MKS.

Navigate to: Public Cloud → Managed Kubernetes Service → Create a cluster

1. Configure cluster

Consider using the following configuration for the current use case:

• Name: vllm-deployment-l40s-qwen3-8b
• Location: 1-AZ Region – Gravelines (GRA11)
• Plan: Free (or Standard)
• Network: attach a Private network (e.g. 0000 - AI Private Network)
• Version: Latest stable (e.g. 1.34)

2. Create GPU Node pool

During the cluster creation, configure the vLLM Node pool for GPUs:

• Node pool name: vllm
• Flavor: L40S-90
• Number of nodes: 2
• Autoscaling: Disabled (OFF)

Why L40S-90?

• Cost-effective for single-model deployment (1 GPU per node)
• Sufficient RAM (90GB) for Qwen3-VL-8B model

You should see your cluster (e.g. vllm-deployment-l40s-qwen3-8b) in the list, along with the following information:

You can now set up the node pool dedicated to monitoring.

3. Create CPU Node pool

From your cluster, click on Add a node pool and configure it as follow:

• Node pool name: monitoring
• Flavor: B2-15
• Number of nodes: 1
• Autoscaling: Disabled (OFF)

✅ Note

Monitoring stack can run on GPU nodes if cost is a concern. Dedicated CPU node provides better isolation and resource management.

If the status is green with the OK label, you can proceed to the next step.

4. Configure Kubernetes access

Once your nodes have been provisioned, you can download the Kubeconfig file and configure kubectl with your MKS cluster.

# configure kubectl with your MKS cluster
export KUBECONFIG=/path/to/your/kubeconfig-xxxxxx.yml

# verify cluster connectivity
kubectl cluster-info
kubectl get nodes

Returning:

NAME                     STATUS   ROLES    AGE   VERSION
monitoring-node-xxxxxx   Ready    <none>   1d   v1.34.2
vllm-node-yyyyyy         Ready    <none>   1d   v1.34.2
vllm-node-zzzzzz         Ready    <none>   1d   v1.34.2

Before going further, add a label to the CPU node for monitoring workloads.

CPU_NODE=$(kubectl get nodes -o json | \
  jq -r '.items[] | select(.status.allocatable."nvidia.com/gpu" == null) | .metadata.name')
kubectl label node $CPU_NODE node-role=monitoring

Finally, check with the following command:

NAME                     GPU      ROLE
monitoring-node-xxxxxx   <none>   monitoring
vllm-node-yyyyyy         1        <none>
vllm-node-zzzzzz         1        <none>

Once both nodes are in Ready status, you can proceed to the next step.

Step 2 – Install GPU operator

To start, consider setting up the GPU operator.

✅ Note

This step is based on this OVHcloud documentation: Deploying a GPU application on OVHcloud Managed Kubernetes Service

1. Add NVIDIA helm repository and create namespace

Add NVIDIA helm repo:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

And create Namespace as follow.

kubectl create namespace gpu-operator

2. Install GPU operator with correct configuration

The GPU Operator must be configured with specific driver versions to ensure compatibility with vLLM containers.

However, the default installation uses recent drivers (580.x with CUDA 13.x) which are incompatible with vLLM containers (CUDA 12.x).

Solution: Force driver version 535.183.01 (CUDA 12.2).

helm install gpu-operator nvidia/gpu-operator \
  -n gpu-operator \
  --set driver.enabled=true \
  --set driver.version="535.183.01" \
  --set toolkit.enabled=true \
  --set operator.defaultRuntime=containerd \
  --set devicePlugin.enabled=true \
  --set dcgmExporter.enabled=true \
  --set dcgmExporter.image="dcgm-exporter" \
  --set dcgmExporter.version="3.1.7-3.1.4-ubuntu20.04" \
  --set gfd.enabled=true \
  --set migManager.enabled=false \
  --set nodeStatusExporter.enabled=true \
  --set validator.driver.enable=false \
  --set validator.toolkit.enable=false \
  --set validator.plugin.enable=false \
  --timeout 20m

✅ Note

Specifying the DCGM version may only be necessary if you encounter problems with the default image (e.g. ‘ImagePullBackOff’). If this is the case, add the following parameters:
--set dcgmExporter.repository="nvcr.io/nvidia/k8s"
--set dcgmExporter.image="dcgm-exporter"
--set dcgmExporter.version="3.1.7-3.1.4-ubuntu20.04"

kubectl get pods -n gpu-operator

Note that all pods should reach Running state in 5-10 minutes.

You can also check the GPU availability:

kubectl get nodes -o json | jq -r '.items[] | select(.status.allocatable."nvidia.com/gpu" != null) | "\(.metadata.name): \(.status.allocatable."nvidia.com/gpu") GPU(s)"'

Returning:

vllm-node-yyyyyy: 1 GPU(s)
vllm-node-zzzzzz: 1 GPU(s)

And you can test to run nvidia-smi:

DRIVER_POD=$(kubectl get pods -n gpu-operator -l app=nvidia-driver-daemonset -o name | head -1)
kubectl exec -n gpu-operator $DRIVER_POD -- nvidia-smi

If GPU tests are working properly, you can move on DCGM service configuration.

3. Configure DCGM service

Why is DCGM Exporter required?

DCGM (Data Centre GPU Manager) is NVIDIA’s official tool for monitoring GPUs in production. The goal is to be able to collect and display metrics from both GPU nodes.

The metrics provided are:

• DCGM_FI_DEV_GPU_UTIL – GPU utilisation (%)
• DCGM_FI_DEV_GPU_TEMP – GPU temperature (°C)
• DCGM_FI_DEV_FB_USED – VRAM used (MB)
• DCGM_FI_DEV_FB_FREE – Free VRAM (MB)
• DCGM_FI_DEV_POWER_USAGE – Power consumption (W)
• And 50+ other GPU metrics

Next, ensure DCGM service has the correct labels and port configuration:

kubectl patch svc nvidia-dcgm-exporter -n gpu-operator --type merge -p '{
  "metadata": {
    "labels": {
      "app": "nvidia-dcgm-exporter"
    }
  },
  "spec": {
    "ports": [
      {
        "name": "metrics",
        "port": 9400,
        "targetPort": 9400,
        "protocol": "TCP"
      }
    ]
  }
}'

Verify the endpoints (should show 2 IPs, one per GPU node).

kubectl get endpoints nvidia-dcgm-exporter -n gpu-operator

NAME                   ENDPOINTS                       AGE
nvidia-dcgm-exporter   x.x.x.x:9400,x.x.x.x:9400   17d

Step 3 – Deploy Qwen3 VL 8B with vLLM inference server

The deployment of the Qwen 3 VL 8B model on two L40S GPU nodes is carried out in several stages.

1. Create namespace and Hugging Face secret

Start by creating Namespace:

kubectl create namespace vllm

Next, you must retrieve your Hugging Face token and replace the HF_TOKEN value by your own:

export HF_TOKEN="hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Create your secret as follow:

kubectl create secret generic huggingface-secret \
  --from-literal=token=$HF_TOKEN \
  --namespace=vllm

Verify you obtain the following output by launching:

kubectl get secret huggingface-secret -n vllm

NAME                 TYPE     DATA   AGE
huggingface-secret   Opaque   1      14d

2. Create vLLM deployment configuration

First, you can create vllm-deployment-2nodes.yaml file.

Deploy vLLM:

kubectl apply -f vllm-deployment-2nodes.yaml

You can monitor the deployment (it should take 8-10 minutes for model download and loading).

kubectl get pods -n vllm -o wide -w

Expected output after 10 minutes:

NAME               READY  STATUS   RESTARTS  AGE  IP       NODE  
qwen3-vl-xxxx-yyy  1/1    Running  0         1d   X.X.X.X  vllm-node-yyyyyy
qwen3-vl-xxxx-zzz  1/1    Running  0         1d   X.X.X.X  vllm-node-zzzzzz

You can also check the container logs:

kubectl logs -f -n vllm <pod-name>

You should find in the logs: “Uvicorn running on http://0.0.0.0:8000“

Is everything installed correctly? Then let’s move on to the next step.

3. Add service label

Ensure service has the correct label for ServiceMonitor discovery.

kubectl label svc qwen3-vl-service -n vllm app=qwen3-vl --overwrite

You can now verify by launching the following command.

kubectl get svc qwen3-vl-service -n vllm --show-labels | grep "app=qwen3-vl"

Returning:

qwen3-vl-service  ClusterIP  X.X.X.X  <none> 8000/TCP 1d  app=qwen3-vl

Step 4 – Install NGINX ingress controller

⚠️ Moving beyond Ingress

Follow this tutorial if you want to use Gateway instead of Ingress.

1. Add helm repository and configure Ingress

First of all, add helm repository:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

Create configuration file with ingress-nginx-values.yaml.

Then, install NGINX Ingress:

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  -f ingress-nginx-values.yaml \
  --wait

Wait for LoadBalancer IP. The external IP assignment should take 1-2 minutes.

kubectl get svc -n ingress-nginx ingress-nginx-controller -w

Once <EXTERNAL-IP> is no longer , Ctrl+C and export it:

export EXTERNAL_IP=<EXTERNAL-IP>
echo "API URL: http://$EXTERNAL_IP"

2. Create vLLM Ingress resource

Next, create vLLM Ingress using vllm-ingress.yaml.

Apply it as follow:

kubectl apply -f vllm-ingress.yaml

You can now test different API calls to verify that your deployment is functional.

3. Test API

Firstly, check if the model is available:

curl http://$EXTERNAL_IP/v1/models | jq

{
  "object": "list",
  "data": [
    {
      "id": "qwen3-vl-8b",
      "object": "model",
      "created": 1772472143,
      "owned_by": "vllm",
      "root": "Qwen/Qwen3-VL-8B-Instruct",
      "parent": null,
      "max_model_len": 8192,
      "permission": [
        {
          "id": "modelperm-8fb35cdd3208b068",
          "object": "model_permission",
          "created": 1772472143,
          "allow_create_engine": false,
          "allow_sampling": true,
          "allow_logprobs": true,
          "allow_search_indices": false,
          "allow_view": true,
          "allow_fine_tuning": false,
          "organization": "*",
          "group": null,
          "is_blocking": false
        }
      ]
    }
  ]
}

Next, test inference using the following request:

curl http://$EXTERNAL_IP/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-vl-8b",
    "messages": [{"role": "user", "content": "Count from 1 to 10."}],
    "max_tokens": 100
  }' | jq '.choices[0].message.content'

"1, 2, 3, 4, 5, 6, 7, 8, 9, 10"

Great! You’re almost there…

Step 5 – Install Prometheus stack

Now, set up the monitoring stack that provides complete observability for application-level (vLLM) and hardware-level (GPU) metrics:

1. Add helm repository and create namespace

Add Prometheus helm repo:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Then, create the monitoring Namespace.

kubectl create namespace monitoring

2. Create Prometheus deployment configuration and installation

First, create prometheus.yaml file.

Install Prometheus stack:

helm install prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring \
  -f prometheus.yaml \
  --timeout 10m \
  --wait

Now, monitor its installation and wait until the pods are ready:

kubectl get pods -n monitoring -w

If all pods are running successfully, you can proceed to the next step.

3. Check that the installation is operational

First access Grafana in background:

kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80 &

Test Grafana health:

curl -s http://localhost:3000/api/health | jq

{
  "database": "ok",
  "version": "12.3.3",
  "commit": "2a14494b2d6ab60f860d8b27603d0ccb264336f6"
}

You can now access to Grafana locally via http://localhost:3000. You will have to use:

• Login: admin
• Password: Admin123!vLLM

Well done! You can now proceed to the configuration step.

Step 6 – Configure ServiceMonitors

The ServiceMonitors is used to tell Prometheus which endpoints to scrape for metrics.

1. Create vLLM ServiceMonitor

Retrieve the file from the GitHub repository: vllm-servicemonitor.yaml.

Next, apply and check that the ServiceMonitor vllm-metrics exists:

kubectl apply -f vllm-servicemonitor.yaml
kubectl get servicemonitor -n vllm

2. Create DCGM ServiceMonitor

First, create the dcgm-servicemonitor.yaml file.

Once again, apply and verify:

kubectl apply -f dcgm-servicemonitor.yaml
kubectl get servicemonitor -n gpu-operator

gpu-operator                  1d
nvidia-dcgm-exporter          1d
nvidia-node-status-exporter   1d

3. Configure Prometheus for Cross-Namespace discovery

Apply a patch to allow Prometheus to discover ServiceMonitors in all namespaces.

kubectl patch prometheus prometheus-kube-prometheus-prometheus -n monitoring --type merge -p '{
  "spec": {
    "serviceMonitorNamespaceSelector": {},
    "podMonitorNamespaceSelector": {}
  }
}'

Now you have to restart Prometheus.

1. Delete Prometheus pod to force configuration reload
2. Wait for Prometheus to restart

kubectl delete pod prometheus-prometheus-kube-prometheus-prometheus-0 -n monitoring

kubectl wait --for=condition=Ready \
  pod/prometheus-prometheus-kube-prometheus-prometheus-0 \
  -n monitoring \
  --timeout=180s

Wait about 2 minutes for discovery and finally, verify targets:

kubectl port-forward -n monitoring \
  prometheus-prometheus-kube-prometheus-prometheus-0 9090:9090 &

You can open in browser: http://localhost:9090/targets and search for:

• vllm
• dcgm

Note that the expected targets are:

• serviceMonitor/vllm/vllm-metrics/0 (2/2 UP)
• serviceMonitor/gpu-operator/nvidia-dcgm-exporter/0 (2/2 UP)

Step 7 – Create Grafana dashboards

In this final step, the goal is to create two Grafana dashboards to track both the software side with vLLM metrics and the hardware metrics that will monitor the GPU consumption and system.

1. vLLM application metrics

The dashboard provides insights into vLLM application performance, request handling, and resource utilization based on the following metrics:

This vLLM Grafana dashboard is composed of 23 panels:

The dashboard provides insights into LLM application performance, request handling, and resource utilisation based on the previous metrics.

Now create the dashboard using vllm-app-dashboard.json. Then, launch:

echo "Importing vLLM application dashboard..."
curl -X POST \
  'http://localhost:3000/api/dashboards/db' \
  -H 'Content-Type: application/json' \
  -u 'admin:Admin123!vLLM' \
  -d @vllm-app-dashboard.json | jq '.status, .url'

Next, you an access the vLLM dashboard and follow metrics in real time:

This dashboard is also essential to track hardware consumption for comprehensive monitoring.

2. GPU hardware metrics

Take advantage of the most useful DCGM metrics to check both the functioning and consumption of your hardware resources:

This hardware Grafana dashboard is composed of 13 panels with GPU hardware and system metrics. A detailed view is also available GPU util (%), temperature (°C), vRAM (GB) and power (Watt).

Please refer to hardware-dashboard.json by loading it as follows:

echo "Importing hardware dashboard..."
curl -X POST \
  'http://localhost:3000/api/dashboards/db' \
  -H 'Content-Type: application/json' \
  -u 'admin:Admin123!vLLM' \
  -d @hardware-dashboard.json | jq '.status, .url'

Finally, track resource consumption using this hardware dashboard:

Congratulations! Everything is working. You can now test your model and track the various metrics in real time.

Step 8 – LLM testing and performance tracking

Start by installing Python dependencies:

pip3 install openai tqdm

Replace the <EXTERNAL_IP> by the vLLM service external IP and launch the performance test thanks to the following Python code:

import time
import threading
import random
from statistics import mean
from openai import OpenAI
from tqdm import tqdm

APP_URL = "http://94.23.185.22/v1"
MODEL = "qwen3-vl-8b"

CONCURRENT_WORKERS = 500          # concurrency
REQUESTS_PER_WORKER = 10
MAX_TOKENS = 200                  # generation pressure

# some random prompts
SHORT_PROMPTS = [
    "Summarize the theory of relativity.",
    "Explain what a transformer model is.",
    "What is Kubernetes autoscaling?"
]

MEDIUM_PROMPTS = [
    "Explain how attention mechanisms work in transformer-based models, including self-attention and multi-head attention.",
    "Describe how vLLM manages KV cache and why it impacts inference performance."
]

LONG_PROMPTS = [
    "Write a very detailed technical explanation of how large language models perform inference, "
    "including tokenization, embedding lookup, transformer layers, attention computation, KV cache usage, "
    "GPU memory management, and how batching affects latency and throughput. Use examples.",
]

PROMPT_POOL = (
    SHORT_PROMPTS * 2 +
    MEDIUM_PROMPTS * 4 +
    LONG_PROMPTS * 6    # bias toward long prompts
)

# openai compliance
client = OpenAI(
    base_url=APP_URL,
    api_key="foo"
)

# basic metrics
latencies = []
errors = 0
lock = threading.Lock()

# worker
def worker(worker_id):
    global errors
    for _ in range(REQUESTS_PER_WORKER):
        prompt = random.choice(PROMPT_POOL)

        start = time.time()
        try:
            client.chat.completions.create(
                model=MODEL,
                messages=[{"role": "user", "content": prompt}],
                max_tokens=MAX_TOKENS,
                temperature=0.7,
            )
            elapsed = time.time() - start

            with lock:
                latencies.append(elapsed)

        except Exception as e:
            with lock:
                errors += 1

# run
threads = []
start_time = time.time()

print("\n-> STARTING PERFORMANCE TEST:")
print(f"Concurrency: {CONCURRENT_WORKERS}")
print(f"Total requests: {CONCURRENT_WORKERS * REQUESTS_PER_WORKER}")

for i in range(CONCURRENT_WORKERS):
    t = threading.Thread(target=worker, args=(i,))
    t.start()
    threads.append(t)

for t in threads:
    t.join()

total_time = time.time() - start_time

# results
print("\n-> BENCH RESULTS:")
print(f"Total requests sent: {len(latencies) + errors}")
print(f"Successful requests: {len(latencies)}")
print(f"Errors: {errors}")
print(f"Total wall time: {total_time:.2f}s")

if latencies:
    print(f"Avg latency: {mean(latencies):.2f}s")
    print(f"Min latency: {min(latencies):.2f}s")
    print(f"Max latency: {max(latencies):.2f}s")
    print(f"Throughput: {len(latencies)/total_time:.2f} req/s")

Returning:

-> STARTING PERFORMANCE TEST:
Concurrency: 500
Total requests: 5000

-> BENCH RESULTS:
Total requests sent: 5000
Successful requests: 5000
Errors: 0
Total wall time: 225.54s
Avg latency: 21.45s
Min latency: 6.06s
Max latency: 25.19s
Throughput: 22.17 req/s

Don’t forget to track GPU and vLLM metrics in your Grafana dashboards!

Conslusion

This reference architecture demonstrates a vLLM deployment on OVHcloud Managed Kubernetes Service (MKS) with comprehensive GPU monitoring. Benefits include:

• High Performance: GPU-accelerated inference with L40S
• Scalability: Kubernetes-native, horizontal scaling-ready
• Reliability: Health checks, auto-restart, monitoring
• API Compatibility: OpenAI-compatible endpoints
• Multimodality: Vision & text capabilities
• Full stack monitoring: Complete vLLM application and hardware dashboards

Going Further

Your current architecture is functional. However, if desired, it could be improved into a full production-ready solution.

Wish to take production hardening a step further?

Go further with the following enhancements:

1. Authentication & authorization
   • vLLM API authentication
   • Grafana authentication
   • Prometheus security
2. High availability & load balancing
   • Grafana high availability with multiple replicas and shared storage
   • Prometheus high availability
   • vLLM Horizontal Pod Autoscaling (HPA) based on custom metrics
3. Data persistence & backup
   • Prometheus long-term storage with persistent storage
   • Grafana Dashboard Backup
4. Observability enhancements
   • Distributed tracing by adding OpenTelemetry for request tracing
   • Alerting rules with production-ready alert rules

Introduction

Ethereum is quickly becoming known as one of the most efficient and flexible blockchain networks in the world, enabling financial organisations and individuals alike to create smart contracts that can power the likes of decentralised finance (DeFi) applications and NFT ecosystems. Ethereum is one of the foundations of Web3, providing a decentralised, scalable and secure network where builders can create the digital economy of the future.

But how do you get started? In this tutorial, we provide a guide to deploying and operating an Ethereum node on an OVHcloud public server. By the end of this guide, you will have a fully functional Ethereum node running on OVHcloud, following best practices for reliability and maintainability.

The security hardening and operational best practices required to fully protect an Ethereum node are beyond the scope of this tutorial. Users are strongly advised to implement additional security measures — such as firewall configuration, key management, and monitoring — according to their organizational requirements and industry best practices.

All set? Let’s get started.

Launching an instance

Navigate to the OVHcloud Control Panel, and under the Public Cloud section, select Instances. From there, click on Create an Instance to begin the provisioning process.

To run an Ethereum node reliably, the hardware specifications must meet the client software’s minimum requirements. According to the Ethereum Foundation documentation, an Ethereum node requires at least:

● Execution client: 2 CPU cores, 16 GB of RAM, and 1 TB of fast SSD storage.

● Consensus client: 2 CPU cores, 8 GB of RAM, and access to the same storage.

For production environments and long-term stability, higher specifications are strongly recommended. In this tutorial, we will provision an instance with 2 vCores and 30 GB of RAM, which satisfies the minimum combined requirements for running both the execution and consensus clients on a single machine.

Within the Memory Optimized category, locate the instance type named R2-30 and select it for deployment.

Next, select the geographic location for your instance. The choice of region may affect latency, network performance, and regulatory considerations. For the purposes of this tutorial, we will deploy the node in the Frankfurt data center, which provides low-latency connectivity within Europe and is well-suited for Ethereum node operations.

It is worth noting that maintaining nodes in different geographic regions contributes to the overall resilience and decentralization of the Ethereum network. Geographical diversity helps reduce the risk of localized outages and improves redundancy across the infrastructure.

Now, select the operating system image for your instance. For this tutorial, we will use Ubuntu 24.04 LTS.

Next, select the public SSH key that will be associated with your instance. This key will be installed on the server during provisioning and will serve as the primary authentication method for secure remote access. After the instance is launched, you will be able to connect to it via SSH using the corresponding private key. This approach eliminates the need for password-based logins and significantly enhances security by enforcing key-based authentication.

Assign a descriptive name to your instance (e.g., eth-node-fra-01) following your organization’s naming convention. If your workflow uses tags or labels, add ones that identify the role (execution/consensus), environment (prod/stage), and region (FRA). OVHcloud also allows attaching a post-installation script (cloud-init user data) to automate provisioning; however, this tutorial proceeds step-by-step, so leave that field empty.

For the purposes of this tutorial, we will simply assign the instance the name OVHnode.

Configure the network access by selecting Public mode, which will assign the instance a public IP address and enable external connectivity. This setting is required for the node to participate in the Ethereum network. Next, choose your preferred billing method.

Finally, click on Create an Instance to launch the deployment process. OVHcloud will provision the server with the selected configuration, and within a few minutes, the instance will be available and running. At this point, your Ethereum node host environment is ready for initial access and further configuration.

Adding Storage

The next step is to provision persistent storage for the Ethereum blockchain data. In the OVHcloud Control Panel, navigate to the Block Storage section from the side menu, and click on Create a Volume. This volume will serve as the primary data store for the Ethereum chain, ensuring durability and scalability independent of the compute instance.

When creating the storage volume, ensure that you select the same region as your compute instance. This is essential to guarantee low-latency access and to allow the volume to be attached directly to your node without cross-region performance penalties.

OVHcloud provides three categories of block storage volumes:

• Classic HDD – 500 IOPS guaranteed.
• High-Speed SSD – up to 3,000 IOPS.
• High-Speed Gen2 – up to 20,000 IOPS.

Running an Ethereum node requires high-performance storage due to the constant read and write operations needed to synchronize the blockchain and access block and state data. For this reason, we strongly recommend selecting a High-Speed Gen2 volume, which delivers the necessary throughput and input/output operations per second (IOPS) to ensure stable node performance.

Both the Ethereum Execution Layer (EL) client and the Consensus Layer (CL) client require significant disk capacity to store blockchain data, state, and historical records. A minimum of 2 TB of storage is recommended to operate a full mainnet node reliably. When creating the block storage volume in OVHcloud, set the capacity to 2 TB and select the High-Speed Gen2 option to ensure sufficient performance for synchronization and long-term operation.

Assign a descriptive name to the storage volume to simplify management and identification. For example, you may name it chaindata to clearly indicate its role as the primary data store for the node.

Once all parameters have been configured — including the region, storage type, capacity, and name — click on Create Volume. OVHcloud will provision the block storage resource, which will then be available to attach to your Ethereum node instance.

Mounting the Volume

After the new volume appears as available in the OVHcloud Control Panel, attach it to your Ethereum node instance. To do this, open the ⋮ (more options) menu next to the volume entry and select Attach to an Instance. From the list of instances, choose the node you previously created. The volume will then be linked to that instance and accessible as an additional block device.

Now, establish a secure connection to your server via SSH. Use the following command from your local terminal, replacing IPaddress with the public IP assigned to your instance:

ssh ubuntu@IPaddress

By default, OVHcloud instances provisioned with the Ubuntu image create a user named ubuntu, which you should use for the initial connection. Authentication will be handled through the SSH key you configured during instance creation.

Once connected to the instance, run the following command to list all available block devices:

lsblk

This will display a tree view of the system’s storage devices, including the root disk and the newly attached block storage volume. Identify the additional device (e.g., /dev/sdb) that corresponds to the 2 TB volume you created in OVHcloud. This device will later be formatted and mounted to store the Ethereum blockchain data.

Next, create a partition on the newly attached volume. Replace /dev/sdb with the device name identified in the previous step if it differs. Execute:

sudo fdisk /dev/sdb

This command will open the partitioning utility for the selected block device. From there, you can create a new primary partition that spans the entire disk. Once complete, the partition will typically be available as /dev/sdb1.

Once the partition has been created (e.g., /dev/sdb1), format it with the ext4 filesystem so it can be mounted and used by the operating system. Run the following command:

sudo mkfs.ext4 /dev/sdb1

This will initialize the partition with an ext4 filesystem, which is a stable and widely supported choice for storing Ethereum chain data.

Now, create a dedicated directory to serve as the mount point for the formatted volume, then mount it and verify that it has been successfully attached to the filesystem. Execute the following commands:

sudo mkdir -p /mnt/chaindata

sudo mount /dev/sdb1 /mnt/chaindata

df -h

• mkdir -p /mnt/chaindata creates the mount directory (using -p ensures no error if intermediate directories are missing).
• mount /dev/sdb1 /mnt/chaindata mounts the formatted partition to the directory.
• df -h displays all mounted filesystems in a human-readable format, allowing you to confirm that /dev/sdb1 is correctly mounted at /mnt/chaindata with the expected capacity (approximately 2 TB).

At this point, your disk is mounted and ready for use. However, the configuration is not persistent: if the server restarts, the volume will need to be mounted manually. To ensure the volume is mounted automatically at boot, we must configure it in the /etc/fstab file.

First, retrieve the UUID (Universally Unique Identifier) of your volume by running:

sudo blkid

This command lists all block devices and their associated attributes. Identify the entry corresponding to your new partition (e.g., /dev/sdb1) and copy the value of its UUID field, which will be used in the fstab configuration.

Next, edit the /etc/fstab file to configure the automatic mount. Open the file with your preferred text editor, for example:

sudo nano /etc/fstab

Then add the following line at the end of the file, replacing the UUID with the one obtained from the previous blkid command:

UUID=e146e498-bba2-4574-9b47-b54fffea77e7 /mnt/chaindata ext4 nofail 0 0

This entry ensures that the partition will be mounted at /mnt/chaindata automatically on every system boot. The nofail option allows the system to continue booting even if the device is unavailable.

Your storage volume is now fully configured and ready to be used for storing Ethereum blockchain data. With the automatic mount entry in place, the system will make the volume available at /mnt/chaindata on every reboot, ensuring a stable and persistent data directory for your node.

Create a dedicated user

Next, create a dedicated user account to manage all Ethereum node operations. This practice improves security by separating node processes from the default system user. Run the following commands:

sudo useradd -s /bin/bash -d /home/node_admin/ -m -G sudo node_admin

echo 'node_admin:MySuperPassword123' | sudo chpasswd

sudo mkdir -p /home/node_admin/.ssh

• useradd creates a new user named node_admin, with a home directory, bash shell, and membership in the sudo group.
• chpasswd sets an initial password for the new user (replace with a strong secret or configure key-based login).
• mkdir -p creates the .ssh directory for SSH configuration in the user’s home directory.

Now, configure SSH key-based authentication for the new user by adding your public SSH key to the authorized_keys file. Replace the placeholder with your actual public key:

sudo sh -c "echo 'My-public-SSH-key' > /home/node_admin/.ssh/authorized_keys"

This command creates the authorized_keys file under /home/node_admin/.ssh/ and writes your public key into it, allowing secure, passwordless login as the node_admin user.

Ethereum Preliminaries

Operating a fully functional Ethereum node requires the coordinated operation of two key software components:

1. Execution Client (EL) – responsible for processing transactions and maintaining the Ethereum state.

2. Consensus Client (CL) – responsible for reaching consensus with the rest of the network through the Ethereum proof-of-stake protocol.

These two components must run in tandem and communicate securely to maintain synchronization with the Ethereum mainnet.

The Ethereum ecosystem supports multiple client implementations, each developed independently but compliant with the Ethereum specification. The most widely used options include:

Execution Clients (EL):

• Geth
• Nethermind
• Reth
• Besu
• Erigon

Consensus Clients (CL):

• Lighthouse
• Prysm
• Teku
• Nimbus
• Lodestar

For this guide, we will use the following combination:

● Execution Client: Nethermind

● Consensus Client: Lighthouse

Installing Nethermind (Execution Client)

Step 1: Add the Nethermind APT Repository

To install Nethermind via APT, begin by adding the official repository:

sudo add-apt-repository ppa:nethermindeth/nethermind

If the above command is not found, install the required tools first:

sudo apt-get install software-properties-common

Step 2: Update the Package Index

Refresh your package list to include packages from the newly added repository:

sudo apt-get update

⚠️This may take a few minutes depending on your system and network speed.

Step 3: Install Nethermind

Now install the Nethermind binary:

sudo apt-get install nethermind -y

Installing Lighthouse (Consensus Client)

Step 1: Download the Latest Stable Release

Navigate to the Lighthouse GitHub Releases page and locate the latest stable release.

As of September 29, 2025, version 8.0.0 is marked as a Pre-release, so we will use the stable version 7.1.0.

Use the following curl command to download the Lighthouse client binary archive:

curl -LO https://github.com/sigp/lighthouse/releases/download/v7.1.0/lighthouse-v7.1.0-x86_64-unknown-linux-gnu.tar.gz

Step 2: Extract the Archive

Once downloaded, extract the archive:

tar -xvf lighthouse-v7.1.0-x86_64-unknown-linux-gnu.tar.gz

This will place the lighthouse binary in your current directory.

Step 3: Verify and Move the Binary

Test the binary to ensure it is working:

./lighthouse –version

Move it to a directory included in your system’s $PATH for global access:

sudo cp lighthouse /usr/bin

Create the JWT Secret File

A shared JWT secret is required for secure authenticated communication between the execution and consensus clients.

Step 1: Create a Secrets Directory

sudo mkdir -p /secrets

Step 2: Generate the JWT Token

openssl rand -hex 32 | tr -d "\n" | sudo tee /secrets/jwt.hex > /dev/null

You should now have the file /secrets/jwt.hex containing a 32-byte hexadecimal secret.

Using screen for Session Persistence

When running on a remote server (such as an OVH cloud instance), any disconnection from your SSH session will terminate running processes unless they are managed through tools like screen.

Check if screen is installed:

screen –version

If not installed:

sudo apt-get install screen

Setting Ownership for /mnt/chaindata

When running Ethereum clients (Nethermind and Lighthouse), it’s essential that the user executing the commands has the necessary access to the data directory. To avoid permission issues and maintain security, you should assign ownership of the previously mounted directory to your current user.

sudo chown $USER:$USER /mnt/chaindata

This command sets the user and group ownership of /mnt/chaindata to the currently logged-in user. It ensures that you (and your Ethereum clients, if run under your user account) have full access to read, write, and modify files in this directory.

Now we are ready to launch both the execution and consensus clients in separate screen sessions for persistent background operation.

Launching Nethermind (Execution Client)

Step 1: Create a Screen Session

screen -S nethermind

Step 2: Run Nethermind

nethermind -c mainnet \ 
--data-dir /mnt/chaindata/nethermind \ 
--JsonRpc.Enabled true \ 
--HealthChecks.Enabled true \ 
--HealthChecks.UIEnabled true \ 
--JsonRpc.EngineHost=127.0.0.1 \ 
--JsonRpc.EnginePort=8551 \ 
--JsonRpc.JwtSecretFile=/secrets/jwt.hex 

You should see logs indicating the client is running. Eventually, the message:

Waiting for Forkchoice message from Consensus Layer

will appear, indicating the execution client is waiting to pair with the consensus client.

Step 3: Detach the Session

Press: Ctrl-a then d to detach from the session and return to the main shell.

Step 4: List Active Sessions (Optional)

screen -ls

To reattach later:

screen -r nethermind

Launching Lighthouse (Consensus Client)

Step 1: Create a New Screen Session

screen -S lighthouse

Step 2: Run Lighthouse Beacon Node

lighthouse bn \ 
--network mainnet \ 
--execution-endpoint http://127.0.0.1:8551 \ 
--execution-jwt /secrets/jwt.hex \ 
--checkpoint-sync-url https://mainnet.checkpoint.sigp.io \ 
--http \ 
--datadir /mnt/chaindata/lighthouse

After some initial setup, Lighthouse should begin syncing with the network.

Step 3: Detach the Session

Use the same key combination: Ctrl-a then d.

Verifying Synchronization Between EL and CL

At this stage, both the execution client (Nethermind) and the consensus client (Lighthouse) should be running in separate screen sessions. To confirm that they are properly connected and synchronization is underway, reattach to the Nethermind session and inspect the logs.

Step 1: Reattach to the Nethermind Session

screen -r nethermind

This command brings you back into the Nethermind screen session, where you can observe real-time logs.

Step 2: Check for Communication Messages

If Lighthouse is running and connected correctly, Nethermind’s logs should no longer display:

Waiting for Forkchoice message from Consensus Layer

Instead, you should see logs indicating that the Engine API communication has been established and blocks are being processed. Look for messages like:

Received ForkChoice: ...
Syncing...

These logs confirm that Nethermind is receiving block proposals and fork choice updates from Lighthouse and that the node is syncing correctly with the Ethereum mainnet.

Conclusion

And you’re done! You have deployed a fully functional Ethereum node on OVHcloud.

While this guide focused on the technical deployment, it is important to complement the setup with proper security hardening, monitoring, and maintenance practices to ensure long-term stability. With the foundation now in place, you can extend the node’s functionality, integrate it into larger infrastructures, or use it as a base for research, development, and staking operations.

This is the first guide in our mini-series and will shortly be followed by a tutorial on how to deploy an Ethereum node on a bare metal server and monitor it in real-time. Stay tuned for more.

• 👤 Invitée : Alexandre Touret
  • Bluesky : @touret.info
  • LinkedIn : https://www.linkedin.com/in/atouret/
• 🗓️ Date d’enregistrement : 27 février 2026
• 🎧 Lien vers l’épisode

👤 Présentation d’Alexandre – ⏱️ 0″37s

📰 News Techs 

🤖 Intelligence Artificielle – ⏱️ 15″40s

Spotify indique que ses développeurs ne codent plus depuis décembre grâce à l’IA

• https://developers.slashdot.org/story/26/02/13/1834228/spotify-says-its-best-developers-havent-written-a-line-of-code-since-december-thanks-to-ai

OpenClaw

• https://openclaw.ai/
• https://www.infostealers.com/article/clawdbot-the-new-primary-target-for-infostealers-in-the-ai-era/  
• https://www.youtube.com/watch?v=F0EammZyMaA

OpenClaw founder Peter Steinberger is joining OpenAI

• https://www.theverge.com/ai-artificial-intelligence/879623/openclaw-founder-peter-steinberger-joins-openai

IA au quotidien – Paralléliser sa production agentique de code

• https://www.linkedin.com/pulse/claude-code-au-quotidien-parall%C3%A9liser-ses-t%C3%A2ches-fr%C3%A9d%C3%A9ric-camblor-jqjpe/?trackingId=h9dz1qUyRxeD6qwWMb9vlg%3D%3D

👩‍💻 Développement – ⏱️ 48″40s

Java has evolved.Your code can too

• https://javaevolved.github.io/

Claude code skills

• https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf
• https://bsky.app/profile/k33gorg.bsky.social/post/3me6zw6klkk2d

The Augmented Developer: My Journey with Cursor CLI

• https://david.pilato.fr/posts/2026-02-06-the-augmented-developer/

L’ANSSI révise sa doctrine vis-à-vis du logiciel libre

• https://linuxfr.org/news/l-anssi-revise-sa-doctrine-vis-a-vis-du-logiciel-libre

👥 Sociétal – ⏱️ 1h”02″30s

IBM triple le nombre de jeunes diplômés dans leur recrutement

• https://fortune.com/2026/02/13/tech-giant-ibm-tripling-gen-z-entry-level-hiring-according-to-chro-rewriting-jobs-ai-era/

Forklifts Require Training : Sleepwalking into labor collapse

• https://www.zacsweers.dev/forklifts-require-training/

🎤 Conférences / meetup – ⏱️ 1h”13″20s

• https://developers.events/

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

Since autumn 2025, the global memory market has been going through a major disruption. Although barely noticeable to end users, these developments are radically changing the cost of computer hardware and, as a direct result, the cost of the cloud.

This article will decipher this structural crisis, its real-life impacts, and the strategic choices that OVHcloud is implementing to mitigate its effects.

An industrial shift towards GPUs

Globally, the three major memory manufacturers have redirected a significant portion of their production capacity to meet the massive demand for GPUs, particularly for AI-related and high-bandwidth computing applications.

This reallocation took place without a corresponding reduction in the historical demand for RAM and storage, generating pressure on several market segments simultaneously.

The consequences of this were immediate and noticeable:

• pressure on supply, with reduced stock and extended lead times
• continuous rise in RAM and disk prices since September 2025
• long-term market instability, which is not expected to find a new balance until late 2026

A sustained inflation of memory components

Even after the market stabilises, prices are not expected to return to their historical levels before 2028, the amount of time needed for new production capacities to become truly operational.

This development profoundly disrupts the economic fundamentals of computer hardware, both for on-premises infrastructures and for the cloud. Depending on configurations, the prices related to RAM and storage could increase by 15% to 300% compared to 2025 prices, depending on the volumes of memory and disk capacity deployed.

This change of scale is both abrupt and unprecedented, with no recent equivalent in the global market.

A market under pressure, even with higher prices

Paradoxically, the rise in prices is not enough to secure the availability of components. Currently, to guarantee the delivery of their desired volume of RAM or disks, cloud providers need to order up to 12 months in advance, without being told the final price at the time of purchase.

In practice, prices are only communicated one to two months after delivery, depending on the changes in supply and demand during the quarter in question. This uncertainty places unprecedented pressure on industry players and cloud providers, simultaneously affecting production and distribution.

Towards a new global balance of demand

This situation will inevitably have repercussions on the volumes ordered. Some customers will find the prices too high and limit their investments, while others, lacking alternatives, will continue to place orders regardless.

This interplay of opposing forces should lead to a new global balance, but at a significantly higher price point. Current projections anticipate a 250% to 300% increase in the price of RAM by the end of 2026, compared to September 2025.

Our strategy to soften the blow

In light of this reality, OVHcloud has chosen not to automatically pass on the entire price increase of components to its customers.

For the cloud deployed between 2026 and 2028 (including Public Cloud, Private Cloud, and Bare Metal), the average price increase will be limited – between 9% and 11% – despite significantly higher RAM and disk costs.

To offset this gap, a moderate increase of 2% to 6% is planned for solutions deployed before 2025, depending on the age of the equipment, as well as a change in IPv4 pricing. The latter should not have a significant impact on our customers’ budgets, as the cost of IP addresses is a small share compared to other resources in a cloud project.

Our objective is clear: to maintain pricing consistency across the entire range from 2021 to 2028, and to prepare for a gradual return to normal in 2029.

Continuous investments and developing solutions

Beyond pricing adjustments, this period will be characterised by sustained investments in our solutions and in the customer experience.

Despite the strong pressure from rising component costs, we are continuing to develop our services to provide more value to our customers.

In practical terms, this will result in:

• a gradual strengthening of support mechanisms
• an increase in resources included in certain ranges
• a modernization of our computing and storage infrastructures

These initiatives demonstrate our commitment to not reduce this period to merely a consequence of cost increases, but to maintain a dynamic of improving our services, even in a constrained economic context.

Time frame and implementation procedures

Our clients have already received emails detailing the precise impacts on their services. The new prices will come into effect on 1 April 2026.

Until that date, it is possible to renew services at the current rates for a duration of up to 2 years. In all cases, the new prices will only apply at the end of the current contractual period.

A time of uncertainty and a strategic advantage

We are going through an exceptionally unpredictable period, where market visibility rarely lasts longer than one to two weeks. There remains hope that prices will stabilize on a long-term basis from 2026, so that we can avoid further unfavorable announcements.
In this tense context, having a global supply chain and two internal production facilities is a major strategic advantage. This allows us to continue receiving components and producing servers, while the memory shortage affects a large part of the market.

Our Prices

You will find below our new pricing:
– Public Cloud: Prices below are displayed on an hourly basis and with Linux OS. Please, find on our Prices web page our monthly-consumed virtual machine instances (b2, c2, r2) and Savings Plan options (b3, c3, r3) as well as prices with Windows licences.
– All our VPS, Floating IPs, and Additional IP pricing.
– Bare Metal: The displayed prices correspond to a 1-month commitment; additional discounts apply for 12- or 24-month prepayments. The prices for options are for new orders only. The renewal of options, which has been communicated by email to our customers, will be limited to +10% for disk options and +15% for RAM options.

For existing subscriptions renewed before April 1st, you can secure your current pricing for the full duration of the commitment you choose, effective from your renewal date.

Please note that the following product categories are not affected by our pricing evolution:
– Public Cloud – Compute : Cloud GPUs and Metal Instances
– Public Cloud – Container : Managed Kubernetes, Managed Registries & Managed Rancher
– Public Cloud – Network : Load Balancer, Gateway. Public and Private network traffic remains included.
– Public Cloud – Storage : Object Storage, Block Storage.
– Public Cloud – Analytics : Data Platform
– Public Cloud – AI & Machine Learning : AI Solutions (AI Notebook, AI Training, AI Deploy) and AI Endpoints
– Public Cloud – Quantum : Emulators & QPUs
– Bare Metal : Kimsufi et SoYouStart ranges
– Bare Metal : All storage (Veeam Enterprise plus, HYCU, Back-up Agent, NAS-HA, Cloud Disk Array)
– Private Cloud : All VMware offers, all storage offers (Veeam Enterprise plus, HYCU, Back-up Agent)

Un basculement industriel vers les GPU

À l’échelle mondiale, les trois grands fabricants de mémoire ont réorienté une part importante de leurs capacités de production pour répondre à la demande massive en GPU, en particulier pour les usages liés à l’IA et au calcul haute performance.

Cette réallocation s’est effectuée sans réduction équivalente de la demande historique en mémoire vive et en stockage, générant une pression simultanée sur plusieurs segments du marché.

Les conséquences sont immédiates et visibles :

• tension sur l’offre, avec des stocks réduits et des délais d’approvisionnement allongés ;
• hausse continue des prix de la RAM et des disques depuis septembre 2025 ;
• instabilité durable du marché, qui ne devrait retrouver un nouvel équilibre qu’à l’horizon fin 2026.

Une inflation durable des composants mémoire

Même après la stabilisation du marché, les prix ne devraient pas retrouver leurs niveaux historiques avant 2028, le temps nécessaire pour que de nouvelles capacités de production soient réellement opérationnelles.

Cette évolution bouleverse profondément les fondamentaux économiques du matériel informatique, tant pour les infrastructures on-premise que pour le cloud. Selon les configurations, l’impact tarifaire lié à la RAM et au stockage pourrait atteindre +15 % à +300 % par rapport aux prix de 2025, en fonction des volumes de mémoire et de capacité disque déployés.

Ce changement d’échelle est à la fois brutal et inédit, sans équivalent récent sur le marché mondial.

Un marché sous tension même à prix élevé

Paradoxalement, la hausse des prix ne suffit pas à sécuriser la disponibilité des composants. Aujourd’hui, pour garantir la livraison de volumes de RAM ou de disques, il est nécessaire pour les fournisseurs de cloud de passer commande jusqu’à 12 mois à l’avance, sans connaître le prix final au moment de l’achat.

En pratique, les tarifs ne sont communiqués qu’un à deux mois après la livraison, selon l’évolution de l’offre et de la demande sur le trimestre concerné. Cette incertitude exerce une pression inédite sur les acteurs industriels et les fournisseurs de cloud, affectant simultanément la production et la distribution.

Vers un nouvel équilibre mondial de la demande

Cette situation aura inévitablement des répercussions sur les volumes commandés. Certains clients jugeront les prix trop élevés et limiteront leurs investissements, tandis que d’autres, faute d’alternative, continueront à passer commande malgré tout.

Ce jeu de forces opposées devrait conduire à un nouvel équilibre mondial, mais à un niveau de prix nettement supérieur. Les projections actuelles anticipent une augmentation de la RAM de +250 % à +300 % à la fin 2026, par rapport à septembre 2025.

Notre stratégie pour amortir le choc

Face à cette réalité, OVHcloud a choisi de ne pas répercuter automatiquement l’intégralité de la hausse des composants sur ses clients.

Pour le cloud déployé entre 2026 et 2028 — incluant le Public Cloud, le Private Cloud et le Bare Metal — l’augmentation moyenne des prix sera limitée, entre +9 % et +11 %, malgré des coûts de RAM et de disques nettement plus élevés.

Pour compenser cet écart, un ajustement modéré est prévu sur les offres déployées avant 2025, de +2 % à +6 %, en fonction de l’ancienneté du matériel, ainsi qu’une évolution des tarifs des IPv4. Cette dernière ne devrait pas avoir d’impact significatif sur le budget de nos clients, le coût des adresses IP représentant une part limitée par rapport aux autres ressources d’un projet cloud.

Notre objectif est clair : préserver une cohérence tarifaire sur l’ensemble des gammes 2021-2028 et préparer un retour progressif à la normale en 2029.

Investissements continus et évolution des offres

Au-delà des ajustements tarifaires, cette période se caractérise par des investissements soutenus dans nos offres et dans l’expérience client.

Malgré la forte pression liée à l’augmentation des coûts des composants, nous continuons à faire évoluer nos services afin d’apporter davantage de valeur à nos clients.

Concrètement, cela se traduit par :

• un renforcement progressif des dispositifs de support ;
• une augmentation des ressources incluses dans certaines gammes ;
• une modernisation de nos infrastructures de calcul et de stockage.

Ces initiatives témoignent de notre volonté de ne pas réduire cette phase à une simple répercussion des hausses de coûts, mais de maintenir une dynamique d’amélioration de nos services, même dans un contexte économique contraint.

Calendrier et modalités d’application

Nos clients ont déjà reçu des emails détaillant les impacts précis sur leurs services. Les nouveaux tarifs seront appliqués à compter du 1^er avril 2026.

Jusqu’à cette date, il est possible de renouveler les services aux tarifs actuels pour une durée pouvant aller jusqu’à 2 ans. Dans tous les cas, les nouveaux prix ne s’appliqueront qu’à l’issue de la période d’engagement en cours.

Une période d’incertitude et un avantage stratégique

Nous traversons une phase exceptionnellement imprévisible, où la visibilité sur les marchés dépasse rarement une à deux semaines. L’espoir demeure que les prix se stabilisent durablement dès 2026, afin d’éviter de nouvelles annonces défavorables.

Dans ce contexte tendu, disposer d’une chaîne d’approvisionnement mondiale et de deux usines de production internes constitue un avantage stratégique majeur. Cela nous permet de continuer à recevoir des composants et à produire des serveurs, là où la pénurie de mémoire touche une grande partie du marché.

Nos tarifs

Vous trouverez ci-dessous nos nouveaux tarifs :
– Public Cloud : les prix ci-dessous sont affichés à l’heure et avec OS Linux. Vous trouverez sur notre page Tarifs les prix des instances de machines virtuelle consommées au mois (b2, c2, r2) ou en Savings Plan (b3, c3, r3) ainsi que les tarifs avec licences Windows.
– Tous nos tarifs VPS, Floating IPs & IP additionnelles.
– Bare Metal : les prix affichés correspondent à un engagement d’un mois ; des remises supplémentaires sont appliquées en cas de prépaiement sur 12 ou 24 mois. Les prix des options sont ceux des nouvelles commandes uniquement. Le renouvellement d’options qui a été communiqué par email à nos clients sera quant à lui limité à +10% sur les options de disques, +15% sur les options de RAM.

Pour toutes les souscriptions existantes renouvelées avant le 1er avril, vous pouvez conserver votre tarif actuel pendant toute la durée d’engagement choisie, à compter de votre date de renouvellement.

Veuillez noter que les catégories de produits suivantes ne sont pas concernées par l’évolution de nos tarifs :
– Public Cloud – Compute : Cloud GPUs et Metal Instances
– Public Cloud – Container : Managed Kubernetes, Managed Registries & Managed Rancher
– Public Cloud – Network : Load Balancer, Gateway. Le trafic réseau Public et Privé reste inclus.
– Public Cloud – Storage : Object Storage, Block Storage.
– Public Cloud – Analytics : Data Platform
– Public Cloud – AI & Machine Learning : AI Solutions (AI Notebook, AI Training, AI Deploy) et AI Endpoints
– Public Cloud – Quantum : Emulators & QPUs
– Bare Metal – stockage : Veeam Enterprise Plus, HYCU, Back-up Agent, NAS-HA, Cloud Disk Array
– Bare Metal : Gammes Kimsufi et SoYouStart
– Private Cloud : offres VMware et offres de stockage (Veeam Enterprise plus, HYCU, Back-up Agent)