If you run stateful applications on Kubernetes, one common challenge is providing shared persistent storage that can be accessed by multiple workloads.

While Kubernetes Persistent Volumes usually rely on block storage with ReadWriteOnce access, some applications require shared filesystem access with ReadWriteMany (RWX) capabilities.

OVHcloud File Storage provides managed NFS shares that can be dynamically consumed by Kubernetes workloads through the Manila CSI driver.

In this blog post, we will see how to integrate OVHcloud File Storage with OVHcloud Managed Kubernetes Service (MKS) using Manila CSI and test RWX storage capabilities.

OVHcloud File Storage

OVHcloud Public Cloud File Storage is a fully managed shared file storage service designed for cloud-native workloads running on Public Cloud instances and Kubernetes clusters.

Built on OpenStack Manila, it provides shared NFSv3 volumes that can be mounted simultaneously by multiple clients, making it an ideal solution for applications requiring ReadWriteMany (RWX) access. Volumes can be provisioned from 150 GiB up to 10 TiB, with predictable, linear performance that scales with the allocated capacity.

Because the service is fully managed, you don’t need to deploy or maintain your own NFS server. File Storage integrates with the OVHcloud platform through the Control Panel, API, CLI, Terraform provider, and Kubernetes via the Manila CSI driver, allowing shared volumes to be dynamically provisioned directly from your cluster.

Why use Manila CSI?

The Kubernetes Container Storage Interface (CSI) provides a standard mechanism for exposing external storage systems to Kubernetes.

Instead of manually creating NFS mounts and PersistentVolumes, the Manila CSI driver allows Kubernetes to dynamically create and manage file shares using Kubernetes resources such as StorageClasses (SC), PersistentVolumeClaims (PVC) and PersistentVolumes (PV).

Prerequisites

Before starting, you need:

• An OVHcloud Public Cloud project
• An OVHcloud Managed Kubernetes Service (MKS) cluster that is connected to a private network
• Terraform CLI installed
• kubectl CLI installed

Deploying Manila CSI step by step: let’s do it!

We already have a MKS cluster, in EU-WEST-PAR region, running inside a private network and a subnet. In this blog post we will:

• create a Public Cloud user for the Manila CSI driver
• install the CSI NFS driver
• install the Manila CSI driver
• deploy a Secret for Manila CSI that allows the Manila CSI driver to authenticate against OpenStack and manage Manila resources in your cluster
• create a file shared network
• deploy a ConfigMap to configure the Manila CSI driver
• deploy the csi-manila-nfs StorageClass to enable the Manila CSI driver to dynamically create Manila shares and use them as Kubernetes volumes

We will use Terraform to deploy this architecture easily.

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

terraform {
  required_providers {
    helm = {
      source = "hashicorp/helm"
    }

    kubectl = {
      source = "alekc/kubectl"
      version = "2.1.6"
    }

    ovh = {
      source = "ovh/ovh"
    }
  }
}

provider "helm" {
  kubernetes = {
    host                   = data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].host
    client_certificate     = base64decode(data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].client_certificate)
    client_key             = base64decode(data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].client_key)
    cluster_ca_certificate = base64decode(data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].cluster_ca_certificate)
  }
}

provider "kubectl" {
  host                   = data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].host
  client_certificate     = base64decode(data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].client_certificate)
  client_key             = base64decode(data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].client_key)
  cluster_ca_certificate = base64decode(data.ovh_cloud_project_kube.mks_cluster.kubeconfig_attributes[0].cluster_ca_certificate)
  load_config_file       = false
}

Set the environment variables, for the OVHcloud Terraform provider, 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 variables.tf.template file and fill it with these information:

variable "service_name" {
  default = "$OVH_CLOUD_PROJECT_SERVICE"
}

variable "mks_cluster_id" {
  default = "<your_mks_cluster_id>"
}

⚠️ In the file, replace the MKS ID with your existing MKS cluster ID 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 nfs_share.tf file and fill it with these information:

data "ovh_cloud_project_kube" "mks_cluster" {
  service_name = var.service_name
  kube_id      = var.mks_cluster_id
}

data "ovh_cloud_network_private_vrack_subnet" "mks_cluster_subnet" {
  service_name = var.service_name
  network_id   = data.ovh_cloud_project_kube.mks_cluster.private_network_id
  id           = data.ovh_cloud_project_kube.mks_cluster.nodes_subnet_id
}

# CSI Manila

module "csi_manila" {
  source = "git::https://github.com/ovh/public-cloud-examples.git//containers-orchestration/managed-kubernetes/install-csi-manila/modules/ovhcloud/csi_manila?ref=v1.5.0"

  service_name       = var.service_name
  region             = data.ovh_cloud_project_kube.mks_cluster.region
  share_network_name = "${data.ovh_cloud_project_kube.mks_cluster.name}-share-network"
  network_id         = data.ovh_cloud_project_kube.mks_cluster.private_network_id
  subnet_id          = data.ovh_cloud_project_kube.mks_cluster.nodes_subnet_id
  subnet_cidr        = data.ovh_cloud_network_private_vrack_subnet.mks_cluster_subnet.cidr
}

output "manila-user" {
  value = module.csi_manila.manila-user
}

💡In this Terraform file we are using an existing csi_manila Terraform module hosted in the OVHcloud Public Cloud Examples GitHub repository.

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

terraform init

The output should be like this:

$ terraform init

