Why I Chose OVHcloud: Sustainability, Data Sovereignty, and Building Independent Infrastructure Part 1

14 November 2026
Jonathan Aquilina - Eagle Eye T
Cloud , Infrastructure , Open Source Software

A metallic eagle watches over two data centres connected by a glowing gold fibre link.

I chose OVHcloud because I wanted to rent the hardware and network capacity while keeping control over how I run, secure and recover my services.

I’m funding this infrastructure myself, independently of OSS Malta at this time. That makes the monthly bill part of the engineering decision. A design that looks good on paper has to stay affordable when backups grow, downloads pick up or i need another server. It also has to be something I can maintain alongside a full time IT career.

Three things stood out when I compared my options:

OVHcloud has its own back bone network.
Dedicated server offerings with predictable costs including public transfer.
Sustainability.

I wanted to see what the provider measured, what the figures covered, and how much they could tell me about the workloads I would actually run.

This is the first article in a series on building that infrastructure. It starts with the provider decision because that decision shapes everything that follows such as the virtualization platform, the network, identity, backups and how I recover when something goes wrong.

Why Predictable Costs Mattered More Than a Cheap Starting Price

The cost of a server is easy to compare, but the cost of running a service on it is much harder.

A monthly compute price says little about what happens when you add storage, keep backups off site or move a large amount of data during a recovery. A project can spend months using very little bandwidth and then need to move a large volume in a single afternoon. I wanted a hosting model I could budget for during both.

For the dedicated server offers I was considering the combination of hardware pricing and included public traffic. This made OVHcloud a better fit for this build.

OVHcloud describes its dedicated server public traffic as unmetered. The detail I care about is what the selected offer includes, because an unmetered transfer allowance and a guaranteed throughput rate answer different questions.

Consider a restore, If transfer is included, that helps me estimate the bill. How quickly the restore completes still depends on the throughput available between the backup destination and the recovery host, plus how quickly both ends can read and write the data. I have to plan for cost and recovery time separately.

I’d check the exact server offer, region and contract before buying. I’d also price public bandwidth and private connectivity separately. An upgrade that makes downloads faster won’t necessarily improve the path I use for replication.

There’s still a good case for services from AWS, Azure or Google Cloud when managed operations or rapid scaling are the priority. I was comparing a different proposition: whether dedicated capacity and a stack I operate myself made sense for the services I intend to run, and for this project they did.

What the Backbone Gives Me, and What I Still Have to Design

OVHcloud operates a backbone that connects its data centers. That was one of the reasons I chose it, If I want to place workloads in more than one location, I want to understand the network between those locations as well as the connection from each one to the internet.

That affects everyday operations. A private path might carry replication, backups or traffic between services. Each puts different demands on the network. A large backup can tolerate a slower transfer. Cluster coordination needs consistent communication, and an application makaing repeated database calls can feel the effect of latency even when the link has plenty of bandwidth.

I’m designing around questions I can test:

How long does a representative replication job or restore take?
What happens to normal service traffic while a large transfer is running?
If a site loses connectivity, which services keep working and which require intervention?
Which dependencies do two locations still share because they’re with the same provider?

That last question matters. Geographic separation can protect against some local failures, while both locations may still depend on the same provider account or services. Understanding those shared dependencies tells me which failures my design can handle and where I need a separate recovery option.

What Data Sovereignty Means for This Build

For me, data residency starts with where data is stored. Data sovereignty is the broader question of who controls it, who can access it, and under which terms and jurisdictions.

OVHcloud’s European presence and the ability to select where workloads run mattered to me. Its data sovereignty overview explains the company’s position on the legal and operational controls for services it supplies to European customers. I use that as a starting point and look at the terms of the particular service when I need to establish what applies.

The primary server is only one stop in the life of the data. A Backup might live with another provider. A monitoring service might retain logs in another location. An off site copy might be encrypted, but I still need to know who controls the keys and whether I can recover them if I lose access to my main account.

Question	What I Want To Establish
Where is the data?	The locations of the primary workload, backups, replicas and logs.
Who can access it?	Which people or service accounts have access, including how support access is handled.
Who controls recovery?	Where the backups and keys are kept and whether I can use them without my original host.
Can I leave?	Whether I can export the data and recreate a working service elsewhere.

The European Commission’s explanation of the EU Data Act puts provider switching and interoperability in a wider context. On my side the useful test is practical: can I take a backup, restore it somewhere else, and get the application working with its data and permissions intact? A clean export is a good start. A working restore tells me a lot more.

