Software supply chains have become more complex and increasingly targeted, making container image security a fundamental requirement for building trust in modern delivery pipelines.

By signing images with Cosign and protecting signing keys in OVHcloud KMS, teams can keep cryptographic material out of local environments and CI/CD variables, all while making image signing easier to control, audit and integrate into delivery pipelines.

In this blog post, you will learn how to use the OVHcloud KMS plugin for Cosign to generate a key, sign a container image with this key and verify that the OCI image has been correctly signed.

Cosign

Cosign is a tool from the Sigstore project used to sign, verify, and attest OCI container images and software artifacts.

Cosign supports several signing modes, including keyless signing through Sigstore, where short-lived certificates are generated at signing time based on your identity (via GitHub, Google or another OIDC provider), as well as ephemeral key generation, hardware and KMS-backed signing and custom PKI integration.

Cosign supports multiple KMS providers to generate and sign keys. Several external KMS providers are supported, including HashiCorp Vault, AWS KMS, GCP KMS and Azure Key Vault.
Cosign can now also be integrated with OVHcloud KMS through the Sigstore Cosign OVHcloud KMS plugin 💪.

OVHcloud Key Management Service (KMS)

OVHcloud KMS, often called OKMS, is a managed service that centralizes the creation, storage, and management of encryption keys. Its main goal is to help businesses secure data and control cryptographic operations from a single platform.

Each KMS is associated with a region, so the keys stored in that region are guaranteed to stay in that region. You can order multiple KMSs, either in different regions or in the same region.

Prerequisites

To be able to use the Sigstore KMS OVHcloud provider, you need to follow some prerequisites:

• Have an OVHcloud account
• Have created an OKMS domain (“305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have created an IAM local user (“cosign-305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have installed the OVHcloud CLI
• Have uuidgen CLI installed

💡The cosign OVHcloud plugin supports both token and mTLS authentication. For the purposes of this blog post, we will use the token authentication mode. Please follow the Sigstore Cosign KMS plugin for OVHcloud guide if you wish to use mTLS authentication mode.

Generate a PAT token (for token authentication only)

List the OKMS domains:

$ ovhcloud okms list
┌──────────────────────────────────────┬─────────────┐
│                  id                  │   region    │
├──────────────────────────────────────┼─────────────┤
│ 305db938-1234-5678-9012-3a0a29291661 │ eu-west-par │
│ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │ eu-west-par │
└──────────────────────────────────────┴─────────────┘

Save the OKMS ID in an environment variable:

export KMS_RESTAPI_OKMSID="305db938-1234-5678-9012-3a0a29291661"

The cosign OVHcloud plugin needs the permission to create and fetch keys from the OVHcloud KMS.

If you want to use token autentication, you’ll need a token (PAT). You can use the ovhcloud CLI to do that:

PAT_TOKEN=$(ovhcloud iam user token create <iam-local-user-name> --name pat-<iam-local-user-name> --description "PAT cosign for domain $KMS_RESTAPI_OKMSID" -o json  | jq .details.token |  tr -d '"')

echo $PAT_TOKEN

You should have a result like this:

$ PAT_TOKEN=$(ovhcloud iam user token create cosign-305db938-1234-5678-9012-3a0a29291661 --name pat-cosign-305db938-1234-5678-9012-3a0a29291661 --description "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661" -o json  | jq .details.token |  tr -d '"')
2026/05/07 08:48:34 Final parameters:
{
 "description": "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661",
 "name": "pat-cosign-305db938-1234-5678-9012-3a0a29291661"
}

$ echo $PAT_TOKEN
eyJhbGciOiJFZE...ASgXy55_DDFHdy4Z5uSq8lww-Bw

Save the KMS information

Save the KMS information in environment variables. For example:

export KMS_RESTAPI_ENDPOINT=$(ovhcloud okms get $KMS_RESTAPI_OKMSID -o json | jq .restEndpoint | xargs)
export KMS_RESTAPI_TYPE="token"
export KMS_RESTAPI_TOKEN=$PAT_TOKEN

Display the saved information:

$ echo $KMS_RESTAPI_ENDPOINT
https://eu-west-par.okms.ovh.net

$ echo $KMS_RESTAPI_OKMSID
305db938-1234-5678-9012-3a0a29291661

$ echo $KMS_RESTAPI_TYPE
token

$ echo $KMS_RESTAPI_TOKEN
eyJ...BIoHCA

Cosign KMS plugin installation

Install the plugin locally:

curl -fsSL https://raw.githubusercontent.com/ovh/sigstore-kms-ovhcloud/main/install.sh | sh

⚠️ The binary is installed in $HOME/.local/bin by default (created if it does not exist). Make sure this directory is in your PATH.

Or follow the other installation methods.

Now you can use the OVHcloud KMS plugin directly in the cosign command 🎉.

Let’s use Cosign with the OVHcloud KMS!

Generate a key

First, to sign an image, we need to generate a key pair. To do that we need to generate a UUID and use it in the cosign generate-key-pair command.

export KEY_ID=$(uuidgen)
cosign generate-key-pair --kms ovhcloud://$KEY_ID

The signing key is created in OVHcloud KMS, and the public key is written locally.

You should see an output like this:

$ export KEY_ID=$(uuidgen)
$ cosign generate-key-pair --kms ovhcloud://$KEY_ID

Public key written to cosign.pub

The command generates a key pair using the ECDSA algorithm and writes the public key to cosign.pub.

Check the keys have been created:

$ ls -l cosign.pub
-rw-------  1 avache  staff  178 18 juin  16:06 cosign.pub

$ cat cosign.pub

-----BEGIN PUBLIC KEY-----
MFkw...QgwA==
-----END PUBLIC KEY-----

Once the key pair has been generated, use the corresponding OVHcloud KMS key ID in the ovhcloud://$KEY_ID URI when signing and verifying images.

Or get an existing public key (optional)

Instead of creating a new public key, you can retrieve an existing one with the following command:

cosign public-key --key ovhcloud://$KEY_ID --outfile cosign-ovhcloud.pub

Sign an image

Replace the $IMAGE@sha256:$HASH parameter with the URI to your image and the hash to your image and execute this command:

cosign sign --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign sign --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verify the image has been signed

cosign verify --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign verify --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verification for 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},"image":{"docker-manifest-digest":"sha256:b1202...2334e2"},"type":"https://sigstore.dev/cosign/sign/v1"},"optional":{}}]

