OVH Object Storage: When It Fits and When It Doesn't

Choosing an object storage provider is not the decision that matters. I know that sounds like a dodge from a company selling storage tooling, so let me earn it. The thing people get wrong about ovh object storage is that they treat it as a destination, as the answer to a question. It is not. It is one endpoint. A competent, cheap, S3-compatible endpoint sitting in a European datacentre, and once you have decided the endpoint is the interesting variable, you have already made the mistake that costs you a weekend six months from now. The endpoint is the least interesting variable in the setup. What you drive it with is where projects actually go wrong.

OVH object storage is cheap S3 with a European accent, and that is basically correct

The widely repeated claim is that OVH Object Storage is just commodity S3-compatible storage with a French datacentre behind it. A forum commenter will tell you "it is S3, it is cheap, what else is there." That claim deserves a real examination rather than a reflexive defence of complexity, and here is where I land: it mostly holds.

The API shape is S3. That is the whole point, and it is true. You get buckets, keys, a REST interface that speaks the S3 dialect, and signing that any S3 tool already knows how to perform. If you have ever pointed an S3 client at a non-Amazon endpoint by changing a config value, you already know how to point one at OVH. There is no proprietary protocol to learn, no OVH SDK you must adopt, no lock-in at the wire level. That is a genuine and underrated property. It means the switching cost between OVH and any other S3-compatible provider is roughly one line in a config file.

The region model is per-datacentre, and that shapes latency and compliance more than any feature list. OVH runs this out of its own datacentres, so your choice of region is a choice about where the bytes physically sit. For a European company with European data residency obligations, that is not a footnote. It is often the entire reason to look at OVH in the first place.

The pricing model is usage-based, metered on storage and requests and egress, which is the same shape as the hyperscalers. I am not going to quote you a number, partly because I do not want to be wrong in six months and partly because OVH publishes its own numbers and you should read them there rather than trust a blog. What matters is the shape: you pay for what you store and what you move, and the meter runs whether you are watching or not.

So the myth holds. OVH Object Storage is cheap S3 with a European accent. If that were the whole story, this post would be three sentences long.

Here is the part the claim misses: "is it any good" is the wrong question, and it was never the hard one. Every serious S3-compatible provider is good enough at the wire level now. The differences that bite you are not in the storage. They are in the tooling around it: how you browse it, how you sync it, how you search across it, how you configure lifecycle and CORS without reading three documents, and how you figure out what a given bucket is actually costing you. Those are the questions that determine whether a project feels smooth or feels like a part-time job. And those questions are identical whether the endpoint is OVH, Cloudflare R2, Backblaze B2, Wasabi, MinIO or Amazon.

The endpoint was never the hard part; the console around it is

A bucket is a bucket. OVH's S3 compatibility means any S3 tool speaks to it. That is the blessing and the curse of the whole category. The blessing is that you are never trapped. The curse is that you are never done, because "any S3 tool" is a universe of options and none of them were designed with your specific combination of five providers in mind.

The friction is never the upload. It is everything that surrounds it. Browsing a bucket you cannot see is annoying. Syncing between two buckets owned by two different providers means two sets of credentials and two mental models. Searching across buckets means searching them one at a time. Configuring lifecycle rules means reading the provider's documentation for that provider's specific quirks. Duplicate detection is a script you write yourself and then forget how it works. And knowing what a single bucket costs you, when the bill arrives as one number for the whole account, is a small ongoing mystery.

None of that is OVH's fault. OVH gives you an endpoint and a console for that endpoint, and by the standard of provider consoles it is fine. It is the same problem every provider has: their console is excellent at showing you their storage and blind to everything else.

This is the gap we built Storafleet into. Storafleet is a control plane for object storage you already own. Your buckets stay where they are. Your credentials are yours. We never store your file contents, only the metadata and configuration needed to drive them. You bring an endpoint, we give you a console that browses, syncs, searches and configures across it.

For OVH specifically, connecting is a matter of supplying your S3 credentials and the endpoint. OVH gives you an endpoint per region, in the recognizable S3 endpoint pattern, and a Storafleet provider entry looks roughly like this:

{
  "provider": "ovh",
  "label": "ovh-gra",
  "endpoint": "s3.gra.io.cloud.ovh.net",
  "region": "gra",
  "access_key_id": "<your-access-key>",
  "secret_access_key": "<your-secret-key>",
  "path_style": true
}

The endpoint is the OVH S3 host for the region you chose. The region matches it. path_style is true for most non-Amazon S3-compatible providers, OVH included, because virtual-host-style addressing assumes DNS you may not control. Swap gra for sbg or de and you are pointed at a different datacentre. That is the whole connection. There is a walkthrough on our docs at storafleet.com/docs/connect/ovh if you want the field-by-field version, and it is worth a read before you paste credentials anywhere, ours included.

The point is not that we invented a way to talk to OVH. Anyone can talk to OVH. The point is that once OVH is one row in a list of providers, the questions that used to require four separate consoles and a shell script become one console. That is the product. The endpoint is table stakes.

Fifty providers in one console is the whole product, and it is also its limit

Storafleet connects 50+ S3-compatible providers plus any custom endpoint you can describe. Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO, DigitalOcean Spaces, Oracle Cloud, IBM Cloud Object Storage, Scaleway, Linode, Vultr, Storj, IDrive e2, Hetzner Object Storage, OVH, and a long tail of others. If it speaks S3, we can usually speak to it. If it speaks a custom S3 dialect, you can hand us the endpoint and we will try.

Fifty is a smaller number than it sounds, and you should hear that from us rather than discover it later. rclone supports more backends than we do, 70+ at last count, and it reaches into consumer clouds we deliberately do not touch. The count is not the product. If backend count is how you are choosing, rclone is ahead of us and will stay ahead of us, because adding a non-S3 backend is cheap for a project that mounts and expensive for a control plane that has to model auth, rate limits and quirks in a schema. We chose depth in one family over breadth across five. That choice costs us the breadth.

What you do with that list is the actual work. Migrate or sync between any two providers, as a one-time job or on a schedule. Search globally across every bucket you have connected, not one bucket at a time. Configure lifecycle rules, CORS, versioning, object lock and public-access settings from a single surface instead of four. Detect duplicates so you are not paying to store the same file three times under slightly different names. See per-bucket cost visibility so the monthly bill stops being a single terrifying number and starts being a set of decisions you can act on.

The pricing model matters here because it is deliberately boring. Storafleet is a flat subscription. We never charge per gigabyte to move data. Migrated bytes are unmetered on every tier, including Free. Tiers differ on concurrent migration jobs and on automation, meaning scheduled sync. That is it. We do not want a meter on your data movement, because the moment we have one we have an incentive to see you move more, and you should be suspicious of any tooling company whose revenue scales with your egress.

On credentials, we take the boring-correct path. Credentials are encrypted at rest with AES-256-GCM using per-namespace HKDF keys, so a compromise in one namespace does not hand over the others. For AWS specifically, you can connect keylessly via IAM role assumption, which means no long-lived secret key ever exists in our database for that account. That is the strongest option we offer and we would like it to be the only one, but the other providers do not all support the equivalent, so for OVH and most of the list, you paste credentials and we encrypt them.

Now the concession, and I mean it.

If you are reading this and thinking "this sounds like rclone with a web UI," you are not wrong, and rclone beats us in ways that are not close. rclone is free, permanently, with no account and no vendor. It supports more backends than we do, 70+ at last count, including the consumer clouds we deliberately do not touch. It mounts, which we cannot. It is scriptable in the way a binary is scriptable and a web console never will be. It runs entirely inside your own security boundary, so the credentials genuinely never leave your hardware. And it has been maintained for over a decade by people who are not us.

That last one is the one I think about. There is a version of this comparison where a prospective customer asks "why would I pay you when rclone exists and is free" and the honest answer is that for a large number of people, they should not, and rclone is the correct choice. I will say more about exactly who in the last section.

Cyberduck and Mountain Duck are further genuine winners in their niche. Desktop clients, one-time licence or free, files stay on your machine, and Mountain Duck mounts remote storage as a drive. For a single person managing a handful of buckets who wants no subscription and no browser tab, they are better than we are. And the providers' own consoles win too. OVH's console is free, always current with whatever OVH shipped last week, and authoritative in a way a third party can never be. If all your data lives in OVH and always will, the OVH console is the right answer and we are an unnecessary layer.

