OVHcloud Object Storage: Notes for Storafleet's Providers Page

OVHcloud Object Storage is an S3-compatible object storage service. It is not a platform, not a filesystem, and not a synonym for the whole of OVHcloud's cloud. When someone types that name into a search box they usually mean one of a dozen products: bare metal, Public Cloud instances, managed Kubernetes, hosted private cloud, web hosting, domains. The part that matters to us is the object storage bucket behind an S3 API, because that is the part we can talk to.

And that is the whole interoperability story. If it speaks S3, we connect to it. OVHcloud Object Storage sits in the same list as Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO, Scaleway, DigitalOcean Spaces and the rest. No special connector, no plugin, no per-provider integration work. Same list, same code path.

OVHcloud Object Storage is S3-compatible, and that is the whole interoperability story

The precise definition is that OVHcloud exposes an S3-compatible API surface, not the S3 service. Those are different claims and the difference is load-bearing. OVHcloud runs its own storage behind its own endpoints. What it publishes is the API contract: the verbs, the signing scheme, the XML error bodies, the multipart upload dance. Any client that has implemented that contract can point at it.

The endpoint shape is region-scoped:

https://s3.<region>.io.cloud.ovh.net

Pick a region, and the hostname changes with it. OVHcloud's object storage regions include gra (Gravelines), sbg (Strasbourg), de (Frankfurt), uk (London), waw (Warsaw), bhs (Beauharnois), syd (Sydney) and sgp (Singapore), so a bucket in Gravelines lives at s3.gra.io.cloud.ovh.net and one in Sydney at s3.syd.io.cloud.ovh.net. The region is not decoration. It is part of the address, and getting it wrong gives you a signature error that reads like a credentials problem when it is not.

Bucket names follow the standard S3 constraints: lowercase letters, digits, hyphens and dots, three to sixty-three characters, no uppercase, no underscores, must start and end alphanumeric. Dots work but they break virtual-hosted-style addressing over TLS in the usual way, so we use path-style where we can and stop arguing about it.

Authentication is an access key and a secret key, generated in the OVHcloud control panel, scoped to a user. That is what you paste into a connection. Two fields, and we test them before saving by listing buckets.

The consequence is that OVHcloud needs no special handling from us. It is one of 50+ S3-compatible providers we connect, plus any custom endpoint you type in by hand. If you are checking whether your provider is in the list before you sign up for anything, the list is at storafleet.com/providers. OVHcloud is on it.

Public S3-compatible endpoints are a feature, not a limitation

S3 compatibility matters more than any single provider's feature list. Not because S3 is elegant. It is not. It is an API accreted over nearly two decades with some genuinely strange corners. It matters because it is the one object storage interface that everybody implemented, which means your tooling works across providers, your migration path exists before you need it, and you can move without rewriting anything.

Compare that to a provider with a proprietary API and a nicer feature set. The features are real. So is the exit cost, and the exit cost is invisible until the day it is not.

Because OVHcloud is S3-compatible, it is a first-class source and destination for everything we do. Migration. Scheduled sync. Cross-bucket search across OVHcloud and other providers in one query. Lifecycle rules, CORS, versioning, object lock and public access configuration. Duplicate detection. Per-bucket cost visibility. None of that requires OVHcloud-specific code, because none of it requires OVHcloud-specific anything.

Concrete example. Say you have a media-prod bucket in s3.gra.io.cloud.ovh.net and you want a copy in Cloudflare R2 for egress reasons, refreshed nightly. You add two connections, point a scheduled sync job from the OVHcloud bucket to the R2 bucket, set the interval, and save. That is the whole task. No rclone.conf, no cron entry, no systemd timer, no shell script that someone has to remember exists. It runs nightly and tells you when it fails.

Portability is the point of the standard, and the standard is why we can exist at all. A control plane over object storage only works in a world where object storage converged on one API. It did. We are the beneficiary of that, not the cause of it.

What we do with OVHcloud, and what it costs

We charge a flat subscription, and we never charge per gigabyte to move data. Migrated bytes are unmetered on every tier including Free. That is not a promotional rate or a launch offer. It is the pricing model, and it is the model because metering bytes would make us charge you more for doing the thing you came here to do.