Conclusion

In this blog post, we have shown how to use Cosign with the OVHcloud KMS plugin to generate a key pair, sign a container image and verify its signature.

By keeping signing keys in a managed KMS, teams can reduce secret sprawl, protect sensitive cryptographic material and make image signing easier to integrate into secure CI/CD workflows.

Feel free to take a look at our Cloud Roadmap & Changelog to follow the latest features coming to OVHcloud Public Cloud products.

In a previous blog post, I explained how to use OVHcloud S3-compatible Object Storage as a Terraform backend for storing Terraform/OpenTofu state files.

Since then, we’ve enhanced OVHcloud Object Storage, and one of the coolest improvements is the support for conditional writes. By preventing concurrent overwrites, this feature enables Terraform’s native S3 state-locking mechanism to work seamlessly with OVHcloud Object Storage.

In practice, Terraform/OpenTofu can create a .tflock object only if it does not already exist. If another operation has already created the lock file, the conditional write fails and the second operation is blocked.

With this blog post, I explain how we can configure our Terraform/OpenTofu backend to store our states in an OVHcloud S3-compatible Object Storage with S3 state locking.

Terraform/OpenTofu S3 State Locking feature

State locking is a critical feature for collaborative Terraform/OpenTofu workflows. It ensures that only one operation can modify a state file at any given time, preventing concurrent writes that could lead to inconsistencies or state corruption.

Concretely, when a user runs terraform apply (or tofu apply), Terraform creates a .tflock file in the S3 bucket. This lock file indicates that an operation is currently in progress and that the state file is being used. If another user attempts to run terraform apply (or tofu apply) while the lock is active, Terraform detects the existing lock and aborts the operation with an error message. This prevents concurrent modifications of the state file and helps avoid state corruption.

Prerequisites

To be able to store your Terraform/OpenTofu states and activate the use_lockfile feature, you need to follow some prerequisites:

• Have an OVHcloud account
• Created a S3-compatible Object Storage (enable bucket versioning for your state bucket so previous state versions can be recovered if needed)
• Installed the Terraform CLI or OpenTofu CLI (version 1.10 or >)
• Installed the OVHcloud CLI

Save the s3 user credentials in environment variables (that allows you to access and store files in the bucket):

export AWS_ACCESS_KEY_ID="xxxxxxxxx"
export AWS_SECRET_ACCESS_KEY="yyyyyyyyy"

