S3 Compatible Storage Providers and Compliance Requirements

• "S3 compatible" describes an API surface, not a compliance posture
• The compliance question is mostly about who holds the paper
• WORM, object lock, and the difference between immutable and compliant
• CAP, ITAR, TAA, FedRAMP: four different regimes, four different questions
• The three provider shapes you are really choosing between
• Side by side: hyperscaler, compliance specialist, self-hosted
• Where each provider shape genuinely wins
• Where a control plane fits, and where it is beside the point
• Managing object lock across 50+ S3-compatible providers from one console
• What Storafleet does not do, and who should not use us for this
• The checklist we would hand an auditor, and the parts you cannot outsource

What "S3 compatible" actually promises, and what it does not

"S3 compatible" is a claim about an API surface. That is all it is. Any provider can implement PutObject, GetObject, ListObjectsV2, DeleteObject and the signature dance that goes with them, and then hand you a service with no audit report, no residency guarantee, no retention enforcement and no legal hold. The verbs are the easy part. The verbs have been the easy part for fifteen years.

People searching for s3 compatible storage providers usually mean one of two things, and they rarely separate them. The first is literal: which providers speak the S3 wire protocol so my existing tooling works against them. The second is the one that actually matters: which providers will survive my auditor asking how I enforce a seven-year retention obligation on a bucket, who can delete the evidence, and where the bytes physically sit. Those are different questions. The first is a protocol question. The second is a governance question, and the protocol answer tells you almost nothing about it.

The fuzzy version, the one we see in procurement docs, goes like this: "the provider is S3 compatible, therefore it works like AWS, therefore it has the governance story AWS has." That does not follow. AWS has a governance story because of the certifications it holds, the audit reports it publishes, the control plane it exposes and the contracts it signs. S3 compatibility is a subset of one of those four things. A provider can be byte-perfect on the S3 API and still have never seen the inside of a SOC 2 audit, still have no answer for data residency, and still let an admin with the root key delete a bucket that was supposed to be immutable for a decade.

So this post is about picking an S3-compatible storage provider on the dimensions an auditor asks about, not the dimensions a benchmark measures. It is also about where a control plane like ours fits, which is a narrower place than the marketing on our own homepage might suggest, and we will say so at length further down. If you're here for the five-minute version: pick the provider on paper first, then pick your tooling, then write down who can change retention and how you would prove it in a courtroom. The tooling is the easiest of the three and the one people spend the most time on.

The compliance question is mostly about who holds the paper, not who holds the bits

Certifications, audit reports, data residency commitments, retention enforcement and legal hold are provider-side obligations. Your control plane configures them. Your control plane does not hold them. There is no tool you can install, ours or anyone else's, that turns a provider without a SOC 2 into a compliant storage layer. The paper comes from the provider. The tool configures the bucket. Those are different links in the chain and only one of them is auditable.

Here is the shape of it. When your auditor asks "how do you know only authorised personnel can read this data", the answer is the provider's access control documentation, the provider's SOC 2 report, the provider's encryption story, and the contract. When your auditor asks "how do you know this object cannot be deleted before 2031", the answer is the provider's object lock implementation and the retention mode you set, plus the log showing who set it. When your auditor asks "where does this data live", the answer is the region you selected and the provider's residency commitment, not the console you used to select it.

What your tool contributes is the configuration layer and the evidence that configuration is correct. That is real work. It's just not certification work. We wrote a longer version of what we mean by compliance on the Storafleet side, and the short version is that we help you configure and verify; we do not and cannot certify.

The practical consequence is that you should shop providers first. Get the SOC 2 Type II report in your hands. Request the ISO 27001 certificate and check the scope statement, because scope statements are where the surprises live. Find out what the residency commitment looks like in the contract, not on the pricing page. Confirm whether object lock is available on the tier you are actually buying, because at several providers it is not available on the cheap tier and the pricing page will not tell you that in a heading. Establish whether legal hold is exposed in the API you are going to use or only in the console.

Then, and only then, decide what sits on top. The order matters because the tool can only configure what the provider exposes. If the provider has no object lock, no control plane on earth can give you immutable objects. We can show you a nice red badge that says the bucket has no retention. That is the extent of our power over a provider that does not implement the feature.