Initializing the backend...
Initializing modules...
Downloading git::https://github.com/ovh/public-cloud-examples.git?ref=v1.5.0 for csi_manila...
- csi_manila in .terraform/modules/csi_manila/containers-orchestration/managed-kubernetes/install-csi-manila/modules/ovhcloud/csi_manila
Initializing provider plugins...
- Reusing previous version of hashicorp/helm from the dependency lock file
- Reusing previous version of alekc/kubectl from the dependency lock file
- Reusing previous version of ovh/ovh from the dependency lock file
- Installing hashicorp/helm v3.2.0...
- Installed hashicorp/helm v3.2.0 (signed by HashiCorp)
- Installing alekc/kubectl v2.1.6...
- Installed alekc/kubectl v2.1.6 (self-signed, key ID 772FB27A86DAFCE7)
- Installing ovh/ovh v2.16.1...
- Installed ovh/ovh v2.16.1 (signed by a HashiCorp partner, key ID F56D1A6CBDAAADA5)
Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://developer.hashicorp.com/terraform/cli/plugins/signing

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

data.ovh_cloud_project_kube.mks_cluster: Reading...
data.ovh_cloud_project_kube.mks_cluster: Read complete after 1s [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx]
data.ovh_cloud_network_private_vrack_subnet.mks_cluster_subnet: Reading...
data.ovh_cloud_network_private_vrack_subnet.mks_cluster_subnet: Read complete after 1s [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx]

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.csi_manila.helm_release.csi-driver-nfs will be created
  + resource "helm_release" "csi-driver-nfs" {
      + atomic                     = false
      + chart                      = "csi-driver-nfs"
      + cleanup_on_fail            = false
      + create_namespace           = false
      + dependency_update          = false
      + disable_crd_hooks          = false
      + disable_openapi_validation = false
      + disable_webhooks           = false
      + force_update               = false
      + id                         = (known after apply)
      + lint                       = false
      + max_history                = 0
      + metadata                   = (known after apply)
      + name                       = "csi-driver-nfs"
      + namespace                  = "kube-system"
      + pass_credentials           = false
      + recreate_pods              = false
      + render_subchart_notes      = true
      + replace                    = false
      + repository                 = "https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts"
      + reset_values               = false
      + reuse_values               = false
      + set_wo                     = (write-only attribute)
      + skip_crds                  = false
      + status                     = "deployed"
      + take_ownership             = false
      + timeout                    = 300
      + upgrade_install            = false
      + verify                     = false
      + version                    = "4.13.4"
      + wait                       = true
      + wait_for_jobs              = false
    }

  # module.csi_manila.helm_release.openstack-manila-csi will be created
  + resource "helm_release" "openstack-manila-csi" {
      + atomic                     = false
      + chart                      = "openstack-manila-csi"
      + cleanup_on_fail            = false
      + create_namespace           = false
      + dependency_update          = false
      + disable_crd_hooks          = false
      + disable_openapi_validation = false
      + disable_webhooks           = false
      + force_update               = false
      + id                         = (known after apply)
      + lint                       = false
      + max_history                = 0
      + metadata                   = (known after apply)
      + name                       = "openstack-manila-csi"
      + namespace                  = "kube-system"
      + pass_credentials           = false
      + recreate_pods              = false
      + render_subchart_notes      = true
      + replace                    = false
      + repository                 = "https://kubernetes.github.io/cloud-provider-openstack"
      + reset_values               = false
      + reuse_values               = false
      + set_wo                     = (write-only attribute)
      + skip_crds                  = false
      + status                     = "deployed"
      + take_ownership             = false
      + timeout                    = 300
      + upgrade_install            = false
      + verify                     = false
      + version                    = "2.36.0"
      + wait                       = true
      + wait_for_jobs              = false
    }

  # module.csi_manila.kubectl_manifest.csi-manila-secrets will be created
  + resource "kubectl_manifest" "csi-manila-secrets" {
      + api_version             = (known after apply)
      + apply_only              = false
      + field_manager           = "kubectl"
      + force_conflicts         = false
      + force_new               = false
      + id                      = (known after apply)
      + kind                    = (known after apply)
      + live_manifest_incluster = (sensitive value)
      + live_uid                = (known after apply)
      + name                    = (known after apply)
      + namespace               = (known after apply)
      + server_side_apply       = false
      + uid                     = (known after apply)
      + validate_schema         = true
      + wait_for_rollout        = true
      + yaml_body               = (sensitive value)
      + yaml_body_parsed        = (known after apply)
      + yaml_incluster          = (sensitive value)
    }

  # module.csi_manila.kubectl_manifest.manila-runtime-configmap will be created
  + resource "kubectl_manifest" "manila-runtime-configmap" {
      + api_version             = "v1"
      + apply_only              = false
      + field_manager           = "kubectl"
      + force_conflicts         = false
      + force_new               = false
      + id                      = (known after apply)
      + kind                    = "ConfigMap"
      + live_manifest_incluster = (sensitive value)
      + live_uid                = (known after apply)
      + name                    = "manila-csi-runtimeconf-cm"
      + namespace               = "default"
      + server_side_apply       = false
      + uid                     = (known after apply)
      + validate_schema         = true
      + wait_for_rollout        = true
      + yaml_body               = (sensitive value)
      + yaml_body_parsed        = <<-EOT
            apiVersion: v1
            data:
              runtimeconfig.json: |
                {
                  "nfs": {
                    "matchExportLocationAddress": "10.1.0.0/16"
                  }
                }
            kind: ConfigMap
            metadata:
              annotations:
                meta.helm.sh/release-name: manila-csi
                meta.helm.sh/release-namespace: default
              labels:
                app.kubernetes.io/managed-by: Helm
              name: manila-csi-runtimeconf-cm
              namespace: default
        EOT
      + yaml_incluster          = (sensitive value)
    }

  # module.csi_manila.kubectl_manifest.storage-class will be created
  + resource "kubectl_manifest" "storage-class" {
      + api_version             = (known after apply)
      + apply_only              = false
      + field_manager           = "kubectl"
      + force_conflicts         = false
      + force_new               = false
      + id                      = (known after apply)
      + kind                    = (known after apply)
      + live_manifest_incluster = (sensitive value)
      + live_uid                = (known after apply)
      + name                    = (known after apply)
      + namespace               = (known after apply)
      + server_side_apply       = false
      + uid                     = (known after apply)
      + validate_schema         = true
      + wait_for_rollout        = true
      + yaml_body               = (sensitive value)
      + yaml_body_parsed        = (known after apply)
      + yaml_incluster          = (sensitive value)
    }

  # module.csi_manila.ovh_cloud_project_user.manila-user will be created
  + resource "ovh_cloud_project_user" "manila-user" {
      + creation_date = (known after apply)
      + description   = "User for the Manila CSI driver"
      + id            = (known after apply)
      + openstack_rc  = (known after apply)
      + password      = (sensitive value)
      + role_name     = "share_operator"
      + roles         = (known after apply)
      + service_name  = "xxxxxxxxxxxxxxxxxxxxx"
      + status        = (known after apply)
      + username      = (known after apply)
    }

  # module.csi_manila.ovh_cloud_storage_file_share_network.sharenetwork will be created
  + resource "ovh_cloud_storage_file_share_network" "sharenetwork" {
      + checksum        = (known after apply)
      + created_at      = (known after apply)
      + current_state   = (known after apply)
      + description     = (known after apply)
      + id              = (known after apply)
      + name            = "mks_standard_3az-share-network"
      + network_id      = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"
      + region          = "EU-WEST-PAR"
      + resource_status = (known after apply)
      + service_name    = "xxxxxxxxxxxxxxxxxxxxx"
      + subnet_id       = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"
      + updated_at      = (known after apply)
    }

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