Configure it

Create a new folder, named my-app (for example), and go into it.

Create a provider.tf file with the following content, and replace the bucket value witht he name of the bucket you created:

terraform {
    backend "s3" {
      bucket = "terraform-state-3az" # the name of YOUR bucket
      key    = "my-app.tfstate" # the name of the state of your app
      region = "eu-west-par" # the region of the bucket
      endpoints = {
        s3 = "https://s3.eu-west-par.io.cloud.ovh.net/" # the endpoint
      }
      skip_credentials_validation = true
      skip_region_validation      = true
      skip_requesting_account_id  = true
      skip_s3_checksum            = true

      use_lockfile = true  # activation of the S3 native state locking feature
    }
}

💡The use_lockfile = true argument enables native S3 state locking. Terraform/OpenTofu uses the .tflock object to prevent two operations from writing to the same state file at the same time.

Test it!

Create a resource.tf file with an example resource to create (only for the testing purpose):

resource "null_resource" "test" {}

Initialise Terraform:

$ terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Finding latest version of hashicorp/null...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

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

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

As you can see, Terraform is using “s3” backend and initialized the provider plugins. 💪

💡Note that .terraform.lock.hcl is the provider dependency lock file created during initialization. The state lock file used for S3 backend locking is the .tflock file shown in the bucket during terraform apply.

Execute the apply command (without answering “yes”):

$ terraform apply

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

Terraform will perform the following actions:

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

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

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

  Enter a value:

Check if a new file appears in the S3 bucket:

$ ovhcloud cloud storage object object list terraform-state-3az

┌───────────────────────┬──────┐
│          key          │ size │
├───────────────────────┼──────┤
│ my-app.tfstate.tflock │ 219  │
└───────────────────────┴──────┘
💡 Use option -o json or -o yaml to get the raw output with all information

A .tflock file appears! 💪

You can also check it in the OVHcloud Control Panel:

This .tflock file means that someone is working on this infrastructure. After answering “yes” to the terraform apply command, the resources will be deployed, the state will appear and the lock file will disappear:

$ terraform apply

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

Terraform will perform the following actions:

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

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

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

  Enter a value: yes

null_resource.test: Creating...
null_resource.test: Creation complete after 0s [id=2048943220587414471]

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


$ ovhcloud cloud storage object object list terraform-state-3az
┌────────────────┬──────┐
│      key       │ size │
├────────────────┼──────┤
│ my-app.tfstate │ 612  │
└────────────────┴──────┘
💡 Use option -o json or -o yaml to get the raw output with all information

🎉

Why this Terraform state locking feature is useful?

If a user executes terraform apply command (without answering yes) and another user executes the same command, an error message will be displayed:

$ terraform apply

╷
│ Error: Error acquiring the state lock
│
│ Error message: operation error S3: PutObject, https response error StatusCode: 412, RequestID: tx7b439680a0104339a2fc7-xxxxxxxxxxxx, HostID: tx7b439680a0104339a2fc7-xxxxxxxxxxxx, api error
│ PreconditionFailed: At least one of the pre-conditions you specified did not hold
│ Lock Info:
│   ID:        xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
│   Path:      terraform-state-3az/my-app.tfstate
│   Operation: OperationTypeApply
│   Who:       avache@xxxxxxxxxx
│   Version:   1.14.9
│   Created:   2026-06-09 13:09:05.562244 +0000 UTC
│   Info:
│
│
│ Terraform acquires a state lock to protect the state from being written
│ by multiple users at the same time. Please resolve the issue above and try
│ again. For most commands, you can disable locking with the "-lock=false"
│ flag, but this is not recommended.
╵

This error is expected. It means another Terraform/OpenTofu operation has already acquired the state lock, so the second operation cannot modify the state file at the same time. The user should wait until the first operation is complete and the lock file has been released, then retry. Although Terraform allows locking to be disabled with -lock=false, this is not recommended because it can lead to concurrent state changes and potential state corruption.

Conclusion

In this blog post, we have seen one use case of conditional writes, but the feature goes far beyond that. Support for conditional writes does not only help prevent accidental overwrites; it also enables safer concurrent workflows, such as Terraform/OpenTofu state locking.

Our team is working on the improvement of Object Storage, so stay tuned for more. And please, as alays, share your thoughts with us!

It’s annoying: a payment often takes seconds to leave your account, but it can take days to reach the person on the other end. Why?