One more thing about the word "compliant". There is no such thing as compliant storage in the abstract. There is storage that satisfies a specific control in a specific framework for a specific data set in a specific jurisdiction. "WORM compliant" means something concrete. "CAP compliant" means something different. "ITAR compliant" is a third thing and mostly not about the storage at all. The rest of this post takes those apart one at a time, because conflating them is how people end up with a bucket they think is compliant and a finding they did not expect.

WORM, object lock and the difference between an immutable bucket and a compliant one

WORM means write once, read many, and in S3 terms it is implemented with object lock, which requires versioning. That is the whole mechanic. Object lock turns on versioning whether you asked or not, because immutability only means anything if there is a version history behind it. Then you set a retention mode and a retention period on objects, or on the bucket as a default, and the provider refuses deletes and overwrites until the clock runs out.

There are two retention modes and the difference is not cosmetic.

• GOVERNANCE mode: users with the right IAM permission (s3:BypassGovernanceRetention and the corresponding header on the request) can delete or shorten retention. This is the mode for "I want protection against accidents and casual deletion, but I need an escape hatch for the legal team."
• COMPLIANCE mode: nobody can delete the object or shorten the retention, including the account root. Not support. Not you. The only way out is to wait. This is the mode that shows up in financial records retention and in some regulated health contexts, and it is the mode people mean when they say WORM.

If you set GOVERNANCE and call it WORM in a policy document, you have written something an auditor will eventually disprove, because the escape hatch is a real permission held by real identities. We have seen this exact finding. It is common because governance mode is the default people reach for, it sounds official, and it is reversible when you get it wrong during testing. The reversibility is the problem.

Legal hold is the other half and it is a separate flag. PutObjectLegalHold with ON prevents deletion regardless of retention expiry, indefinitely, until someone with the right permission turns it off. It is not a retention period. It has no clock. It is a human assertion that this object is now evidence, and it is the mechanism you use when litigation starts and you need a hold that outlives whatever retention window you set two years ago.

The mechanics, concretely, look like this in the AWS CLI, and most S3-compatible providers mirror the flag names closely enough that the same command works with a different --endpoint-url:

aws s3api put-object-lock-configuration \
  --bucket contracts-archive \
  --object-lock-enabled-for-bucket \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 2555
      }
    }
  }'

That sets a bucket default of seven years, compliance mode. New objects inherit it. Existing objects do not, which is the first gap people miss. If you enable object lock on a bucket that already has a million objects, those objects have no retention until you explicitly apply it, and applying it retroactively is a per-object operation, not a bucket setting. There is no "backfill retention" button in S3. You write a script or you use something that writes the script for you.

An immutable bucket is not a compliant bucket. This is the sentence the rest of this section exists to defend. Immutability is a property of the objects. Compliance is a property of the whole arrangement: the provider's certifications, the residency of the data, the retention policy written down and approved, the identity that can change that policy, the logs that record when it changed, and the restore test that proves you can actually read the data back when you need it.

You can have a perfectly immutable bucket with no audit trail of who set the retention, on a provider with no SOC 2, in a region you cannot name, with no documented restore procedure. Every object in it is undeletable. None of it is compliant. The checkbox in the console is green.

There are also providers where object lock exists but is incomplete. Watch for these specifically, because they are the ones that pass a demo and fail an audit:

• Object lock available on the API but no bucket default retention, so every object needs explicit retention set by the writer. If the writer forgets, the object is unprotected and nothing tells you.
• Governance mode implemented, compliance mode not. This is more common than you would think on smaller providers, because compliance mode is a hard promise and hard promises are expensive to keep at scale.
• Legal hold not exposed in the API. If it is console-only, you cannot automate it, and an auditor will ask how you guarantee it was applied.
• Retention set but DeleteObject returns success anyway and the object disappears later. Trust but verify. Test the delete against a locked object and confirm it fails.

That last one is not hypothetical paranoia. The way to verify object lock is to try to break it. Put an object, set compliance retention, attempt the delete with every permission you have, and confirm the provider says no. If it says yes, you have learned something important before the auditor did.

CAP, ITAR, TAA, FedRAMP: what each one actually constrains