That’s the same principle behind the user sovereignty goal I described when introducing EagleEye Linux. Control has to show up in what you can do when the default path is no longer available.

What I Could Verify About Sustainability

OVHcloud describes using water cooling in its data centers, including closed circuits that move heat away from servers. Its FY2025 Sustainability Statement publishes figures for energy and water efficiency, with reporting boundaries that matter when you interpret the results.

Metric	OVHcloud's FY2025 Figure	What It Tells Me
Power Usage Effectiveness (PUE)	1.24	Within the reported scope, the facility used 1.24 units of total energy for each unit used by IT equipment.
Water Usage Effectiveness (WUE)	0.34 L/kWh	The reported water use relative to IT energy consumption, using OVHcloud’s reporting methodology.

Those are provider reported FY2025 figures. The FY2025 Universal Registration Document includes a statutory auditor’s limited assurance report covering the sustainability disclosures within its stated scope. That is useful context for the disclosure. It does not independently measure my servers, establish the footprint of my workloads, or prove that every site performs at the reported figure.

PUE also answers a narrower question than “how sustainable is this infrastructure?” As the Uptime Institute explains, it measures facility overhead relative to IT energy. It does not tell you how efficiently the IT equipment does useful work. A lightly loaded server can still waste energy in a facility with a good PUE.

Water use needs similar care. A closed cooling loop describes how water circulates inside part of the cooling system. It doesn’t tell me the total water footprint of a facility or the impact of water use in that location. I’d need comparable site level measurements and reporting boundaries to rank providers fairly. I don’t have that evidence for this build.

What I can influence is how much infrastructure I run and how I use it. I can size workloads realistically, consolidate services where it makes sense, and add redundancy where the cost of downtime justifies it. I can also set retention based on what I might need to recover rather than keeping every copy indefinitely. Those choices matter regardless of which provider houses the equipment.

The Trade Off: More Control Means More Work

When I operate the software stack, I decide how to segment services, apply updates, manage identities and store backups. I also have to do that work and make sure it holds up under pressure.

Running a virutal machine is the easy part. The harder part is being able to explain what it depends on, who can reach it, where its data goes and what I would do if its host disappeared tonight. A provider can replace failed hardware. I still need a way to bring my services back.

That is why i’m treating this as a series rather than a shopping list. A virtualization platform, firewall, identity servce and backup system each solve a different problem. What matters is whether they work together when something fails. If recovering my identity service requires credentials available only through that same identity service, I have created a dependency I need to resolve before I can call the system recoverable.

The Singularity asks:

If the prover account or a primary host became unavailable tomorrow, which services could I recover, and what would I need to do it?

I don’t need every service back in the same amount of time. I do need ot know what must come back first and have a recovery path I have actually tried.

What Comes Next In The Series

Part 2: Building A Geographically Distributed Proxmox Cluster.

I will look at what changes when nodes are separated by distance: how latency and quorum affect the design, what storage replication buys you, and how failover differs from recovery.

The Proxmox VE administration guide is a useful starting point because cluster communication needs consistently low latency. Two servers in different places don’t automatically make a reliable high availability design.

After that, I’ll cover:

Post	What It Will Cover
Proxmox VE	A standalone look at the platform, storage choices and day to day vm operations.
OPNsense & Dominion	The Edge firewall’s role, how traffic reaches services and where to draw trust boundaries.
Running Forgejo On Proxmox	Operating a self hosted Git service, including access, upgrades and recovery.
FreeIPA	What centralizing Linux identities and host access changes for an administrator
Keycloak with FreeIPA for SSO	How application sign in and the underlying identity directory fit together
Proxmox Backup Server	Backup retention, off site copies and what a restore test should prove.
Moving to IPv6 Only Backends	What I learned about connectivity, compatibility and troubleshooting, with the live configuration kept private.

Final Thoughts

OVHcloud made sense for my project because I could budget for the capacity i needed, choose where to run workloads, and use a provider operated backbone while managing the software stack myself. Its environmental reporting gave me figures i could examine, with limits I could understand.

The next test is what I build on top of it. Can I lose a host and bring back the services that matter? Can I restore outside the original environment? Can I do that without discovering an undocumented dependency halfway through?

That is where the Proxmox article picks up.

Remember The Singularity is always watching.

Call To Action

When you choose a hosting provider, what carries the most weight? Is it predictable costs, data location, managed services, or how easily you can move away?

Share your experiences in the comments below and follow EagleEye Technology for Part 2, where ill get into the decisions behind a geographically distributed proxmox setup.

Sources