It is one of those modern financial mysteries. You tap your phone and the payment looks instant. But if you send money abroad, it can take three to five business days… Moreover, suddenly there are fees, delays, banking cut-off times and a trail of institutions… In an age of real-time apps and always-on services, traditional payments can still move maddeningly slow.

But this is one of the reasons blockchain gets so much attention in today’s financial circles. Put simply, blockchain has the potential to make some payments faster, cheaper, and easier to track. It is not perfect, and it will not replace every payment system overnight, but it does offer an alternative way of moving value between parties.

Why traditional payments can be slow

To understand why blockchain matters, it helps to look at how many traditional payments work today.

If you buy a coffee in your local café, the transaction feels immediate. But behind the scenes, several things are happening. Your bank, the merchant’s bank, the card network and payment processor may all be involved. The transaction is authorised quickly, but settlement can happen later.

Now imagine a more complicated scenario: a freelance designer in France is being paid by a client in the U.S., or a doctor working in London is sending money home to the Philippines. In these cases, the payment often passes through multiple banks, correspondent banking networks, foreign exchange systems, and compliance checks before it reaches the final account.

Each step adds time, cost, and complexity.

This is why international payments can take days rather than minutes. The money may move across different banking systems, operating in different time zones, with different rules, intermediary fees and business-hour limitations. In short, traditional payments often rely on a chain of trusted institutions updating their own records, one by one.

How blockchain changes the model

Blockchain works differently.

Instead of several institutions each keeping their own version of the transaction and then reconciling those records, blockchain uses what’s called a shared ledger: a record of transactions that is distributed across a network and updated according to the same rules. In simple terms, the participants in a shared ledger network are looking at the same history of payments, rather than passing information from one private database to another.

That matters because a lot of delay in traditional payments comes from handoffs. One institution sends instructions to another. A second institution checks them. A third updates its own records. If any part of that chain is closed, delayed, or requires extra review, the payment slows down.

With blockchain payments, the process is more direct. A payment request is sent to the network. Computers on that network check that the sender has the funds and that the same money has not already been spent elsewhere. Once the transaction is validated, it is grouped with other verified transactions, added to the ledger, and then reflected across the network. That shared update is what gives both sides a clearer, synchronized view of what has happened.

This does not remove every check or every operational requirement. But it can reduce the number of intermediaries involved in moving and confirming value. It can also allow the network to operate continuously, rather than depending on banking hours, weekends or regional cut-off times.

Therefore, some blockchain payments can settle far more quickly than traditional international transfers. In the right conditions, they can even happen in minutes or seconds, instead of days.

A simple real-world example

For example, let’s say a woman named Maria works as an architect in Chicago and sends part of her salary every month to her sister and nieces in Mexico. Using a traditional remittance service, she may pay transfer fees, exchange-rate markups, and they have to wait a day or two for the funds to arrive. If the transfer is made before a weekend or public holiday, it may take even longer.

With a blockchain-based payment system, the same transfer could move across a digital network much more directly – maybe even instantly. Instead of passing through a long chain of correspondent banks, the transaction is submitted to a shared ledger, validated by the network, and recorded in a way that both sides can verify. Maria’s family does not have to wait for multiple institutions to update separate records in sequence before the payment is considered settled.

That does not mean the experience is always instant or frictionless, but it does show why blockchain is relevant to ordinary payments. Not just about crypto trading or speculation, blockchain can also make everyday financial activity more efficient and reliable.

Can blockchain make payments cheaper too?

Oftentimes, yes.

Traditional payment systems can be expensive because multiple parties may each take a fee. Currency conversion adds more cost. Smaller cross-border payments can be especially frustrating, because the charges can feel disproportionate to the amount being sent.

Blockchain can reduce some of this friction because fewer intermediaries may be involved in moving and confirming the payment. In some systems, the network is handling verification and settlement instead of several institutions performing overlapping roles.

That does not mean every blockchain payment is cheap. Costs depend heavily on the network, the design of the application, and how busy the chain is. But the core idea is compelling: fewer middlemen means fewer handoffs, which can mean lower costs.

What blockchain will not fix on its own

However, there are some caveats.

Blockchain does not automatically solve every challenge in payments. Regulation, consumer protection, currency volatility, user experience, and integration with existing financial systems all matter. In many markets, blockchain payments still need better interfaces and clearer frameworks before they become truly mainstream.