These four acronyms get used interchangeably in procurement conversations and they are not interchangeable. Each one constrains a different thing. Getting them confused produces the specific failure where someone buys storage that satisfies the wrong requirement and then discovers the real one three weeks before an assessment.

CAP: the audit regime, not the storage

People searching for "cap compliant storage" usually mean one of two things. If you are in a regulated industry, CAP most often refers to the compliance attestation regime an auditor works under, and what it constrains is the audit itself: the standards the auditor applies, the evidence they collect, and the report they produce. There is no storage product that is "CAP compliant" in the way there is storage that implements object lock, because CAP is about the attestation process, not the wire protocol.

In a different context, CAP could be the Cloud Appliance Profile, or a sector-specific control set, or an internal acronym. This is the first thing to nail down with whoever is asking. Which CAP, and which document defines it? The answer changes everything downstream, and it is a two-minute question that saves a quarter of guessing.

What CAP almost always implies for storage: evidence. Whatever the specific regime, the auditor is going to want to see the provider's control documentation, your configuration, and a trail showing the configuration has not drifted. That is the same shape as the SOC 2 story. The storage layer's job is to be configurable and loggable. The provider's job is to hold the report.

ITAR: residency and access, not encryption

ITAR is about who can access the data and where it is, and it is mostly not a storage feature. The International Traffic in Arms Regulations restrict access to defence articles and technical data to US persons, and the storage implications are: the data must be under US jurisdiction, access must be restricted to US persons, and the provider must be able to support that restriction contractually and technically. Encryption does not fix an ITAR problem. Encryption is not a substitute for access control, and "but it's encrypted" is not an answer the Directorate of Defense Trade Controls accepts.

Practically, ITAR-compliant cloud storage means: US regions only, provider personnel access restricted and documented, the provider able to sign the relevant terms, and your own access control mapped to the US-person requirement. Several hyperscalers have government or defence-specific regions for exactly this. Smaller S3-compatible providers usually do not, and that is not a criticism, it is a fact about what it costs to build and certify a region for this. If you have ITAR data, the provider list is short and the storage cost is not the interesting number.

One thing people get wrong: ITAR is not a certification the provider holds. There is no "ITAR certified" badge. It is a regulatory obligation on you, the exporter, and the provider's role is to give you a jurisdiction and an access control story you can rely on. When a vendor's page says "ITAR compliant," read it as "we have a US-only region and we will sign the terms," and verify the second half with your legal team before you move a byte.

TAA: the trade agreement, and it is narrower than people think

TAA compliance is about where the service is delivered from, and it is a Trade Agreements Act question, not a technical control. If you are selling to the US government under a GSA schedule or similar, the TAA says the products and services you supply must come from a designated country. For cloud storage, that maps to: where is the provider incorporated, where do the personnel who operate the service sit, and where does the data reside. A provider with a US region but a support organisation in a non-designated country is not automatically a TAA problem, but it is a question your contracting officer will ask and you need a documented answer.

The TAA is narrower than ITAR. It does not care about US persons specifically. It cares about country of origin. And like ITAR, there is no "TAA compliant" certificate. There is a country-of-origin analysis, and the provider either gives you the documentation to do it or they do not.

FedRAMP: the one with an actual authorisation

FedRAMP is the one of the four where a provider actually holds something you can point at. A FedRAMP authorisation is an assessment against NIST controls, performed by a third-party assessment organisation, reviewed and granted by a government body, and published in a marketplace where you can look it up. It has an impact level: Low, Moderate, or High. It has an authorisation boundary that tells you exactly which services are covered, and the boundary is the part people skim and then get burned by, because storage is often in scope while the fancy analytics feature next to it is not.

If you need FedRAMP, your provider options are a short list and the storage decision is downstream of the authorisation decision. You do not get to pick a clever S3-compatible startup because the pricing is nicer. The authorisation is the gate and there is no way around it.

Regime	What it constrains	Does the provider hold a certificate?	The question to ask
CAP (compliance attestation)	The audit process and evidence standard	No, it governs the auditor, not the vendor	"Which CAP, defined by which document?"
ITAR	Who can access, and under which jurisdiction	No formal certificate exists	"US region, US-person access control, will you sign the terms?"
TAA	Country of origin of the product or service	No formal certificate exists	"Where is the company, where are the operators, where is the data?"
FedRAMP	NIST control baseline, at a specific impact level	Yes, an authorisation with a boundary	"What is the authorisation boundary and is storage inside it?"