What actually differs between tiers is concurrency and automation: how many migration jobs run at once, and whether scheduled sync is available. A one-time move of a few hundred gigabytes on Free is fine, it just runs with fewer parallel jobs. Recurring nightly sync across providers is a paid feature.

Credentials are encrypted at rest with AES-256-GCM under per-namespace HKDF keys. Each customer namespace derives its own key, so a dump of one row is not a dump of the table.

One honest asymmetry: AWS can be connected keylessly via IAM role assumption, and OVHcloud cannot. OVHcloud does not offer an equivalent cross-account role path for its S3 API, so OVHcloud credentials are stored encrypted, not keyless. Encrypted is not the same as never having left your machine. We will come back to that in the concession section, because it deserves the space.

That is not a limitation dressed up as a principle. It is the architecture. It means the blast radius of anything going wrong on our side is configuration, not your data.

Where rclone genuinely beats us, and we are not going to pretend otherwise

rclone is better than us for a large number of people, and the honest answer for many readers of this post is: use rclone. Not "consider rclone as a complement". Use it. It is free, permanently, with no account, no subscription and no vendor. It supports far more backends than we do, 70+, including the consumer clouds we deliberately do not touch. It mounts. It is scriptable to a degree a web UI can never match. It runs entirely inside your own security boundary, so your credentials never leave hardware you control. And it has been maintained for over a decade, which means when you ask "will this still work in five years", rclone has a better answer than a company that started in 2026 and is, we will say it plainly, a small team.

We have no published case studies and no named customers to point at. We are not going to invent them for a blog post. If a decade of maintenance history matters more to you than a console with scheduling built in, that is a reasonable thing to care about and rclone wins that comparison outright.

So here is who should not use us.

• Your budget is zero. The conversation is over and rclone wins. Do not sign up for a free tier you will resent managing.
• You need storage mounted as a local drive. We have no FUSE surface. Nothing appears in Finder or Explorer. Use rclone mount, Mountain Duck or ExpanDrive.
• You need Google Drive, Dropbox, OneDrive, Box, SFTP or WebDAV. We connect the S3-compatible family and custom S3 endpoints, and nothing else. Use rclone or MultCloud for consumer-cloud work. CloudFuze covers the enterprise end of the same problem.
• Credentials must never leave hardware you control. Our encryption is real, but "the keys never left my laptop" is a stronger guarantee than ours and it would be dishonest to pretend otherwise. rclone. If it is AWS only, our IAM role connect avoids storing a secret at all, and that is the one case where we are on the same footing.
• Everything lives in one cloud and always will. The provider's own console is free, authoritative and always current with that provider's newest features. We are not. For OVHcloud-only work, use the OVHcloud console.
• The workflow is entirely code and always will be. 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. A CLI fits that natively and a web UI never will.

Also worth naming: Cyberduck, Mountain Duck and S3 Browser are better than us for a single person managing a few buckets who wants a one-time licence or a free desktop client with no subscription and files that stay on their machine. If that is you, buy the licence and skip us.

The case for us is blending, not replacing

If OVHcloud is the only place your data will ever live, the OVHcloud console is free, authoritative, and always current with OVHcloud's newest features. Use it. We mean that. There is no version of this where a third-party control plane knows about a provider's new capability before the provider does.

We are for the case where OVHcloud is one of several providers and the job is policy across them. That is the throughline. One place to define a scheduled sync from Gravelines to R2. One place to search across an OVHcloud bucket, a B2 bucket and a MinIO instance you run yourself. One place to spot that the same 40 GB of video exists in three buckets under three names. One place to see what each bucket is costing and which one has not been read in a year. One place to set lifecycle rules, CORS, versioning, object lock and public access, and to see all of it side by side rather than in three different consoles with three different vocabularies.

That is the product. Not a better OVHcloud console. A single policy layer over the fact that you ended up with four providers and no consistent way to reason about them.

What happens if you sign up: you connect OVHcloud with an access key and secret key, we validate them, and you can move a bucket or schedule a sync in the next ten minutes. What it costs: a flat subscription, with migrated bytes unmetered on every tier including Free, and the paid tiers buying you more concurrent migration jobs and scheduled sync. If OVHcloud is your only provider and you have no plans to change that, close this tab and go use the console you already pay for.