There is also a difference between the underlying technology and the end-user experience. Most people do not want to think about wallets, keys, or protocols when they are paying rent or buying groceries. For blockchain payments to scale, the experience must become simpler and more familiar.

Back to Maria

So let’s go back to Maria, sending money back to her family who might have an important bill they need to pay urgently.

In the traditional model, the payment might pass through several institutions, take days to settle, and lose value through fees and exchange costs.

In a blockchain-based model, the transfer could move through a shared ledger, be validated by the network rather than reconciled across several separate databases, settle much faster, and give both sides a clearer view of what is happening.

That is why this matters to regular people like you, me, and Maria. Blockchain may not replace every payment rail tomorrow, but it offers a serious alternative for a world that increasingly expects transactions to be fast, transparent and borderless.

Batch Mode is designed to help in exactly this type of scenario.

What is Batch Mode?

When working with LLMs, you often send requests one by one through synchronous endpoints like /v1/chat/completions or /v1/responses. This works fine for real-time use cases, but what can you do if you need to process hundreds or thousands of prompts? Sending them individually is slow, and you’re limited by rate limits.

Batch mode solves this problem. Instead of sending requests one at a time, you upload a file containing all your requests, submit a batch job, and get the results back asynchronously, within a maximum of 24 hours. And here’s the cherry on top: batch mode is 50% cheaper than synchronous requests. Since the platform can schedule your workload more efficiently, you benefit from a significant cost reduction.

This is ideal for:

• 📊 Bulk classification or summarization tasks
• 🌍 Large-scale translation jobs
• 📝 Generating descriptions for a product catalog
• 🧪 Evaluating model outputs on a test dataset

ℹ️ The Batch API is compatible with the OpenAI Batch API format, so you can use the official OpenAI SDK to interact with it.

When not to use Batch Mode!

Batch Mode is designed for large workloads that do not need an immediate response. This being said, it is not the right choice for real-time use cases such as chatbots, live customer support, interactive assistants or applications where users expect an answer within seconds. For those scenarios, synchronous endpoints remain more appropriate. Use Batch Mode when your requests can be processed asynchronously and retrieved later.

ℹ️ The Batch API is currently in beta. You can find more information about the beta on the dedicated page.

Prerequisites for using Batch Mode

Before getting started, you’ll need:

• An AI Endpoints API key
• Python 3.10+ installed
• The openai Python package

⚠️ You can generate your API key from the AI Endpoints console.

Install the dependency:

pip install openai

Set up your environment variables:

export OVH_AI_ENDPOINTS_ACCESS_TOKEN='your_api_key'
export OVH_AI_ENDPOINTS_BASE_URL='https://oai.endpoints.kepler.ai.cloud.ovh.net/v1'

Step 1: Prepare the Input File

The input file uses the JSON Lines format (.jsonl). Each line is a self-contained request with a unique custom_id that lets you match results to their original requests.

Here’s an example requests.jsonl:

{"custom_id": "request-1", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-oss-20b", "messages": [{"role": "user", "content": "Summarise the plot of Hamlet in two sentences."}]}}
{"custom_id": "request-2", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-oss-20b", "messages": [{"role": "user", "content": "Translate 'Good morning' into French, Spanish and German."}]}}

Key points:

• Each custom_id must be unique within a batch
• The model field must reference a model available in the AI Endpoints catalog
• The url field indicates which endpoint to call

Step 2: Upload the File and Create the Batch

Here’s the complete Python code that handles the full workflow: upload, create, poll, and download:

import os
import time

from openai import OpenAI

# Load environment variables
_OVH_AI_ENDPOINTS_ACCESS_TOKEN = os.environ["OVH_AI_ENDPOINTS_ACCESS_TOKEN"]
_OVH_AI_ENDPOINTS_BASE_URL = os.environ["OVH_AI_ENDPOINTS_BASE_URL"]

# Initialize the OpenAI-compatible client targeting OVHcloud AI Endpoints
client = OpenAI(
    base_url=_OVH_AI_ENDPOINTS_BASE_URL,
    api_key=_OVH_AI_ENDPOINTS_ACCESS_TOKEN,
)

# 1. Upload the input JSONL file with purpose="batch"
print("📤 Uploading input file...")
batch_input_file = client.files.create(
    file=open("requests.jsonl", "rb"),
    purpose="batch",
)
print(f"✅ Uploaded file id: {batch_input_file.id}")

# 2. Create the batch referencing the uploaded file
print("🚀 Creating batch...")
batch = client.batches.create(
    input_file_id=batch_input_file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h",
    metadata={"description": "Batch mode example - OVHcloud AI Endpoints"},
)
print(f"✅ Batch created: {batch.id} (status: {batch.status})")

# 3. Poll the batch status until it reaches a terminal state
print("⏳ Polling batch status...")
while True:
    current = client.batches.retrieve(batch.id)
    print(f"   status={current.status} counts={current.request_counts}")
    if current.status in ("completed", "failed", "expired", "cancelled"):
        break
    time.sleep(30)

# 4. Download the results (and errors if any)
final = client.batches.retrieve(batch.id)

if final.output_file_id:
    print("📥 Downloading results.jsonl...")
    output = client.files.content(final.output_file_id)
    with open("results.jsonl", "wb") as f:
        f.write(output.read())
    print("✅ Results written to results.jsonl")

if final.error_file_id:
    print("🐛 Downloading errors.jsonl...")
    errors = client.files.content(final.error_file_id)
    with open("errors.jsonl", "wb") as f:
        f.write(errors.read())
    print("🐛 Errors written to errors.jsonl")

print(f"🏁 Final batch status: {final.status}")

Let’s break down the key steps:

Upload the input file

batch_input_file = client.files.create(
    file=open("requests.jsonl", "rb"),
    purpose="batch",
)

The purpose=”batch” parameter tells the API that this file will be used as batch input.

Create the batch

batch = client.batches.create(
    input_file_id=batch_input_file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h",
)

The completion_window=”24h” means the batch will be stopped after 24 hours if not completed.

Poll the batch status

while True:
    current = client.batches.retrieve(batch.id)
    print(f"   status={current.status} counts={current.request_counts}")
    if current.status in ("completed", "failed", "expired", "cancelled"):
        break
    time.sleep(30)

The client.batches.retrieve(batch.id) call returns the current state of the batch. The request_counts field gives you a breakdown of how many requests are completed, failed, or still in progress, useful for monitoring large batches.

The possible terminal states are:

• completed: all requests have been processed successfully
• failed: the batch encountered a fatal error
• expired: the batch exceeded the completion_window duration
• cancelled: the batch was manually cancelled via the API

We poll every 30 seconds here, but you can adjust this interval depending on your use case. For very large batches, a longer interval (e.g., 60–120 seconds) is more appropriate.

Download the results

final = client.batches.retrieve(batch.id)

if final.output_file_id:
    output = client.files.content(final.output_file_id)
    with open("results.jsonl", "wb") as f:
        f.write(output.read())

Once the batch is complete, the output_file_id field contains the ID of the results file. You download it using client.files.content() which returns the raw file content.

Download the errors (if any)

if final.error_file_id:
    errors = client.files.content(final.error_file_id)
    with open("errors.jsonl", "wb") as f:
        f.write(errors.read())

If some requests in your batch failed (e.g., invalid model name, malformed input, token limit exceeded), their details will be available in a separate error file. The error_file_id will be None if all requests succeeded. Each line in errors.jsonl contains the custom_id of the failed request along with the error details, making it easy to identify and retry only the failed ones.

Step 3: Read the Results

The output file (results.jsonl) contains one JSON object per line. Each object includes:

• The custom_id matching your original request
• The full response body (same format as a synchronous /v1/chat/completions responses)

Here’s what a result looks like:

{
  "id": "964e007472a557240221910ba143bb03",
  "custom_id": "request-1",
  "response": {
    "status_code": 200,
    "body": {
      "id": "chatcmpl-9879ebff777795a3",
      "choices": [
        {
          "index": 0,
          "message": {
            "role": "assistant",
            "content": "Hamlet, the Prince of Denmark, is driven to madness and vengeance after learning that his father was murdered by his uncle Claudius..."
          },
          "finish_reason": "stop"
        }
      ],
      "model": "gpt-oss-20b",
      "usage": {
        "prompt_tokens": 78,
        "completion_tokens": 297,
        "total_tokens": 375
      }
    }
  },
  "error": null
}

If some requests fail, the errors.jsonl file will contain details about what went wrong for each failed request.

Other Examples Available

The AI Endpoints – Batch mode guide also contains examples in:

• JavaScript: using the OpenAI Node.js SDK
• Pure HTTP requests: using curl without any framework, if you prefer a language-agnostic approach

These examples demonstrate that you can use the Batch API from any language or tool that can make HTTP requests, since it follows the standard OpenAI-compatible API format.

Conclusion

Batch mode is a powerful feature when you need to process large volumes of repetitive, non time-sensitive inference requests, without worrying about rate limits or timeout issues. Upload your file, submit the batch, and come back later for the results, it’s as simple a solution as that.

The OpenAI-compatible API makes it straightforward to integrate into existing workflows, and with examples available in Python, JavaScript, and raw HTTP, you can use whichever approach fits your stack best.

You have a dedicated Discord channel (#ai-endpoints) on our Discord server, see you there!

For more info on AI Endpoints, find our previous blog posts.

Find the full code example in the GitHub repository: public-cloud-examples/ai/ai-endpoints/batch-mode.

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

Devoxx France 2026: The AI Edition

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

Key figures from the 2026 edition:

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

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

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

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

Keynotes

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

Some highlights from the keynotes:

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

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

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

Meet & Greet

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

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

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

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

OVHcloud Presence

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

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

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

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

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

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

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

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

OVHcloud Speakers & Talks

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

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

Find here the topics of their talks:

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

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

🎤 Speaker: Aurélie Vache

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

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

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

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

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

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

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

🎥 Replay.

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

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

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

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

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

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

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

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

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

🎥 Replay.

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

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

🎤 Speakers: Benoît Masson & Theo Bougé

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

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

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

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

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

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

🎥 Replay.

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

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

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

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

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

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

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

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

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

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

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

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

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

🎥 Replay.

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

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

🎤 Speakers: Mathieu Busquet & Stéphane Philippart

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

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

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

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

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

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

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

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

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

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

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

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

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

🎤 Speaker: Sébastien Ferrer

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

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

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

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

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

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

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

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

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

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

🎥 Replay.

“Et si écrire du SQL redevenait cool ?”

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

🎤 Speaker: Sébastien Ferrer

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

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

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

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

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

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

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

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

🎥 Replay.

“🤖 Apprendre à notre IA à … apprendre 🧠”

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

🎤 Speaker: Stéphane Philippart

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

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

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

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

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

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

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

Each approach has its own specificities, advantages and disadvantages.

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

🎥 Replay.

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

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

🎤 Speaker: Héla Ben Khalfallah

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

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

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

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

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

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

🎥 Replay.

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

Podcast

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

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

Key Trends

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

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

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

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

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

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

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

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

Conclusion

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

💬 Stay in Touch

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

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

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.

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

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

OVHcloud Enterprise File System (EFS)

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

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

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

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

NetApp Trident CSI

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

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

Let’s do it!

EFS creation

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

Here you can see the architecture of all the services:

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

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

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

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

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

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

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

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

Let’s deploy our components with Terraform!

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

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

  required_version = ">= 1.7.0"
}

provider "ovh" {
}

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

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

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

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

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

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

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

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

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

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

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

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

# Services to create

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

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

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

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

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

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

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

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

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

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

envsubst < variables.tf.template > variables.tf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Create an output.tf file with the following content:

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

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

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

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

terraform init

The output should be like this:

$ terraform init

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

Terraform has been successfully initialized!

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

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

Apply it:

terraform apply

The output should be like this:

$ terraform apply

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

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

Terraform will perform the following actions:

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

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

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

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

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

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

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

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

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

  Enter a value: yes

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

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

Outputs:

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

Save the OAuth2 credentials in environment variables:

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

Trident CSI Installation

Install the Trident operator in your MKS cluster:

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

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

You should have a result like this:

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

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

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

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

To learn more about the release, try:

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

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

$ kubectl get pods -n trident

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

Trident Backend Creation

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

1. Secret Creation

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

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

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

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

Apply the secret in your cluster:

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

Check that the secret has been correctly created:

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

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

2. Trident Backend Creation

Create your backend with the command below:

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

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

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

$ kubectl get TridentBackendConfig -n trident

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

Use EFS in your MKS cluster

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

1. StorageClass

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

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

Apply the StorageClass:

kubectl apply -f sc_efs.yaml

Check that the StorageClass has been created:

$ kubectl get sc ovh-efs-premium

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

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

2. Volume Creation (PVC)

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

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

Apply it:

kubectl apply -f pvc_efs.yaml

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

kubectl get pvc premium-pvc-efs

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

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

$ kubectl get pvc

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

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

Conclusion

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

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

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