OVH Public Cloud: Getting Started Guide for DevOps Teams

OVH Public Cloud offers a competitive alternative to AWS and Azure for European companies. Here is a practical guide to deploying a complete DevOps stack.

Why OVH Public Cloud in 2025?

OVH is Europe's largest hosting provider, operating more than 40 data centres across four continents. In 2025, several converging trends are strengthening its appeal for DevOps teams: rising digital sovereignty requirements in Europe (the EU AI Act, France's Cloud de Confiance programme, SecNumCloud qualification), growing organisational pressure to reduce dependency on US hyperscalers, and genuine pricing competitiveness — most notably the absence of data-egress fees between OVH zones, which can represent several thousand euros in monthly savings for data-intensive workloads.

OVH is not merely a cheaper AWS. It occupies a distinct position: infrastructure hosted exclusively on European soil, subject only to European law, and eligible for SecNumCloud qualification for sensitive French public-sector data. For organisations subject to GDPR or sectoral regulations (finance, healthcare, defence), these are not marketing points — they are hard requirements that US hyperscalers, subject to the CLOUD Act, structurally cannot satisfy.

Key Services for a DevOps Stack on OVH

MKS (Managed Kubernetes Service): fully managed Kubernetes compatible with standard manifests, Helm charts, and operators. The control plane is managed and upgraded by OVH; worker nodes run on OVH bare metal, delivering better price-to-performance ratios than equivalent AWS managed nodes.
Object Storage (S3-compatible): drop-in S3 replacement — any tool that speaks the S3 API (Terraform S3 backend, AWS CLI, Rclone, MinIO client, application SDKs) works without modification. No vendor lock-in at the storage layer.
Managed Private Registry (Harbor): Docker image registry hosted in Europe with full RBAC, vulnerability scanning (Trivy integration), and replication. Your images stay in Europe and never transit US infrastructure.
AI Deploy: GPU-based inference and training infrastructure for ML workloads, available in European regions with the same sovereignty guarantees.
Managed Databases: PostgreSQL, MySQL, Redis, Kafka, and OpenSearch as fully managed services. Compatible with standard connection strings — no application changes needed when migrating from another provider.

Provisioning an MKS Cluster with Terraform

The OVH Terraform provider covers the full OVH Public Cloud API and is published on the Terraform Registry. Here is a production-ready cluster configuration with autoscaling node pools:

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = "~> 0.40"
    }
  }
  # Store Terraform state in OVH Object Storage (S3-compatible)
  backend "s3" {
    bucket                      = "my-terraform-state"
    key                         = "prod/k8s/terraform.tfstate"
    region                      = "gra"
    endpoint                    = "s3.gra.io.cloud.ovh.net"
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
  }
}

provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = var.ovh_application_key
  application_secret = var.ovh_application_secret
  consumer_key       = var.ovh_consumer_key
}

# Managed Kubernetes cluster
resource "ovh_cloud_project_kube" "prod" {
  service_name = var.ovh_service_name
  name         = "prod-cluster"
  region       = "GRA9"
  version      = "1.29"

  customization_apiserver {
    admissionplugins {
      enabled  = ["NodeRestriction"]
      disabled = []
    }
  }
}

# Autoscaling node pool — scales between 2 and 10 nodes
resource "ovh_cloud_project_kube_nodepool" "workers" {
  service_name  = var.ovh_service_name
  kube_id       = ovh_cloud_project_kube.prod.id
  name          = "general-workers"
  flavor_name   = "b3-32"    # 8 vCPU, 32 GB RAM
  desired_nodes = 3
  min_nodes     = 2
  max_nodes     = 10
  autoscale     = true
}

Using OVH Object Storage as the Terraform state backend means your infrastructure state is stored in Europe alongside your workloads — no cross-border state file storage, no dependency on an S3 bucket in us-east-1.

CI/CD Pipeline with GitHub Actions and OVH Registry

A complete build-push-deploy pipeline targeting OVH infrastructure follows the same structure as any cloud-native CI/CD workflow — only the registry and kubeconfig endpoints differ:

# .github/workflows/deploy.yml
name: Build and Deploy to OVH

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Login to OVH Managed Registry (Harbor)
        uses: docker/login-action@v3
        with:
          registry: ${{ vars.OVH_REGISTRY_URL }}
          username: ${{ secrets.OVH_REGISTRY_USER }}
          password: ${{ secrets.OVH_REGISTRY_PASSWORD }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ vars.OVH_REGISTRY_URL }}/my-app:${{ github.sha }}
          cache-from: type=registry,ref=${{ vars.OVH_REGISTRY_URL }}/my-app:cache
          cache-to: type=registry,ref=${{ vars.OVH_REGISTRY_URL }}/my-app:cache,mode=max

      - name: Deploy to OVH Kubernetes (MKS)
        uses: azure/k8s-deploy@v4
        with:
          kubeconfig: ${{ secrets.OVH_KUBECONFIG }}
          namespace: production
          images: ${{ vars.OVH_REGISTRY_URL }}/my-app:${{ github.sha }}
          manifests: k8s/overlays/prod/

The Harbor registry supports layer caching, which significantly reduces build times for images with large dependency layers. The kubeconfig stored in GitHub Secrets should be scoped to a service account with the minimum permissions required for the deployment namespace only.

Monitoring with Prometheus and Grafana on MKS

kube-prometheus-stack deploys identically on OVH MKS as on any other Kubernetes cluster, with one OVH-specific adjustment: the storage class name. OVH uses Cinder-backed block storage managed via the CSI driver:

# values.yaml — OVH MKS adapted configuration
grafana:
  adminPassword: "replace-with-vault-secret"
  persistence:
    enabled: true
    storageClassName: csi-cinder-high-speed   # OVH high-performance block storage
    size: 10Gi
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-prod
    hosts:
      - grafana.myapp.example.com
    tls:
      - secretName: grafana-tls
        hosts: [grafana.myapp.example.com]

prometheus:
  prometheusSpec:
    retention: 30d
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: csi-cinder-high-speed
          resources:
            requests:
              storage: 50Gi

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: csi-cinder-high-speed
          resources:
            requests:
              storage: 5Gi

The csi-cinder-high-speed storage class maps to NVMe-backed Cinder volumes, providing the IOPS needed for Prometheus's time-series write workload. The standard csi-cinder-classic class is adequate for Grafana's lighter usage pattern.

OVH vs AWS vs Azure: A Practical Comparison

For European regulated workloads, the comparison is not purely about feature parity — sovereignty and compliance credentials carry real weight in procurement decisions:

Criterion	OVH Public Cloud	AWS (EU regions)	Azure (EU regions)
Data sovereignty	European law only	Subject to US CLOUD Act	Subject to US CLOUD Act
SecNumCloud	Eligible	Not eligible	Not eligible
Compute (8 vCPU)	~€0.08/h (b3-32)	~€0.14/h (m6i.2xlarge)	~€0.16/h (D8s v5)
Data egress	Free between OVH zones	€0.08/GB after 1 GB/month	€0.07/GB after 5 GB/month
Managed services count	~50 services	200+ services	200+ services
Kubernetes (managed)	OVH MKS — standard K8s API	EKS — extensive add-ons	AKS — deep Azure integration
Support	Business support from €100/month	Business from ~$100/month	Developer from $29/month

The egress pricing difference is particularly significant for data-intensive workloads. A platform transferring 10 TB per month between services would pay approximately €800/month in AWS egress fees — zero on OVH. Over a year, that difference funds a dedicated engineering quarter.

Conclusion

OVH Public Cloud is production-mature for European workloads. Its compatibility with standard APIs — S3 for storage, the standard Kubernetes API for compute, standard PostgreSQL/MySQL connections for databases — means you avoid most forms of vendor lock-in while keeping your data and workloads on European infrastructure under European law.

For French and European companies subject to data sovereignty requirements, or those simply looking to reduce cloud costs without compromising on quality, OVH deserves a formal evaluation. The migration cost is lower than it appears: if your current stack is built on standard open-source tooling (Terraform, Helm, Docker, standard SQL), moving to OVH is a configuration change, not a re-architecture.