The throughline: only one of these four gives you a piece of paper with the provider's name on it that you can hand to someone. The other three are analyses you perform and document, using evidence the provider supplies. That asymmetry is why "is this provider compliant" is the wrong question. The right question is "which regime, and what evidence does it require, and can this provider give me that evidence in writing."

The three provider shapes you are really choosing between

Underneath all the brand names there are three shapes. Hyperscaler, compliance-specialist S3 vendor, and self-hosted S3 behind your own controls. Almost every provider you will evaluate is one of these, sometimes dressed up, and the shape determines the compliance story far more than the logo does.

Shape one: the hyperscaler. Amazon S3, Azure Blob with its S3-ish compatibility layer, Google Cloud Storage with its interoperability mode, Oracle Cloud, IBM Cloud Object Storage. The defining property is that they hold the certifications directly and have held them for years. SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, PCI, FedRAMP at multiple impact levels, HIPAA-eligible services, regional commitments in writing. The audit paper is the product as much as the storage is. The cost is that you pay for it, in money and in the complexity of the IAM model, and the egress pricing is a line item people underestimate until the first bill.

Shape two: the compliance-specialist S3 vendor. Providers whose entire pitch is S3 compatibility plus a specific compliance posture, often at a price point the hyperscalers cannot match because they are not paying for a hundred other services. Some are genuinely built for regulated workloads with object lock, residency guarantees and audit reports. Some are S3-compatible storage with a compliance page. The distinguishing test is the same for all of them: ask for the SOC 2 report and the scope statement, and see how fast it arrives. A provider that has one sends it. A provider that does not sends a security whitepaper and hopes you will not notice the difference.

Shape three: self-hosted S3. MinIO or Ceph on your own hardware, in your own rack, in your own building. The compliance story is entirely yours to write, which is either the whole point or the whole problem depending on your organisation. If you have the staff, the physical security, the audit capability and the appetite, this is the only shape where you hold every link in the chain yourself. If you do not, it is a way to turn a storage bill into a headcount problem and an audit finding.

Most teams evaluating S3-compatible storage providers are choosing between shapes one and two and occasionally considering three because someone in the room has strong opinions about sovereignty. All three are legitimate. What is not legitimate is picking on price and then discovering the compliance shape does not match the requirement. The price difference between shapes one and two is real and it is not large enough to justify re-doing a migration.

Side by side: hyperscaler, compliance specialist, self-hosted

The dimensions that actually decide this are not throughput and not price per gigabyte. They are the ones an auditor, a lawyer and an ops engineer each ask about, and they pull in different directions.

Dimension	Hyperscaler	Compliance-specialist S3 vendor	Self-hosted (MinIO / Ceph)
Certifications you can hand over	Broad and current. SOC 1/2/3, ISO 27001/27017/27018, PCI, FedRAMP at multiple levels, HIPAA-eligible services, all published	Varies enormously. Some hold SOC 2 and ISO 27001 with a clear scope statement. Some hold nothing and describe it as "enterprise-grade security"	None held by a vendor, because there is no vendor. You produce your own audit evidence, or you hire someone to
Object lock and WORM	Full implementation, both modes, legal hold in the API, bucket defaults, per-object retention	Usually present, sometimes incomplete. Compliance mode and legal hold are the two features to test specifically	Depends on the version and configuration. MinIO supports object lock; Ceph has object lock support that varies by release and by how it is deployed
Data residency	Region selection with contractual commitments, plus sovereign and government regions in some jurisdictions	Often the strongest selling point: single-jurisdiction operators, explicit commitments, sometimes physically in-country	Wherever your rack is. Total control, total responsibility, including the physical security audit
Audit surface	Extensive logging and access analysis tooling, mature, but the surface is large and the IAM model is genuinely complex	Smaller surface, simpler model, easier to explain to an auditor, fewer features to accidentally misconfigure	Whatever you build. You own log retention, tamper resistance, and the argument that the logs are trustworthy
Pricing shape	Per-gigabyte storage plus per-request plus egress. The egress line is where budgets go to die	Usually flat per-terabyte with no egress, or egress included up to a threshold. Predictable, and the reason many teams move	Capital cost for hardware plus staff time plus the power and cooling. Predictable only if you are honest about the staff line
Ops burden	Low. It is someone else's problem, and there is a support contract	Low to moderate. Smaller providers sometimes have thinner support windows, so read the SLA	High. You are now running a distributed storage system. This is a real job and it does not pause for holidays
Time to first compliant bucket	Hours, but the compliance paperwork takes weeks and involves your legal team	Hours to days, depending on how fast they return the audit report	Weeks to months, and the audit readiness work is the long pole
Exit cost	Egress is the lock-in mechanism and it is priced accordingly	Usually low or zero egress, which is why the migration is easy and why nobody fights to keep you	You own the hardware, so exit means moving data to something else and writing off the rack