Fifty providers in one console is the whole product. It is also the limit of it. We are useful precisely when you have more than one, and dead weight when you have exactly one.

We do not mount, we do not speak to Drive, and the keys are in our database

Here is the list of things we do not do, verified and not softened.

No FUSE. No local drive. No Finder or Explorer surface. We do not mount storage as a filesystem. If you want a remote bucket to appear as a folder on your laptop, we cannot give you that and rclone mount, Mountain Duck and ExpanDrive can. This is not a roadmap item we are coyly hinting at. It is a thing we do not do.

We connect the S3-compatible family and custom S3 endpoints, and nothing else. No Google Drive, Dropbox, OneDrive, SFTP, WebDAV or Box. If your job is Drive-to-bucket, we are the wrong tool and you should stop reading and go install rclone or look at MultCloud. We made that choice deliberately. Every non-S3 backend is a different auth model, a different rate-limit behaviour and a different set of quirks, and we would rather be excellent at one family than mediocre across five.

Your credentials sit encrypted in our database, not on your own hardware. The encryption is real, AES-256-GCM with per-namespace HKDF keys, and AWS can be connected keylessly through IAM role assumption so no secret exists with us at all. But "the keys never left my laptop" is a stronger answer than ours, and it would be dishonest to pretend otherwise. If your threat model does not permit credentials to leave hardware you control, we are not the right place to put them, and rclone running on that hardware is.

We are a console, not a command. We do not compose with cron, systemd, CI pipelines, shell scripts or Makefiles the way a binary does. You cannot pipe into us. You cannot storafleet sync --dry-run | grep failed. If your workflow is code, a CLI fits it natively and a web UI never will, no matter how many webhook features we bolt on.

We have no published case studies and no named customers to point at. We will not invent them. Every "trusted by" logo wall you have seen on a page like this one is a decision someone made, and we have made the opposite one: we would rather show you the product and the limits than manufacture social proof.

And we are a small team. Storafleet started in 2026. On the question "will this still exist in five years," a decade-old open-source project with a broad contributor base has a better answer than we do, and it is not close. If long-term survival of your tooling vendor is a hard requirement, that is a legitimate reason to choose the older option, and we would rather you choose knowingly than be surprised.

Who should not use Storafleet for OVH object storage

The verdict, plainly, without a sales pivot at the end.

If your budget for this is zero, the conversation is over and rclone wins. Not "rclone wins on price but consider us for the UI." rclone wins. It is free, it is excellent, it has been maintained for over a decade, and it covers more ground than we do. Go use it.

If you need storage mounted as a filesystem, we cannot help and you should not stretch to make us fit. rclone mount, Mountain Duck and ExpanDrive all do this. We do not.

If you need Google Drive, Dropbox, OneDrive or SFTP in the mix, rclone or MultCloud. We deliberately do not speak those protocols, so a workflow that depends on them is not a workflow we can serve, and no amount of clever configuration on your side will change that.

If your credentials must never leave hardware you control, rclone is the answer, or our IAM-role connect if and only if the target is AWS. For OVH, which does not offer us the keyless equivalent, credentials come to us encrypted or they do not come at all, and if that is unacceptable then it is unacceptable and you should use a tool that runs where the keys live.

If everything lives in one cloud and always will, use that provider's own console. OVH's console is free, it is more current with OVH's newest features than we will ever be, and it is authoritative. We are an unnecessary layer in that world and we will not pretend otherwise to win a subscription.

And if the workflow is entirely code and always will be, use a CLI. A console does not compose. A CLI does. That is the whole argument and it does not have a rebuttal.

So who is Storafleet actually for? A team running buckets across several S3-compatible providers, including OVH, who wants one console instead of five. A team that needs scheduled sync between providers and does not want to own the cron job and the error handling and the retry logic that comes with it. A team that wants to search across every bucket at once, configure lifecycle and CORS without reading four sets of docs, and see what each bucket costs before the invoice arrives. If you will pay a flat subscription for that and find the encryption and the keyless AWS path acceptable, we built this for you and the OVH connection takes about two minutes. If that is not you, the alternatives above are not consolation prizes. They are the right answer, and we would rather say so than sell you something you will outgrow in a month.