Introduction

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

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

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

All set? Let’s get started.

Launching an instance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adding Storage

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

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

OVHcloud provides three categories of block storage volumes:

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

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

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

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

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

Mounting the Volume

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

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

ssh ubuntu@IPaddress

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

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

lsblk

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

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

sudo fdisk /dev/sdb

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

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

sudo mkfs.ext4 /dev/sdb1

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

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

sudo mkdir -p /mnt/chaindata

sudo mount /dev/sdb1 /mnt/chaindata

df -h

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

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

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

sudo blkid

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

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

sudo nano /etc/fstab

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

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

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

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

Create a dedicated user

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

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

echo 'node_admin:MySuperPassword123' | sudo chpasswd

sudo mkdir -p /home/node_admin/.ssh

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

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

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

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

Ethereum Preliminaries

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

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

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

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

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

Execution Clients (EL):

• Geth
• Nethermind
• Reth
• Besu
• Erigon

Consensus Clients (CL):

• Lighthouse
• Prysm
• Teku
• Nimbus
• Lodestar

For this guide, we will use the following combination:

● Execution Client: Nethermind

● Consensus Client: Lighthouse

Installing Nethermind (Execution Client)

Step 1: Add the Nethermind APT Repository

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

sudo add-apt-repository ppa:nethermindeth/nethermind

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

sudo apt-get install software-properties-common

Step 2: Update the Package Index

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

sudo apt-get update

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

Step 3: Install Nethermind

Now install the Nethermind binary:

sudo apt-get install nethermind -y

Installing Lighthouse (Consensus Client)

Step 1: Download the Latest Stable Release

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

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

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

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

Step 2: Extract the Archive

Once downloaded, extract the archive:

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

This will place the lighthouse binary in your current directory.

Step 3: Verify and Move the Binary

Test the binary to ensure it is working:

./lighthouse –version

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

sudo cp lighthouse /usr/bin

Create the JWT Secret File

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

Step 1: Create a Secrets Directory

sudo mkdir -p /secrets

Step 2: Generate the JWT Token

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

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

Using screen for Session Persistence

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

Check if screen is installed:

screen –version

If not installed:

sudo apt-get install screen

Setting Ownership for /mnt/chaindata

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

sudo chown $USER:$USER /mnt/chaindata

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

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

Launching Nethermind (Execution Client)

Step 1: Create a Screen Session

screen -S nethermind

Step 2: Run Nethermind

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

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

Waiting for Forkchoice message from Consensus Layer

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

Step 3: Detach the Session

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

Step 4: List Active Sessions (Optional)

screen -ls

To reattach later:

screen -r nethermind

Launching Lighthouse (Consensus Client)

Step 1: Create a New Screen Session

screen -S lighthouse

Step 2: Run Lighthouse Beacon Node

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

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

Step 3: Detach the Session

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

Verifying Synchronization Between EL and CL

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

Step 1: Reattach to the Nethermind Session

screen -r nethermind

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

Step 2: Check for Communication Messages

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

Waiting for Forkchoice message from Consensus Layer

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

Received ForkChoice: ...
Syncing...

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

Conclusion

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

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

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

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

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

An industrial shift towards GPUs

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

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

The consequences of this were immediate and noticeable:

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

A sustained inflation of memory components

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

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

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

A market under pressure, even with higher prices

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

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

Towards a new global balance of demand

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

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

Our strategy to soften the blow

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

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

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

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

Continuous investments and developing solutions

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

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

In practical terms, this will result in:

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

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

Time frame and implementation procedures

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

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

A time of uncertainty and a strategic advantage

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

Our Prices

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

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

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

Un basculement industriel vers les GPU

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

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

Les conséquences sont immédiates et visibles :

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

Une inflation durable des composants mémoire

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

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

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

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

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

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

Vers un nouvel équilibre mondial de la demande

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

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

Notre stratégie pour amortir le choc

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

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

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

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

Investissements continus et évolution des offres

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

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

Concrètement, cela se traduit par :

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

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

Calendrier et modalités d’application

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

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

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

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

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

Nos tarifs

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

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

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