Read that table with one thing in mind: the certification column is the only one where you cannot fix a bad answer with engineering. You can work around an awkward API. You can script around a missing feature. You cannot work around a provider that has no audit report, because the report is not a technical artefact, it is an attestation by a third party about the provider's controls. If the report does not exist, no amount of cleverness on your side creates it.

Where each provider shape genuinely wins

The hyperscaler wins when the certification list is the requirement and the budget has room for the egress bill. If you are selling to enterprises, to the US government, or to anyone whose procurement process asks for a FedRAMP authorisation by name, you are going to end up on a hyperscaler or a provider with equivalent authorisations, and the pricing conversation is downstream of that. Their object lock implementation is complete, the audit reports are current, the residency commitments are contractual, and the support contract means you can escalate. The complexity is real and the bill at the end of the year is real, but there is no scenario where a compliance-specialist startup with no FedRAMP authorisation is the correct answer for a federal workload. We will say that plainly because it is true and because pretending otherwise would cost us nothing in the short term and everything in the long term.

The compliance-specialist S3 vendor wins on price and on residency, when and only when they can produce the paper. The pattern that works: you need object lock, you need a specific jurisdiction, you have a per-terabyte budget that a hyperscaler blows through on egress alone, and your compliance requirement is SOC 2 plus ISO 27001 plus a residency commitment rather than a federal authorisation. In that case a specialist provider with the reports and the region is the correct answer and the hyperscaler is overkill. The failure mode is picking the specialist on price before verifying the paper, then discovering in the assessment that the SOC 2 covers a different entity or excludes the storage service. Scope statements matter. Read them.

Self-hosted wins when the data cannot leave your control and you have the people to run it. Sovereignty, air-gapped environments, defence work, and any situation where the answer to "who has physical access to the disk" must be "people on our payroll, in our building, which we can show you." MinIO on hardware you own is a legitimate answer to that, and no hosted provider can match it because the whole point is that no third party is involved. The cost is that you now operate a distributed storage system, you own the audit evidence, and the staff who know how are the staff you cannot easily replace. If you have that team, self-hosted is genuinely the right call and the hosted options are genuinely wrong. If you do not, it is a trap.

The shape that is never correct: picking a provider because the pricing page is simple, then discovering the compliance shape does not match. We see this in the migration requests that come to us, which is a biased sample, but the pattern is consistent. Someone moved to a cheaper provider, the provider turned out to have no object lock on the tier they bought, and now they are migrating back and the migration is the cheap part. The re-certification conversation is not.

Where a control plane fits, and where it is beside the point

Storafleet is a control plane for object storage you already own. That is the whole product. You bring the buckets, we give you a console that connects to them over the S3 API, and we configure things. We never store your file contents. Not as a policy, as an architecture: the data path goes provider to you, and our servers hold metadata and credentials and nothing else.

What that means concretely. We connect to 50+ S3-compatible providers, Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO, DigitalOcean Spaces, Oracle Cloud, IBM Cloud Object Storage, Scaleway, Linode, Vultr, Storj, IDrive e2, Hetzner, plus any custom S3 endpoint you point us at. Against those buckets we can browse, upload, download, migrate and sync between providers on a schedule, search across buckets globally, configure lifecycle rules, CORS, versioning, object lock and public-access settings, detect duplicates, and show per-bucket cost. Credentials are encrypted at rest with AES-256-GCM using per-namespace HKDF keys, and AWS can be connected keylessly by IAM role assumption if you would rather not hand over a key at all.