Changes to Outputs:
  + manila-user = (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.csi_manila.ovh_cloud_storage_file_share_network.sharenetwork: Creating...
module.csi_manila.ovh_cloud_project_user.manila-user: Creating...
module.csi_manila.kubectl_manifest.manila-runtime-configmap: Creating...
module.csi_manila.kubectl_manifest.manila-runtime-configmap: Creation complete after 0s [id=/api/v1/namespaces/default/configmaps/manila-csi-runtimeconf-cm]
module.csi_manila.helm_release.csi-driver-nfs: Creating...
module.csi_manila.ovh_cloud_storage_file_share_network.sharenetwork: Still creating... [00m10s elapsed]
module.csi_manila.ovh_cloud_project_user.manila-user: Still creating... [00m10s elapsed]
module.csi_manila.ovh_cloud_storage_file_share_network.sharenetwork: Creation complete after 12s [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx]
module.csi_manila.kubectl_manifest.storage-class: Creating...
module.csi_manila.ovh_cloud_project_user.manila-user: Creation complete after 13s [id=718526]
module.csi_manila.kubectl_manifest.csi-manila-secrets: Creating...
module.csi_manila.kubectl_manifest.csi-manila-secrets: Creation complete after 1s [id=/api/v1/namespaces/default/secrets/csi-manila-secrets]
...

Let’s create dynamically File Storage on Kubernetes

Now, in your Kubernetes cluster, create a pvc.yaml file witht this content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-share-fs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 150Gi
  storageClassName: csi-manila-nfs

Apply this Persistent Volume Claim (PVC), thanks to that Kubernetes users can request shared storage:

kubectl apply -f pvc.yaml

Check the status of the PVC:

kubectl get pvc nfs-share-fs-pvc

Wait until the status of the PVC changes to Bound.

You should have an output like this:

$ kubectl get pvc nfs-share-fs-pvc

NAME               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     VOLUMEATTRIBUTESCLASS   AGE
nfs-share-fs-pvc   Bound    pvc-af1349b7-eb51-43ac-b0f0-94d0e8139c57   150Gi      RWX            csi-manila-nfs   <unset>                 3h48m

Create a deploy.yaml file and fill it with this content:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
      - name: nfs-share-fs-pvc
        persistentVolumeClaim:
          claimName: nfs-share-fs-pvc
      containers:
      - name: nginx
        image: nginx
        ports:
          - containerPort: 80
            name: "http-server"
        volumeMounts:
          - mountPath: "/usr/share/nginx/html"
            name: nfs-share-fs-pvc

Apply this deployment with one pod that has a volume attached to nfs-share-fs-pvc:

kubectl apply -f deploy.yaml

Verify that the pod is running:

kubectl get pod

You should have an output like this:

$ kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6cbf9b898c-svpzf   1/1     Running   0          6m

Verify that you can scale the deployment (multi-attach volume):

kubectl scale deploy/nginx-deployment --replicas=2

Check another pod is running:

kubectl get pod

You should have an output like this:

$ kubectl get pod

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6cbf9b898c-867bq   1/1     Running   0          3m
nginx-deployment-6cbf9b898c-svpzf   1/1     Running   0          9m

To verify RWX functionality, connect to one pod and create a file in the mounted directory (e.g., /usr/share/nginx/html).

MY_POD=$(kubectl get po -o name | sed -n '1p')
echo $MY_POD

#Create a file in the pod number 1
kubectl exec $MY_POD -it -- touch /usr/share/nginx/html/index.html

Then connect to the second pod and confirm the file is visible:

MY_POD_2=$(kubectl get po -o name | sed -n '2p')
echo $MY_POD_2

#Display it in the pod number two
kubectl exec $MY_POD_2 -it -- ls -alrt /usr/share/nginx/html/

You should have an output like this:

$ kubectl exec $MY_POD_2 -it -- ls -alrt /usr/share/nginx/html/

total 24
drwxr-xr-x 3 root root  4096 Jul 14 01:22 ..
drwx------ 2 root root 16384 Jul 15 09:18 lost+found
drwxrwxrwx 3 root root  4096 Jul 15 09:32 .
-rw-r--r-- 1 root root     0 Jul 15 13:09 index.html

Now your Manila share exposed through NFS is functioning the way you want! 🎉

Conclusion

In this blog post we showed that using Manila CSI with OVHcloud File Storage makes it possible to provide Kubernetes applications with dynamically provisioned shared storage.

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.

When people talk about blockchain, they are usually talking about the visible parts: cryptocurrencies, wallets, tokens, or applications built on top. But underneath all of that sits the whole architecture that makes the system work.

Like any structure, the underlying architecture matters. In blockchain, the structure determines how transactions move through the network, how they are validated, how the ledger stays synchronised, and why some blockchains can process payments or smart contracts much more efficiently than others.

In this article, we will take a look “behind the scenes” of the intricacy of a typical blockchain architecture built around a proof of stake consensus mechanism. We will also look at why Layer 2 networks exist, and how rollups help blockchains scale without simply pushing all activity through the main chain. But let’s begin at the beginning.

We start with the user

Every blockchain transaction begins with a user and an application.

The application might be a wallet, a decentralised finance platform, a marketplace, or another decentralised app. The user signs the transaction with their private key, which proves that they are authorised to move assets or trigger a smart contract action.

At this stage, nothing has yet been added to the blockchain itself. The transaction is simply a request: “I want to send these funds,” or “I want to interact with this application.”

The next step is getting that request into the network.

The role of RPC nodes and the gateway layer

Like all networks, traffic and requests go through several different stages before they are completed. Most users do not connect directly to the deepest parts of a blockchain network. Instead, transactions are usually submitted through an RPC node — short for remote procedure call node.

Think of the RPC node as an access point, or a gateway that will get you there. It receives requests from wallets, apps, and developer tools, and passes them into the blockchain system. In high-traffic environments, this layer may also include load balancers, proxies, or caching systems to help distribute demand and keep services responsive.

This matters because blockchain networks are not just ledgers. They are also live digital systems that need to handle large volumes of incoming activity. If the access layer is poorly designed, the user experience will suffer long before validation even begins.

Once the transaction has entered the network through this gateway layer, it moves on, closer to the validation process.

The mempool: the “waiting room” for transactions

After passing through the access layer, the transaction usually enters the mempool, or transaction pool.

The mempool is essentially a waiting area for transactions that have been submitted, but not yet finalised. The network checks that the request is valid in basic ways: that the signature is correct, that the sender has the required funds, and that the transaction format meets the network’s rules.

At this stage, the transaction has been submitted to the network, but it is not yet officially part of the blockchain. It is waiting in a queue until validators choose it, place it in the right order with other transactions, and add it to a block.

This matters because a transaction can be visible to the network before it is fully confirmed. In other words, the network can see that the transaction exists before it becomes a permanent part of the shared ledger.

How proof of stake validation works

Ready? This is where proof of stake comes in. The most important part of any blockchain network is validation, which checks the transaction ahead of being incorporated into the block.

In a proof of stake blockchain, the network does not rely on miners solving complex mathematical puzzles, as happens in proof of work systems. Instead, validation is handled by validators: participants who lock up a stake in the network, check the transaction, and are then rewarded for helping to secure it.

When transactions are ready to move forward, validators play a role in checking them and helping the network agree on what should be added next. A block proposer assembles valid transactions into a block, and other validators help confirm that this proposed block is legitimate.

The precise mechanics vary between networks, but the broad idea is the same: the chain moves forward because the network reaches consensus on the next valid state of the ledger.

This process is far more computationally lightweight than proof of work. Why is this useful? Because proof of stake is generally more energy-efficient than proof of work, and it is often better suited to blockchains that need higher throughput and lower latency. That efficiency is attractive to many enterprises.

From execution to block creation

Once a transaction has been selected, the network has to do more than simply store it. It must also process what that transaction means.

For a simple transfer, that may just mean moving a balance from one wallet to another. For a smart contract interaction, it may involve executing code. In Ethereum-based environments, for example, this happens through the Ethereum Virtual Machine, or EVM.

This execution layer matters because blockchains are not static databases. They are state machines. Every new valid transaction changes the state of the network, and the system must determine exactly what that new state is.

After execution, the transaction is incorporated into a block. That block is then proposed, validated, and distributed across the network.

Once consensus is reached, the block is added to the chain. The transaction is now confirmed as part of the shared ledger.

Full nodes, propagation and the distributed ledger

Let’s move on. After a block is accepted, it does not stay in one place. It is propagated across the peer-to-peer network so that the blockchain remains synchronised.

This is where full nodes play an important role. Full nodes store the blockchain’s history and verify the validity of blocks and transactions. Together, they help maintain the integrity of the distributed ledger.

That distributed structure is a core part of blockchain’s appeal. Instead of one central authority updating one private database, many participants maintain and verify the ledger together. That is what gives blockchain its combination of transparency, resilience, and decentralisation.

Why Layer 2 exists

So far, this all sounds logical. But it also raises a problem — read on.

If every transaction has to move through the main chain, validated and recorded in the same shared environment, what happens when activity explodes?

What happens is congestion.

Layer 1 blockchains are powerful, but they are not infinitely scalable. If too many low-value or high-frequency transactions compete for space on the main chain, speed can drop and costs can rise.

This is why Layer 2 networks have become so important.

Layer 2 sits above the main blockchain and handles part of the workload elsewhere, while still ultimately relying on the security of the Layer 1 chain.

In practical terms, this means that large volumes of activity can happen off the main chain, with results later passed back and settled on Layer 1.

How rollups work

If you’ve gotten this far, you’re doing well. Now it’s time to learn about one of the most important Layer 2 approaches: the rollup.

A rollup gathers many transactions together, processes them off the main chain, and then submits the result back to Layer 1 as a bundled update. This reduces pressure on the main blockchain and helps improve throughput. These transactions have to be verified as well, but when they are smaller transactions, networks can be less rigorous about verification. However, there are still processes involved, and

There are two major trust models here.

Optimistic rollups assume that submitted transactions are valid unless challenged. This makes them fast and efficient, but it also means there is usually a contest period during which invalid transactions can be disputed.

Zero-knowledge rollups, often called ZK rollups, use cryptographic proofs to demonstrate that the transactions are valid without revealing all of their underlying details. This can provide strong efficiency and privacy benefits, while reducing the need for long challenge periods.

Once the transaction has been verified in this way, it is incorporated into a block with many other smaller transactions, and passed back to the Layer 1 blockchain.

Both optimistic and ZK models aim to answer the same question: how do you scale blockchain activity without abandoning trust?

That is the real architectural challenge. Layer 2 systems are not simply shortcuts. They are engineering responses to the limits of Layer 1.

Why blockchain architecture matters

It is easy to think of blockchain as a single thing, but in reality it is a stack of interacting layers — a structural foundation.

First, there is the user-facing application. The gateway layer that receives transactions. Then the mempool that holds them. The validator layer that checks and orders them. The execution environment that updates the state of the chain. The full nodes that preserve and distribute the ledger. And, increasingly, the Layer 2 systems that help the whole model scale.

Understanding that architecture helps explain why blockchain performance depends on more than the chain alone. It depends on networking, validation design, software layers, and the infrastructure choices all working together.

That is also why blockchain architecture is now such an important topic for builders, operators, and IT leaders alike. The question is no longer simply “what is blockchain?” — it is “how does this system actually work at scale?”

And the answer lies in the masterful architecture behind it.

Introduction

Dans une nouvelle session Twitch #VeryTechTalk, Rémy (Tech Evangelist) a invité Antonin (Product Manager) et Édouard (IT Team Leader) pour décortiquer la solution Object Storage d’OVHcloud.

Au fil de la discussion, ils ont revisité les débuts du service, expliqué comment il a été repensé autour d’une compatibilité S3, détaillé les mécanismes de résilience et présenté les nouvelles fonctionnalités à venir dans les prochains mois. Cet article de blog reprend les points clés de cette discussion pour vous donner des perspectives sur cette technologie et, qui sait, vous donner envie de la tester !

L’historique du projet

En 2014, OVH proposait HubiC, une offre grand public reposant sur du stockage de fichiers (NAS) accessible via WebDAV. Le modèle fonctionnait tant que les volumes restaient modestes, mais dès que les téraoctets ont commencé à affluer, l’équipe a compris que la mise à l’échelle était limitée.

La solution a alors basculé vers OpenStack Swift, la brique objet du projet OpenStack. Celle-ci a permis de mettre à disposition des clientes et clients une offre d’Object Storage et de gérer les objets à l’échelle du cloud.

En 2020, OVHcloud a racheté OpenIO, une startup déjà experte du stockage compatible S3. Cette acquisition a été le catalyseur du projet.

OpenStack Swift a été conservé pour les usages historiques et une offre compatible S3 a pu voir le jour afin de répondre aux exigences du marché (ex. outils, CI/CD, IA). La première classe compatible S3 a été mise à disposition un an et demi après le rachat, puis d’autres classes (infrequent‑access, hyper‑performance) ont suivi, créant un portfolio multiclasse.

« Il est primordial d’accélérer le développement de cette API  : les outils S3 sont devenus le standard de facto » – Antonin

Le but était de transformer l’Object Storage en une offre générique (multi-usages) capable de couvrir les backups classiques, les workloads de machine learning, les archives légales…

Aujourd’hui, le service se positionne comme le point d’ancrage de nombreuses solutions internes : images d’instances, Logs Data Platform, stockage de logs, etc.

Architecture et évolutivité : un « infini » virtuel

L’équipe gère des centaines de milliers de disques répartis dans les datacenters d’OVHcloud. Cette densité permet de proposer une évolutivité quasi‑infinie. Un des points forts, ainsi qu’une volonté d’OVHcloud, est que l’utilisatrice ou l’utilisateur ne voit jamais le moment où un disque est ajouté ou remplacé, aucune interruption n’est perceptible.

« L’évolution doit être la plus transparente possible. L’utilisatrice ou l’utilisateur ne doit jamais voir un « drop » pendant l’ajout d’un disque. » – Édouard

Toutefois, cette quasi-infinité concernant le volume doit être encadrée, renforcée et tolérante à la panne de certains de ses éléments tout en continuant de fournir un service.

Plutôt que de se contenter de copier les données, le service découpe chaque objet en plusieurs fragments et ajoute des chunks de parité (Erasure Coding). Si une panne survenait sur un disque, un rack ou sur un datacenter entier dans le cas d’un stockage 3-AZ. Les fragments restants permettent de reconstruire le fichier original sans perte. C’est l’un des points forts d’Object Storage.

Dans le cadre du service, OVHcloud assure la durabilité (les données restent intactes) et la disponibilité (accès en permanence) des données. La clientèle, quant à elle, choisit le niveau de résilience  : nombre de copies, réplication asynchrone, versionning, object‑lock…

Cette granularité permet d’ajuster le coût au niveau de criticité des données.

• Durabilité : les données restent intactes grâce à l’Erasure Coding et à la réplication multisite.
• Disponibilité : l’accès aux objets est garanti même lorsqu’une zone de disponibilité (AZ) tombe en panne.

Performance et métriques clés

Dans une infrastructure de cette taille, il existe de nombreuses métriques qu’il est possible d’analyser. Certaines attirent toutefois davantage l’attention des équipes opérationnelles. Édouard nous en détaille trois, qui peuvent également être monitorées si vous possédez une infrastructure dans laquelle vous gérez une plateforme de stockage par vous-même.

Le taux d’erreur, premier signal d’alerte

Le taux d’erreur (500/503) est le premier indicateur de santé du service.

Un pic déclenche immédiatement les mécanismes de retry intégrés aux SDK, de façon transparente pour l’utilisateur ou l’utilisatrice. Ces tentatives successives sont effectuées côté client pour s’assurer que la lecture (ou l’écriture) se déroule dans de bonnes conditions.

Time‑to‑First‑Byte (TTFB) : le vrai baromètre de latence

Le TTFB mesure le temps nécessaire pour délivrer le premier octet, quel que soit le poids du fichier.

Une hausse du TTFB signale souvent une saturation ou un incident dans l’infrastructure. L’équipe surveille ce KPI en temps réel pour anticiper les anomalies. Il s’agit d’un indicateur fort en interne pour la performance et la santé de la plateforme.

IOPS versus capacité disque

Depuis quelques années, les capacités des disques continuent de croître, mais les IOPS restent relativement stables.

Cette évolution crée un IOPS/To décroissant, d’où la nécessité de garder ces métriques sous supervision afin d’anticiper un possible engorgement.

Cas d’usage concrets

Cas n°1 : sauvegarde et archivage

Les clientes et clients peuvent effectuer leurs sauvegardes directement dans un bucket, profiter du versionning et de l’object‑lock, puis restaurer les données en quelques clics. L’archivage sur bande, proposé depuis 2025, offre un coût de 1‑2 €/To avec un TTFB de l’ordre de l’heure, idéal pour les obligations légales de conservation à long terme.

• Versionning : chaque modification crée une nouvelle version, protégeant de la perte causée par les suppressions accidentelles.
• Object Lock (immutabilité) : écriture unique, lecture illimitée ; idéal contre les ransomwares.

Cas n°2 : big data et IA

Les volumes massifs nécessaires à l’entraînement de modèles de machine learning sont stockés en « cold  » sur l’Object Storage, puis déplacés vers les clusters de calcul lorsqu’ils sont requis.

Cas n°3 : services internes d’OVHcloud

Les usages d’Object Storage se démocratisent. Il est normal et nécessaire que les produits OVHcloud aussi tirent parti des bénéfices apportés par cette technologie.

En effet, de nombreux services s’appuient sur elle : images d’instances, logs de la Logs Data Platform, stockage de données froides, etc.

Feuille de route et innovations à venir

Object Storage 2.0

Un backend refondu (nom de code Object Storage 2.0) est en phase de bêta privée. L’objectif est supprimer les soft limits actuelles, réduire le TTFB au minimum et offrir des performances supérieures pour les cas d’usage client à forte granularité (milliers de petits fichiers).

Transparence via la feuille de route publique

Toutes les évolutions sont publiées sur le OVHcloud GitHub. Les utilisateurs et utilisatrices peuvent suivre les tickets, laisser des commentaires et s’inscrire aux versions bêta via le serveur Discord dédié.

Conclusion

L’OVHcloud Object Storage a parcouru un long chemin et est désormais une plateforme multiclasse, capable de gérer des centaines de milliers de disques tout en offrant une résilience de niveau entreprise. L’intégration d’OpenIO a permis d’ajouter une API compatible S3, répondant aux exigences d’interopérabilité du marché. Grâce à l’Erasure Coding, au versionning, à l’object‑lock et aux options de réplication, chaque cliente et client peut ajuster la durabilité et la disponibilité de ses données à son propre coût.

Vous avez un projet cloud native ou avez besoin de sauvegarde à grande échelle ?estez dès maintenant l’Object Storage d’OVHcloud, explorez les différentes stratégies de résilience et partagez vos retours : la communauté technique grandit grâce à vos expériences.

Vous avez aimé cet article ? La vidéo dont il est extrait est accessible sur notre chaîne Youtube, ici : https://www.youtube.com/watch?v=KmS0YhjuYZc

Introduction

In a new #VeryTechTalk session on Twitch, Rémy (Tech Evangelist), was joined by Antonin (Product Manager) and Édouard (IT Team Leader) to unpack OVHcloud’s Object Storage solution.

They chatted about the service’s early days, how it was redesigned to work with S3, its resilience features, and upcoming additions. This blog post rounds up the key points from the chat to give you a fresh take on this technology, and maybe even make you curious enough to try it for yourself.

How the project started

In 2014, OVHcloud launched HubiC, a consumer service based on File Storage (NAS) and accessible via WebDAV. The model was fine with small amounts of data, but when the terabytes started pouring in, the team realised it couldn’t scale enough to keep up.

The solution was then moved to OpenStack Swift, one of OpenStack’s core building blocks. As a result, customers got an Object Storage service that could manage objects at cloud scale.

In 2020, OVHcloud acquired OpenIO, a startup known for its expertise in S3-compatible storage, which set the project in motion.

We kept OpenStack Swift for legacy uses, but launched an S3-compatible service for modern needs like tools, CI/CD, and AI. About a year and a half after the acquisition, the first S3-compatible class launched, followed by others (infrequent-access and hyper-performance), forming a Multiclass Portfolio.

“We need to build this API quickly as S3 tools are now the go-to standard” – Antonin

We wanted to make Object Storage a multi-purpose service, covering everything from classic backups and machine learning workloads to legal archives.

Today, the service acts as the anchor point for many in-house solutions: instance images, Logs Data Platform, log storage, etc.

Architecture and scalability: virtually limitless

The team manages hundreds of thousands of disks, spread across OVHcloud datacentres, which allow for near-limitless scalability. A big plus, and one of OVHcloud’s goals, is that users don’t notice when a disk is added or swapped out – meaning no downtime.

“Scaling should be as transparent as possible. When adding a disc, users shouldn’t notice any drop in performance.” – Édouard

Even so, this near-limitless volume should be kept in check, enhanced and able to handle some failures while still delivering service.

Rather than simply copying the data, the service splits each object into chunks and adds parity chunks (erasure coding). In the case of 3-AZ storage deployments, if a disk, rack, or an entire datacentre fails, we can use the remaining bits to put the original file back together without losing anything. And this is where Object Storage really shines.

As part of the service, OVHcloud ensures durability (data remains intact) and data availability (uninterrupted access). Customers have the option to choose the level of resilience they need: number of copies, asynchronous replication, versioning, and object-lock features.

This granularity helps customers adjust costs depending on how critical their data is.

• Durability: data remains intact thanks to erasure coding and multi-site replication.
• Availability: access to objects is guaranteed even when an Availability Zone (AZ) goes down.

Performance indicators and key metrics

A variety of metrics can be analysed within an infrastructure of this scale. But a few of them are getting more attention from operations teams. Édouard goes over three of them, which are also worth keeping an eye on if you run your own storage infrastructure and setup.

Error rate: an early warning sign

Error rate (500/503) is the first indicator of the solution’s health.

SDKs are set up to retry automatically when there’s a spike, without the user even noticing. These repeated attempts are made on the customer’s end to ensure a successful read (or write).

Time-to-First-Byte (TTFB): the best gauge of latency

TTFB measures the time it takes to deliver the first byte, no matter the file size.

A slower TTFB usually means the infrastructure is overloaded or something isn’t working as it should. The team monitors this KPI in real time so they can get ahead of issues. It’s a reliable internal indicator of the platform’s performance and overall health.

IOPS vs disk capacity

Even though disk sizes have expanded in recent years, their IOPS haven’t really changed.

A larger capacity lowers IOPS per TB, which is why tracking these metrics is necessary to spot potential slowdowns.

Real-world use cases

Use case 1: Backup and archiving

Customers can back up directly to a bucket, use versioning and object lock, and restore data with just a few clicks. Tape archiving, available since 2025, cost about €1–2 per TB with a TTFB of roughly an hour, ideal for long-term, compliant storage needs.

• Versioning: saves a new version for every edit, so nothing is deleted by accident.
• Object Lock (immutability): write once, read many to help protect against ransomware.

Use case 2: Big data and AI

Huge amounts of data for training machine learning models are kept in cold storage on Object Storage and then moved to compute clusters when needed.

Use case 3: OVHcloud internal services

Object storage is becoming more accessible to a wider range of users. It makes sense for OVHcloud products to make the most of what this technology has to offer.

In fact, it supports many services including instance images, Logs Data Platform logs, and cold data storage.

Roadmap and upcoming innovations

Object Storage 2.0

A redesigned backend (codename Object Storage 2.0) is currently in private beta. The goal is to get rid of soft limits, achieve the lowest possible TTFB, and deliver top performance for customer applications with thousands of small files.

Transparency via the published roadmap

All updates are shared on the OVHcloud GitHub. Users can track tickets, leave comments, and sign up for beta versions in our Discord server.

To sum up…

OVHcloud Object Storage has come a long way and is now a multi-class platform, capable of managing hundreds of thousands of disks while providing robust resiliency. OpenIO’s integration now includes an S3-compatible API to keep up with market demand for interoperability. And with erasure coding, versioning, object-lock, and replication options, customers can adjust data durability and availability according to their budget.

Got a cloud-native project or need large-scale backup? Try OVHcloud Object Storage now. Take a look at the different resilience strategies and tell us what you think — your experience can help the tech community grow.

Was this article helpful? You can watch the full video this excerpt is taken from on our YouTube channel here: https://www.youtube.com/watch?v=KmS0YhjuYZc

Docker Agent is an open-source framework for building collaborative multi-agent workflows.
Instead of one monolithic agent trying to do everything, you compose a team of specialized
agents. Each agent has a clear role, specific tools, and its own model, allowing them to
communicate and collaborate on complex, multi-step tasks.

In this post, we’ll explore how to wire up Docker Agent with OVHcloud AI Endpoints to create
a multi-agent coding assistant: one agent browses documentation, another writes the code.

Install/configure Docker Agent

All detailed instructions for installing and configuring Docker Agent can be found in
the official documentation.
Once installed, Docker Agent is available as the docker-agent or docker agent command line
tool.
⚠ Docker Agent does not need Docker engine to run. ⚠

Authenticate with AI Endpoints

To use Docker Agent with AI Endpoints, export your API key:

export OVH_AI_ENDPOINTS_ACCESS_TOKEN="your_api_key_here"

ℹ️ Docker Agent uses the token_key field in the provider configuration to know which environment variable holds the API token, here we name it OVH_AI_ENDPOINTS_ACCESS_TOKEN. ℹ️

Configure the provider and models

AI Endpoints is fully integrated in docker agents. That’s mean that the configuration is very easy as you can see in the official documentation.

One of the strengths of AI Endpoints is the ability to choose the right model for each task. This allows each agent to use a model optimized for its specific role rather than forcing a single model to handle every step of the workflow. Here we use gpt-oss-120b for the crawler, which handles documentation analysis, web browsing and reasoning, while Qwen3.5-397B-A17B is used for the coder due to its strong code generation capabilities.

Create a team of agents for coding

Let’s build a two-agent team: a crawler that fetches documentation from the web, and a coder that turns that documentation into working code.

The crawler uses the fetch toolset to read URLs and passes the extracted context to the coder via the sub_agents mechanism. The coder uses the filesystem toolset to create files and the shell toolset to execute or validate them when needed.

agents:
  crawler: 
    model: ovhcloud/gpt-oss-120b
    description: Documentation crawler
    instruction: |
      You are a documentation crawler.
      Step 1: use the fetch tool to read the URLs provided by the user and     extract the relevant information.
      Step 2: you MUST invoke the coder sub-agent tool with the full context you gathered, so it can write the code.
      Do NOT write the code yourself. Always invoke the coder agent.
    sub_agents: [coder]
    toolsets:
     - type: filesystem
     - type: fetch

coder:
  model: ovhcloud/Qwen3.5-397B-A17B
  description: Coder
  instruction: |
    Write code based on the context provided.
    Ensure code quality and maintainability.
    Save files to disk using the filesystem toolset, use the current path.
   toolsets:
    - type: filesystem
    - type: fetch
    - type: shell

As you can see using an OVHcloud model is very easy: get the model name from the catalog and add ovhcloud/ to the name in the configuration file.

Run the agents

Once your configuration file is ready, run the team with:

docker agent run ovhcloud-agent.yml

Here is the Docker Agent in action:

Conclusion

In this post, we saw how Docker Agent makes it easy to build collaborative multi-agent teams (without requiring Docker engine) and how AI Endpoints fits in naturally thanks to its full OpenAI API compatibility.

AI Endpoints gives you the flexibility to choose the right model for each agent in a multi-agent workflow, all from a single provider configuration. Rather than relying on one model for every task, you can combine specialized models for research, reasoning, coding, content generation, or data processing.

The crawler/coder example shown here is just one illustration of this approach. The same multi-agent pattern can be applied to a wide range of workflows wherein specialized agents collaborate to complete complex tasks more efficiently.

Have questions or feedback? Join the dedicated #ai-endpoints channel on our Discord server.

To learn more about AI Endpoints, please explore our previous blog posts.

Introduction

As part of the new season of OVHcloud’s Twitch channel, Rémy (Tech Evangelist) invited Charbel Harb (Containerisation Sales Specialist) to demystify Rancher, the Kubernetes cluster management platform. During their conversation, they discussed the multicloud advantages of the solution, usage modes and features, as well as potential future developments. This article summarises the key points of their discussion to help you understand how Rancher can lighten the operational load of your Kubernetes environments.

Rancher does not replace Managed Kubernetes; it overlays it

Rancher functions as a Kubernetes cluster management platform: it is installed as a layer on top of your clusters, whether they are hosted with OVHcloud, on bare metal, or with another provider. It does not replace Kubernetes; it complements the solution by providing a graphical interface that replicates actions usually performed in command lines.

“Rancher is a complete multicloud Managed Kubernetes cluster management platform. It does not replace Kubernetes – it’s an overlay.”

OVHcloud focuses on technological freedom and open source. After testing several solutions, Rancher was selected for its agnostic nature and lack of vendor lock-in. Its partnership with SUSE, a European publisher sharing the same sovereignty principles, has led to the launch of a “vanilla” version of Rancher, enriched with some interface adjustments for deploying clusters with OVHcloud.

Multicloud management and deployment flexibility

Rancher offers a single dashboard for both local and remote clusters. It centralises the management of clusters hosted on:

• OVHcloud Managed Kubernetes Service
• Public Cloud or Private Cloud instances self-managed by the client
• Other cloud providers offering a Managed Kubernetes Service

The interface lists all clusters, regardless of their location, as long as they have a public outbound IP address.

Rancher offers two entry points that are easily identifiable:

• Create a new cluster from one of the supported environments (choice of zone, number of AZs, type of nodes, enabling autoscaling)
• import an existing cluster by deploying a small Rancher agent via a kubectl command.

This duality ensures that every member of a DevOps team works in a way that’s comfortable for them, while retaining the ability to automate tasks via scripts.

User experience: GUI vs CLI

Rancher caters to both profiles:

• users who prefer clicking: creating clusters, sizing node pools, and deploying applications can be done in a few clicks, without memorising long kubectl syntaxes.
• experts who prefer the power of the terminal: the interface includes a kubectl terminal that allows commands be directly executed on the cluster, even from a bastion or a computer without local installation.

This duality ensures that every member of a DevOps team works in a way that’s comfortable for them, while retaining the ability to automate tasks via scripts.

Integrated application catalogue: monitoring, observability and security

Rancher includes a catalogue of applications (Helm charts),  including Prometheus and Grafana, that are pre-installed and free. 

In just a few clicks, you can add a monitoring layer to your cluster and immediately visualise metrics like CPU, RAM, network load and logs.

“The application catalogue is a toolbox that solves many issues.”

These tools facilitate quick debugging and provide enough visibility to initiate finops actions (scale-up/scale-down, resource optimisation) even though Rancher is not a financial management product.

Security and access control

Rancher integrates complete role-based access control (RBAC).
You can create user groups, assign them predefined roles (read, write, administration), and link them to external authentication providers such as LDAP or SSO. This granularity prevents human errors and strengthens compliance with internal policies.

Internal architecture: the brain and the agent

Rancher Manager operates within its own dedicated Kubernetes cluster, shared for all OVHcloud customers. Each managed cluster has a Rancher agent that receives instructions from the administration console. During creation, this console automatically deploys the agent. During import, the user executes the provided command to install the agent. This architecture ensures reliable communication while maintaining the isolation of client workloads.

Roadmap and development perspectives

The product is currently stable, and several areas for improvement are underway:

• support for “private” mode (clusters without public IPs) to meet the requirements of isolated networks
• integration of AI assistants to generate prompts for creating clusters or managing users, further reducing the number of clicks required.

These developments align with our goal of offering an increasingly smooth and automated experience for DevOps teams.

Conclusion

Rancher positions itself as a versatile tool for Kubernetes management: it centralises multicloud clusters, offers an intuitive graphical interface, integrates a catalogue of ready-to-use applications, and ensures granular security via RBAC.

“The first piece of advice is really to try it. Give yourself some time to measure the gain.”

If you’d like to test this solution, we are currently offering a free trial of the Managed Rancher service. Start a test cluster, explore the application catalogue, and measure how much time you save in your DevOps processes.

Over to you! Contact our team, schedule a personalised demonstration session, and discover how Rancher can transform the management of your Kubernetes environments.

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.