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

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

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

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

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

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

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

Ce que vous allez automatiser dans ce script :

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

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

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

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

2. Utilisation de Terraform pour le déploiement

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

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

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

Son utilisation :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There are two steps to automating the deployment:

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

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

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

What you will automate in this script:

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

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

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

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

2. Using Terraform for deployment

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

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

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

Its usage:

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

This is what will ensure data persistence.

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

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

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

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

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

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

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

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

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

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

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

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

1. Prerequisites: securing the network part

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

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

Change the line “bind-addr” as follows: 

bind-addr: 127.0.0.1:8080

Then restart the service.

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

2. Implement the reverse proxy

Here, you have two choices:

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

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

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

Installation (Debian/Ubuntu)

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

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

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

• Simple configuration only on HTTP port (80)

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

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

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

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

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

3. Network and firewall

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

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

Start by opening the ports related to the functional services.

Activate the firewall:

Check the implementation of the rules.

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

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

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

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

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

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

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

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

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

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

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

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

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

Modifiez la ligne « bind-addr » comme suit :

bind-addr: 127.0.0.1:8080

Puis redémarrez le service.

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

2. Implémenter le reverse proxy

Ici, vous avez deux choix :

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

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

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

Installation (Debian/Ubuntu

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

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

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

• Configuration simple uniquement sur le port HTTP (80)

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

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

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

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

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

3. Réseau et pare-feu

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

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

Commencez par ouvrir les ports relatifs aux services fonctionnels.

Activez le firewall :

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Déploiement de l’instance

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

2. Installation de la partie applicative

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

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

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

3. Validation de la configuration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Deploying the instance

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

2. Installing the application element

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

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

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

3. Validate the configuration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mia Experts is a new generation medical software platform designed by a physician, for physicians. From the very beginning, the product was built to integrate artificial intelligence in a way that is useful, secure, and aligned with the realities of medical practice.

Today, many doctors spend a significant part of their day dealing with administrative tasks rather than focusing on patient care and clinical decision-making. Existing medical software is often outdated, poorly designed, and disconnected from how physicians actually work.

Mia Experts aims to change that. By leveraging artificial intelligence, the platform automates repetitive tasks and structures medical data in a meaningful and usable way. The goal is simple: give physicians back their time.

The solution primarily targets private practitioners, particularly in general medicine and surgical specialties, where efficient data management, reliability, and time savings are critical.

Built from Real Medical Experience

The idea behind Mia Experts originated from the daily experience of Vincent Salabi, a surgeon who repeatedly encountered the same issue: medical software that was slow, repetitive, and time-consuming.

Instead of helping doctors, these tools often added friction to their workflow.

At the same time, a major technological shift was occurring: artificial intelligence was becoming accessible in a way that could be deployed securely and within a sovereign regulatory framework.

Mia Experts was born from the collaboration of three co-founders with complementary expertise — medical, technical, and entrepreneurial — united by a shared ambition: to fundamentally rethink the physician’s digital workspace.

Early Milestones and Key Achievements

From the earliest stages, several key milestones helped shape the development of Mia Experts.

One of the first successes was designing the software architecture. The team built a simple, modular, and scalable architecture capable of intelligently interacting with both patient and physician data.

The objective was clear: eliminate unnecessary repetition, ensure every piece of data has meaning, and enable reliable data usage — whether for prescription generation or reducing medical errors.

Operating in the highly regulated healthcare sector also required building an infrastructure compliant with Health Data Hosting (HDS) regulations. Mia Experts chose OVHcloud, ensuring health data sovereignty and providing a robust and secure cloud foundation.

Infrastructure management is handled in partnership with Lecpac Consulting, allowing the team to meet regulatory requirements while focusing on product development and innovation.

Another major milestone came through early presentations at medical conferences, particularly in orthopedic and urological surgery. The response from physicians was extremely positive. The software’s usability and clinical logic quickly generated word-of-mouth interest — even among doctors who had not been directly approached.

Mia Experts also achieved several regulatory and technological milestones:

• LAP certification for prescription software, obtained in collaboration with healthtech company Posos
• INSi compliance, enabling integration with national health identity standards

Even before official product launch, the startup received around 50 pre-orders purely through demonstrations and conference discussions.

The platform is now entering its beta testing phase, with the first deployments planned soon.

Core Values Driving the Product

The development of Mia Experts is guided by a set of strong principles:

• Simplicity – intuitive interfaces designed for real medical workflows
• Pragmatism – AI must deliver measurable time savings
• Data sovereignty – full control over hosting and infrastructure
• Health data security – non-negotiable protection standards
• Intelligent data structuring – ensuring reliable and actionable medical information

Business, Technical and Regulatory Complexity

Building a medical software platform involves navigating a unique combination of business, technological, and regulatory challenges.

From a business perspective, the first hurdle was securing funding while preserving technological independence. Mia Experts achieved this through an initial funding round involving physician investors, complemented by support from Bpifrance and the French Tech Grant program.

On the technical side, the strict healthcare regulatory environment posed significant challenges. Compliance with HDS standards required implementing strong guarantees around security, traceability, service availability, and access governance from the very beginning.

Another critical challenge involved health data interoperability. Medical data must follow standardized national frameworks and coding systems. Mia Experts needed to structure and transform this data so it could interact seamlessly with national health services such as secure messaging systems and health data platforms.

Yet the biggest challenge was balancing all these constraints with a smooth user experience.

The ambition was never to create software that was simply compliant but difficult to use. Instead, the goal was to design a platform that remains intuitive, efficient, and truly supportive of physicians’ daily work.

Why Mia Experts Chose the Cloud

Cloud infrastructure quickly became a natural choice for the project.

First, artificial intelligence requires scalable computing resources. Running AI endpoints, fine-tuning models, and processing medical voice data demand infrastructure that can scale dynamically while protecting sensitive data.

Second, the cloud offers strong advantages for security and regulatory compliance. As a medical software publisher, Mia Experts needed an infrastructure capable of guaranteeing both data sovereignty and regulatory compliance within the European framework.

Finally, the cloud enables a much more agile product strategy. Unlike traditional locally installed medical software, cloud-based architecture allows centralized updates and continuous product improvement without disrupting physicians’ workflows.

For a fast-growing startup, this flexibility is essential.

Leveraging OVHcloud to Build a Sovereign Health Infrastructure

Choosing OVHcloud was a strategic decision for Mia Experts, especially in a context where health data sovereignty is a critical issue.

Many solutions rely on non-European cloud providers. OVHcloud allowed the startup to build its infrastructure on a secure, sovereign European cloud, fully compliant with French and EU regulations.

This has become a strong differentiator — both from a regulatory standpoint and in terms of trust with physicians.

The OVHcloud Startup Program also played a key role during the early development phase by helping offset the high technical costs associated with innovation.

Mia Experts relies heavily on speech-to-text and AI models for generating medical reports. Fine-tuning these models to understand medical vocabulary requires substantial computing power. The program allowed the team to train and test these models without immediate financial pressure.

The Infrastructure Behind Mia Experts

Today, the platform runs on a robust cloud architecture built on OVHcloud services, including:

• Managed Kubernetes for Dev, Pre-production, and Production environments
• S3-compatible object storage for medical documents and AI models
• GPU instances supporting real-time medical speech transcription
• AI Endpoints for LLMs such as Mistral, Llama, and GPT-OSS
• Dedicated Public Cloud instances hosting GitHub CI/CD runners

All infrastructure is hosted in France, ensuring compliance with GDPR and HDS requirements.

One major advantage of OVHcloud AI endpoints is transparency: customer data is not used to train external models, a key concern in healthcare environments.

Tangible Results and Impact

The collaboration with OVHcloud has enabled several concrete achievements.

First, Mia Experts successfully deployed an infrastructure fully compliant with HDS health data hosting standards, guaranteeing high levels of security, availability, and traceability.

Second, the startup has been able to build and control its own AI capabilities, particularly around speech recognition and medical text generation. The voice recognition system has already been adapted to medical vocabulary, delivering strong accuracy in clinical contexts.

Another key outcome is AI sovereignty. By hosting AI inference within a controlled European environment, Mia Experts retains full control over its data, models, and algorithms.

Finally, the cloud infrastructure provides significant operational agility. The team can deploy updates quickly, iterate on AI models, and continuously improve application performance.

Accelerating Product Adoption

These technological choices have significantly strengthened Mia Experts’ positioning within the medical software ecosystem.

The cloud infrastructure makes the solution eligible for Ségur V2 standards, a key regulatory benchmark for healthcare software interoperability in France.

This strengthens credibility with physicians and facilitates integration into the national digital health ecosystem.

By maintaining full control over its AI pipeline — from hosting to model fine-tuning — Mia Experts can guarantee both data confidentiality and high-quality performance tailored to medical language.

What’s Next for Mia Experts

The next step is the progressive onboarding of the first users, with around 50 pre-registrations already secured before the official launch.

In the medium term, the startup aims to reach:

• 300 users within two years
• 500 users within three years

At the same time, Mia Experts plans to expand beyond surgical specialties with the launch of Mia Experts for General Practice, followed by extensions into additional medical disciplines.

The long-term vision is to build a modular medical platform adaptable to multiple specialties while sharing a unified technological foundation.

Advice for Other Startups

For startups building AI-driven products, the Mia Experts team highlights three key lessons.

First, anticipate your data strategy early. AI models are only as good as the data used to train them. Structuring and preparing datasets before accessing cloud resources can provide a major competitive advantage.

Second, do not underestimate regulatory complexity, especially in sectors like healthcare. Partnering with an experienced infrastructure manager can significantly accelerate deployment.

Finally, think of the cloud not only as hosting infrastructure but as a strategic platform for innovation and scalability.

Conclusion

The journey of Mia Experts shows that innovation in healthcare requires a careful balance between technological ambition, regulatory rigor, and practical usability.

By building on a sovereign and compliant cloud infrastructure from the outset, the startup has laid strong foundations for developing a medical platform that genuinely supports physicians.

The collaboration with OVHcloud has enabled Mia Experts to deploy a secure, scalable, and AI-ready infrastructure, ensuring full control over both health data and AI models.

For startups operating in highly regulated sectors, choosing the right cloud ecosystem can make all the difference — enabling innovation, accelerating growth, and building trust from day one.

Don’t let infrastructure costs limit your growth. We strongly urge other startups to join the OVHcloud Startup Program. Contact their team to build your own foundation for sustainable success.

If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

Can you introduce Azursafe, its industry, mission and values?

The blockchain sector has been growing steadily for several years, bringing both new opportunities and complex challenges, including stricter regulations in Europe and beyond. In this evolving landscape, AzurSafe was founded with a clear mission to support blockchain companies, financial institutions, fraud victims, analytics partners, security researchers, and law enforcement agencies in one shared goal: Making Blockchain Safer.

We develop and offer transaction analysis and monitoring solutions, to identify malicious activity using intelligent and innovative technologies.

Quickly gaining the support of the French government and several key partners, AzurSafe has established itself as a trusted player in the sector, earning recognition from private and public financial institutions for its innovative solutions which bring a real added value both in operational and regulatory terms.

What were specific challenges you faced before joining OVHcloud’s Blockchain Accelerator?

Deploying such complex and advanced solutions requires significant logistics in all areas, whether technical or business. Like any ambitious start-up, AzurSafe needs to respond to these challenges as part of its development.

On the technical side, we have to manage and orchestrate dozens of services, from massive data flows to the various characteristics that define each blockchain, then process and analyze all of this while offering a near-instantaneous service, because on the blockchain, every second counts when it comes to preventing fraud.

Why did you decide to explore cloud solutions to overcome these obstacles?

As our solution progressed, we realized that we needed to manage more and more features, then orient the infrastructure so it’s modular as we went along, while maintaining high availability, security standards, and data management without blowing our budget, inevitably linked to our business challenges.

After using other cloud services, we immediately understood the relevance of OVHcloud’s offering. What’s more, we offer a sovereign solution to those who want it (SecNumCloud), so the choice was easy.

How did OVHcloud and the Startup Program help you overcome these challenges?

After two years of intense R&D, we were reassured after benchmarking against the current state of the art and quickly realized that our technology had the same technical capabilities, and even better ones. But that wasn’t all it took to deploy a solution of this kind on the market.

We needed to dig deeper and better understand our environment and the distribution of our solutions and technologies in an ecosystem that was already formed with established players requiring equally established solutions. Participating in inspiring industry exchanges and receiving support throughout our deployment greatly contributed to our success.

Which OVHcloud services or features do you use, and how do they stand out from other solutions?

For our part, we use almost all (or nearly all) Public Cloud services, which stand out from other solutions thanks to their simplicity, performance, and competitive pricing.

How has OVHcloud’s support helped you evolve your infrastructure to meet the demands of your business?

Their support has been very useful in various cases, thanks to the organization of workshops, mentoring, and infrastructure support.

What tangible results have you achieved since collaborating with OVHcloud? How have these results helped to accelerate your growth or improve your product/service offering?

Not to mention the ease of use, which saves time, the costs are at least half those of well-known American providers.

How have these results helped to accelerate your growth or improve your product/service offering?

The program has enabled us to better understand our environment and the industry in which we operate, by combining technical and business support.

Future Vision: What are your ambitions for the future of your startup, and how do you see it evolving within the cloud ecosystem?

Current technologies, as well as the various legal and illegal activities involving blockchain, are still in their infancy. It is easy to predict that they will evolve in the coming years, creating new opportunities but also complex challenges. We do not operate directly on the blockchain, but we must monitor it and evolve with it. Our infrastructure and services must be resilient, and the cloud remains the best alternative for our customers who do not want on-premise software.

What future challenges do you foresee, and how do you see the cloud playing a role in solving them?

The volume of data and the number of protocols and services built on decentralized technologies continue to grow rapidly. Yet, they still rely on essential solutions such as RPC nodes, interface hosting, and advanced platforms like ours to operate safely.

The risks are real and can affect everyone. Security is no longer an option in today’s digital age, and increasingly secure solutions will be necessary. The cloud is an excellent candidate for the coming years, provided it is used correctly.

What advice would you give to other growth-stage startups considering the cloud or joining a support program?

Go for it, you have so much to gain!

Conclusions

AzurSafe has recently reached a new milestone, surpassing $90 billion in transaction value monitored across more than 30 blockchains, highlighting emerging fraud trends and providing real-time insights using advanced AI and ML technologies that demonstrate unrivalled accuracy.

The precision of our fraud detection tools has been approved, audited, battle-tested and endorsed by experts in the financial and investigative industries. But this is only the beginning, and we are preparing huge projects that will completely redefine the landscape on an international scale.

We are surpassing ourselves at every stage to create a more secure blockchain and we would like to thank OVHcloud, our webhost for several years, for this great opportunity and for joining us in revolutionising this industry. We invite anyone who wants to contribute to join us as well.

If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

Before an application go to production, it passes through several stages: source code, build, packaging and distribution. But Malicious code – such as a compromised dependency, breached CI pipeline, or modified package in a registry – can be introduced at any point in the development cycle, potentially impacting thousands of projects

This is precisely where Software Supply Chain Security (SSCS) comes in: to protect not just the code itself, but also how it’s built, delivered, and utilised.

Attacks like SolarWinds and Log4Shell aren’t isolated incidents, but rather subtle indicators that have escalated in severity.

This blog post explores recommended solutions and best practices for OVHcloud Managed Private Registry (MPR), an OCI-compliant artifact registry, to help you enhance your Software Supply Chain Security.

Generate a Software Bill Of Materials (SBOM)

SBOMs provides a list of all the ingredients (OS, libraries, code) and anything that composes the images that will run on your Kubernetes cluster. 

From that list, you can find out more about the image, its vulnerabilities, and licenses.

Generate an SBOM manually

To manually generate an SBOM from your image, click the ‘GENERATE SBOM’ button:

Within seconds, the SBOM column for your image will display “Queued”, then change to “Generating”, and a “SBOM details” link will appear.

Click the ‘SBOM details’ link to view the SBOM:

Your application’s SBOM is generated by Trivy in SPDX format. This item is then listed as an accessory for your image in the registry.

Click the ‘sbom.harbor’ accessory type for more details:

Generate an SBOM automatically

Manually generating an SBOM is a good practice, but automating the process is even better. The private registry can automatically generates the SBOM for you once an image is pushed to the desired project.

Click the project your image is part of, navigate to the ‘Configuration’ tab, then tick the SBOM generation checkbox:

Vulnerabilities scanning

We recommend running vulnerability scans on the images to confirm that:

• the images provided are free of any known vulnerabilities (CVEs);
• security patches are well integrated before deployment;
• the images used in production comply with security and compliance policies.

There are several vulnerability scanners available, like Trivy, Docker Scout, and Grype.

The OVHcloud Managed Private Registry uses Trivy as its default vulnerability scanner, but you can add more scanners if needed. Go to the Administration panel, click ‘Interrogation Services’, then navigate to the ‘Scanners’ tab:

Scan your image manually

To manually run a vulnerability scan on your image, go to your project and click the SCAN VULNERABILITIES button:

Within a few seconds, a scan will run and reveal any vulnerabilities detected in your image.

Click your image to take a look at the CVEs list:

Scan your image automatically

To automatically scan images on push, click the project your image is part of, then the ‘Configuration’ tab, and tick the ‘Vulnerabilities scanning’ checkbox:

Schedule vulnerability scans

Another way to stay informed is by configuring your vulnerability scanner to run scans every day. Go in the Administration panel, click ‘Interrogation Services’, then the ‘Vulnerability’ tab:

You can choose to schedule the scan Hourly, Daily, Weekly or you can customize when the scan will be triggered.

Scheduled scans ensure that existing images are regularly/periodically analyzed for newly discovered vulnerabilities (CVEs).

Prevent vulnerable images from running

You can also configure a project to prevent vulnerable images from being pulled. In order to do that, check the Prevent vulnerable images from running checkbox.

Select the severity level of vulnerabilities to prevent images from running, from None to Critical.

With this configuration, images cannot be pulled if their level is equal to or higher than the selected level of severity.

Exploitable vulnerabilities

When a scanner found vulnerabilities for your images, it is not necessary that they are exploitable in your application/in your image.

In this example, my application is build with golang 1.25-alpine, but Trivy found several CVEs that are only exploitable in golang 1.19.1 or less.

In order to remove/skip the “false positive”, a solution exists.

VEX (Vulnerability Exploitability eXchange) is a standard “format” to state whether a vulnerability is exploitable or not in a specific context.

You can generate a VEX file with vexctl or govulncheck tools.

Example:

# With vexctl
$ VULN_ID="CVE-2022-27664"
$ PRODUCT="pkg:golang/golang.org/x/net@v0.0.0-20220127200216-cd36cc0744dd"
$ vexctl create --file vex.json --author 'Aurélie Vache' --product "pkg:oci/demo@sha256:$HASH?repository_url=$REGISTRY/$HARBOR_PROJECT/demo" --vuln "$VULN_ID" --status 'not_affected' --justification 'vulnerable_code_not_present' --impact-statement "HTTP/2 vulnerability $VULN_ID is not exploitable because the image is compiled with Go 1.20, which contains the patched library."

# With govulncheck (for Go apps)
$ govulncheck -format openvex ./... > ../demo.vex.json

For the moment, OVHcloud MPR (managed Harbor) does not support VEX files (and the OpenVEX format) but it is planned in the future.

💡But the good news is that you can configure a CVEs whitelist with the list of not exploitable CVEs to ignore them during vulnerability scanning:

You can optionally uncheck the Never expires checkbox and use the calendar selector to set an expiry date for the allowlist.

Sign your images

It’s recommended to sign your images to ensure they haven’t been modified and originate from your pipeline (CI/CD).

Signing your images is crucial for protecting them against compromised registries and unauthorised image replacements.

Without a signature, there’s no guarantee the deployed image is the one you originally built!

You can sign your images with Sigstore Cosign or Notation tools:

$ export HARBOR_PROJECT=supply-chain
$ export IMAGE=xxxxxx.c1.de1.container-registry.ovh.net/$HARBOR_PROJECT/demo
$ export HASH=$(skopeo inspect docker://${IMAGE}:latest | jq -r .Digest | sed "s/^sha256://")

# Sign with Cosign
## Generate a private and a public key
$ cosign generate-key-pair
## Sign the image with the OCI 1.1 Referrers API
$ cosign sign -y --key cosign.key $IMAGE@sha256:$HASH 

# Sign with Notation
## Generate a RSA key & a self-signed X.509 test certificate
$ notation cert generate-test --default "test"

## Sign the image with the OCI 1.1 Refferrers API
$ export NOTATION_EXPERIMENTAL=1 ; notation sign -d --allow-referrers-api ${IMAGE}@sha256:${HASH}

You can use Cosign or Notation to sign your images, OVHcloud MPR supports both.

Your signature will appear beside your image as an accessory, plus a green checkmark ✅ in your column:

⚠️ Keep in mind, MPR (Harbor) doesn’t support signatures generated by Cosign v3 (the signature will upload and appear as an accessory, but the mark will stay red instead of turning green). This bug should be fixed in Harbor 2.15 💪.

Signing your OCI artifacts and linking them to your images is recommended, and you can do this using Cosign:

$ cosign attest -y --predicate sbom.spdx.json --key cosign.key $IMAGE@sha256:$HASH

They will be uploaded to the OVHcloud private registry and listed as accessories.

Ensure only verified images are pushed to your registry’s projects

To allow only verified/signed images to be deployed on a project, click the project your image is part of, navigate to the ‘Configuration’ tab, and tick the Cosign and/or Notation checkbox:

When checked, the registry will only allow verified images to be pulled from the project. Verified images are determined by Cosign or Notation, depending on the policy you have checked. Note that if you have both Cosign and Notation policies enforced, then images will need to be signed by both Cosign and Notation to be pulled.

Tag immutability

By default, tags are mutables, it means that you can push an image demo with the tag 1.0.0, do a modification in the code and push again to this same tag.

It could be useful to fix a bug but in term of security a mutable tag does not guarantee that the image you’ve built and pushed for the 1.0.0 version is the same image that exists now in the registry.

Moreover, on Harbor (so on OVHcloud MPR), due to limitations in the upstream OCI Distribution specification, the registry does not enforce a strict link between a tag and an image digest.

As a result, a tag can be reassigned to a different artifact. And it causes a side effect on the registry, this causes the tag to migrate across the artifacts and every artifact that has its tag taken away becomes tagless.

To prevent this situation, you can configure tag immutability rules. Tag immutability guarantees that an immutable tagged artifact cannot be deleted, and also cannot be altered in any way such as through re-pushing, re-tagging, or replication from another target registry.

To do that, click on your project and on the Policy tab and select TAG IMMUTABILITY:

And then click the ADD RULE button.

Fill the repositories and tags list according to your needs.

Example:

⚠️ You can add a maximum of 15 immutability rules per project.

To wrap thing up

Software supply chain security is super important these days. Everything is changing quickly – the concept, standards, and tools. So, leveraging useful tools like OVHcloud MPR and knowing how to set them up can boost your Software Supply Chain Security efforts.

To learn more about how to use and configure OVHcloud private registries, don’t hesitate to follow our guides.