On object lock specifically, be clear about what we are and are not. Our object lock management across those 50+ providers is configuration only, not enforcement. We write the retention configuration to the bucket through the provider's API and we read back what the provider reports. The provider's implementation is what actually refuses the delete. If the provider does not implement compliance mode, or implements it badly, our console cannot create the guarantee and will not claim to. We show you what is set. The provider enforces what is set.

So where does that fit in a compliance conversation? Three places, and no more.

• Configuration. Object lock, versioning, lifecycle and public-access block are the settings that decide whether a bucket is compliant, and they are tedious and error-prone to set correctly across many buckets and many providers. That is exactly the kind of work a control plane should do. Set the default retention once, apply it to the buckets that need it, and have a single view of what is set where.
• Verification. The gap between "we set retention on this bucket" and "every object in this bucket has retention" is where findings live. A console that can list buckets and show which ones have object lock enabled, which have a default retention rule, and which have public access turned on is a pre-audit tool. Not a certification, a pre-audit tool.
• Evidence of configuration drift. If someone turns off versioning on a locked bucket, or enables public access on a bucket that should not have it, you want to know. Not because we prevent it, because we show it.

Where a control plane is beside the point: everything upstream and downstream of configuration. We do not hold the certification. We do not sign the residency commitment. We do not produce the SOC 2 report. We do not guarantee retention enforcement; the provider does, and if the provider's implementation is broken, our console will faithfully show you a green badge on a broken bucket. We do not do the legal analysis of what retention period applies to which data. We do not replace your auditor, your lawyer or your provider's compliance team. If the question is "is this arrangement compliant," the answer comes from those four parties and our console is a small input to one of them.

That is the honest scope. The tool configures and shows. The provider certifies. The lawyer interprets. The auditor decides. Anyone selling you a product that claims to collapse those four into one is selling you the fourth one's job, and the fourth one has professional liability insurance for a reason.

Managing object lock across 50+ S3-compatible providers from one console

The reason a control plane earns its subscription is that the work is repetitive and the failure mode is silent. Here are three things we actually do, in enough detail that you can judge whether they are worth anything to you.

Turning on retention for one logical bucket across three providers

You have a records archive. For reasons of cost and residency it lives in three places: a primary on a compliance-specialist provider in your jurisdiction, a copy on a hyperscaler for a specific team that insists on it, and a cold copy on cheap storage for the ten-year tail. Three providers, three consoles, three slightly different implementations of the same S3 API, and one retention policy that has to be identical on all three or the auditor asks why the copies differ.

Doing this by hand means three logins, three sets of credentials, three CLI profiles, and a put-object-lock-configuration call against each with the right endpoint. It is not hard. It is just the kind of thing that gets done once, correctly, and then drifts, because the person who did it leaves and the documentation says "object lock is enabled" without saying which mode or what period or whether the bucket default is set.

In our console you connect the three providers, select the bucket on each, and set the retention configuration in one place. Same mode, same period, applied across all three. The configuration is stored as metadata against each connected bucket so the next person can see what was set and when, without logging into three providers. That is the entire value proposition in one workflow: the configuration is identical because it was entered once, and the record of what was set lives somewhere other than someone's memory.

The thing we do not do here, and it matters: we do not apply retention to existing objects for you. Enabling object lock on a bucket sets the default for new objects. Backfilling retention onto a million existing objects is a different operation, per object, and whether it is possible depends on the provider. Our console will show you which objects lack retention, and some providers will let you set it in bulk through the API. But if you are expecting a button that makes a pre-existing bucket retroactively immutable, that button does not exist in S3 and it does not exist in our console either.

Checking for gaps before an audit

Two weeks before an assessment, the question is: which of our buckets that should have object lock do not have it. This is not a question you can answer by looking at a list of bucket names. You need to enumerate every bucket across every provider, check the object lock configuration on each, compare against the list of buckets that are supposed to be locked, and find the difference.

Manually that is a script per provider and a spreadsheet to reconcile. In our console it is a list: every connected bucket, its object lock status, its versioning status, its public-access setting. Sort by object lock status and the gaps are the ones with the feature off. The reconciliation against your list of "buckets that should be locked" is still your job, because we do not know your retention policy, but finding the technical gaps is ours.

Two specific things this catches that people miss. First, buckets created after the policy was written that nobody thought to lock, because the person who created them did not know about the policy. Second, buckets where object lock was enabled but versioning was later suspended, which on some providers silently breaks the retention guarantee. Both show up as a status that does not match the expectation, which is the entire point.

Spotting buckets with public access enabled

This is the finding that shows up in the news, not just the audit. A bucket that should be private, is not, and has been that way since someone was debugging a CORS issue in 2023. The S3 API exposes this through the public access block settings and the bucket policy, and the answer is not always obvious from either one in isolation, because a permissive bucket policy combined with a public access block that is off is a different risk than a public access block that is on with a policy that tries to grant public read.

Our console shows the effective public-access status per bucket across every connected provider. Not the individual settings, the effective answer: is this bucket reachable by an unauthenticated request, yes or no. When you have fifty buckets, the difference between checking each one and reading a list is the difference between it getting done and it not getting done. We have no idea why public access is on for a given bucket. That is your call to make. Getting the list of buckets where it is on, in one view, is the part we do.

What this looks like when it goes wrong

A team connects four providers, sets compliance-mode retention on their archive buckets, and moves on. Six months later an auditor asks for evidence that retention is enforced. They go to the console, and three of the four buckets show the retention configuration they set. The fourth shows something different: governance mode, set two months after the initial configuration, by an identity nobody recognises.

That is the finding. Not that retention was off, but that it was changed, and the change was reversible, and nobody noticed for two months. Whether the console would have caught it depends on whether anyone looked, which is a people problem and not a tooling problem. But the tooling is what makes it visible at all, and a console that shows current state per bucket with the configuration history is the difference between finding that in an afternoon and finding it during the assessment.

We are not going to claim this happens to everyone or cite a statistic, because we do not have one and we will not make one up. We will say that the configuration-drift scenario is the one people describe to us when they explain why they are looking for a control plane in the first place, and it is the one our product is actually shaped around.

What Storafleet does not do, and who should not use us for this

We are going to list the things we cannot do, and then tell you who should use something else. This is not a humility exercise. If you buy our product expecting one of these and it turns out we do not do it, you have wasted money and we have wasted your time, and the refund does not recover either.

• We do not mount storage as a local drive. There is no FUSE surface. Remote buckets do not appear in Finder or Explorer. If that is the requirement, we cannot do it and we will not pretend a console is a substitute.
• We connect the S3-compatible family and custom S3 endpoints, and nothing else. No Google Drive, no Dropbox, no OneDrive, no SFTP, no WebDAV, no Box. If the job is Drive-to-bucket, we are the wrong tool.
• 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 by IAM role assumption so no long-lived key exists at all. But "the keys never left my laptop" is a stronger answer than ours and it would be dishonest to claim otherwise.
• 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. If your workflow is code, a CLI fits it natively and a web UI never will.
• We have no published case studies and no named customers. We will not invent them. If your procurement requires references, we cannot supply them and you should factor that in.
• We are a small team and Storafleet started in 2026. On the question "will this still exist in five years," a decade-old open-source project has a better answer than we do. That is a real risk and you should price it in.

Now the verdict, plainly.

If your budget for this is zero, the conversation is over and rclone wins. rclone is free, permanently, with no account and no vendor. It supports more backends than we do, well over seventy including the consumer clouds we deliberately do not touch. It mounts. It is scriptable. It runs inside your own security boundary, so your credentials never leave your infrastructure. It has been maintained for over a decade. For a large number of people, rclone is the honest answer and our product is a paid convenience they do not need. We will say that every time someone asks, because the alternative is talking someone into a subscription they do not need and that is a worse business than losing the sale.

If you need storage mounted as a filesystem, use rclone mount, Mountain Duck or ExpanDrive. We do not do it and we are not going to.

If you need Google Drive, Dropbox, OneDrive or SFTP, use rclone or MultCloud. CloudFuze too if the scale is enterprise. We deliberately do not cover the consumer clouds and that is a product decision, not a gap we are about to close.

If your credentials must never leave hardware you control, use rclone, or use our IAM-role connect if the target is AWS and nothing else. For a mixed-provider setup where the keys cannot leave your network, we are not the answer.

If everything lives in one cloud and always will, that provider's own console is free, always current with the newest features, and authoritative. It is better than us for that job and it costs nothing.

If your workflow is entirely code and always will be, use a CLI. A console does not compose. We are the wrong shape for a pipeline.

And if you are a single person managing a handful of buckets who wants no subscription at all: Cyberduck, Mountain Duck or S3 Browser. One-time licence or free, files stay on your machine, and they mount. Better than us for that.

Who should use us: teams managing buckets across more than one provider, where the repetitive work is configuration and verification rather than data movement, and where a console beats a script because the person doing the work is not the person who wrote the script and may not be an engineer at all. If that is you, the flat subscription with unmetered migration is a straightforward deal. If it is not, one of the tools above is a better fit and we would rather you used it than bought us and been disappointed.

The checklist we would hand an auditor, and the parts you cannot outsource

Here is the list, in the order we would do it, with a note on which parts a tool can help with and which parts are yours alone.

1. Verify the object lock configuration on every bucket that needs it. Not the bucket setting, the per-object state. Pick a sample, confirm the retention mode, confirm the period, confirm the provider actually rejects a delete. Test it. This is the step people skip because the console says it is on. Tooling helps you find the buckets. The test is yours.
2. Confirm the mode is the mode you meant. Governance mode has an escape hatch. If your policy document says immutable and the bucket says governance, fix one of them. This is a conversation with whoever wrote the policy, not a technical fix.
3. Check that versioning is enabled and has not been suspended. Object lock depends on it. A suspended versioning state on a locked bucket is the kind of thing that shows up as a finding and looks like a misconfiguration even when it was deliberate. Tooling shows you the state. The decision about whether it was correct is yours.
4. Keep the provider's SOC 2 report and residency documentation, with the scope statement, somewhere you can find it. Not the link to the trust centre, the actual PDF, dated, with the scope pages highlighted. Auditors ask for the report, not the URL, and trust centres change. This is entirely on you.
5. Document who can change retention. Names, roles, the identity provider group, the approval process. If the answer is "the admin account, and everyone knows the password," that is the finding. Tooling does not answer this question. Your identity provider does, and the answer needs to be written down.
6. Test a restore. Pick an object, find it in the archive, retrieve it, and time how long it takes. An archive nobody has read from is an archive nobody knows is broken. This is the step that most often reveals a lifecycle rule that transitioned data to a tier you cannot retrieve from without a support ticket. Tooling helps you find the object. The restore test is yours.
7. Reconcile the buckets that exist against the buckets that should be locked. New buckets get created. People forget. The list of "should be locked" lives in a policy document and the list of "is locked" lives in the provider. Finding the difference is the audit. Tooling does the enumeration. You do the reconciliation, because only you know which buckets are supposed to be in scope.
8. Check public access on everything, not just the buckets you are worried about. The finding is never on the bucket you were worried about. Tooling gives you the list. You make the call.
9. Write down the retention period and the reason for it. Not "seven years because that is what we always do," the actual regulatory or contractual basis. When the auditor asks why seven and not ten, the answer needs to exist and it needs to be someone's job to have written it.
10. Accept that the certification is the provider's, not the tool's. The SOC 2 report has the provider's name on it. The FedRAMP authorisation is in the provider's boundary. The residency commitment is in the provider's contract. No console, ours included, changes any of that, and any vendor telling you otherwise is telling you something that will not survive contact with an assessor.

The parts you cannot outsource are the parts that decide whether you pass. The provider certifies. Your lawyer interprets which regime applies and what it requires. Your auditor decides whether the evidence is sufficient. Your team writes down who can change retention and why the period is what it is. A control plane, ours or anyone's, configures the buckets and shows you the current state, and that is genuinely useful when you have fifty buckets across four providers and no single view of any of it.

But useful is not the same as sufficient, and the difference between those two words is the entire subject of this post. Buy the provider on the paper. Configure the buckets correctly. Document the decisions. Test the restores. And when a vendor tells you their tool makes you compliant, ask them which certification they hold, and watch what happens next.