Provider notes

Last updated: November 9, 2026

Every provider speaks S3, but not all of it, and not always the same way. We run BucketWorx's full test suite against each provider we name, and this page lists what we found and what BucketWorx does about it, so nothing surprises you.

Why each provider has its own preset

Any S3 client can connect to these providers with an address and a key. What it can't see is where each one quietly differs from Amazon S3: a request it ignores but answers as if it hadn't, a setting it accepts and doesn't keep, a file name it can't store. Those differences only show up when you test for them, and they're the kind that lose data without an error. So the main providers we've tested each have their own choice in BucketWorx's provider list, built from what the tests found. It fills in the right address and settings, hides what that provider can't do instead of letting it fail, and takes extra care where the provider doesn't. Pick the provider's own choice when there is one. For everything else, "Other S3-compatible" assumes the least (see the end of this page).

The largest file each provider takes

From each provider's documentation, read November 7, 2026. From beta 4, BucketWorx refuses a file that's too big before anything uploads, and says which limit it hit. Downloads have no limit.

One term comes up a lot below. When BucketWorx replaces, copies over or deletes a file, it normally asks the server to do it only if the file is still the one you chose, so a change someone else made in the meantime isn't lost. Some servers ignore that request. There, BucketWorx looks at the file itself just before it writes, and stops if it changed. The only gap left is a change made by someone else in the same instant.

Amazon S3

The reference: everything in BucketWorx works here, including storage classes, archive restores and Object Lock.

Cloudflare R2

• No permissions on single files (ACLs), and no version history, so neither is offered.
• No website redirects on files, so that field is hidden.
• It ignores "only if still the one you chose" on copies and deletes, so BucketWorx looks first there. It keeps it on uploads.
• Lifecycle rules: moving files only to Infrequent Access, up to 1,000 rules, and no rules for old versions, delete markers or tags. BucketWorx refuses those before saving. A new R2 bucket already has one rule, which cleans up incomplete uploads across the whole bucket; you'll see it in the editor, and you can keep it.

Tested again November 9, 2026, with the full test suite, including the beta 5 features.

Backblaze B2

• Every bucket keeps old versions, and that can't be paused. Moves and renames rely on that: if a lifecycle rule removes old versions, BucketWorx stops and says so.
• It refuses "only if still the one you chose" altogether, so BucketWorx always looks first. Because B2 keeps the old version, nothing is lost even in the rare clash.
• No tags, no website redirects, and no tabs or line breaks in file names.
• The free tier has daily limits on downloads and requests. When you hit one, BucketWorx says so instead of reporting a permissions problem.
• No Public Access Block, and bucket policies only for Enterprise customers. From beta 4, the security scan reads the bucket's own settings and says "Public" or "Not public" instead of "Couldn't check". A public bucket is shown as "Everyone can download its files", since B2 doesn't let strangers list one.
• Lifecycle rules through the S3 API can only filter by folder, can't move files to another class or use a date, and can't be disabled; BucketWorx refuses those before saving, as B2 would.

Tested November 1, 2026. The beta 5 features were tested on November 9 until B2's free daily request limit stopped the run; the rest runs once it resets.

DigitalOcean Spaces

• It ignores "only if still the one you chose" on copies and deletes, so BucketWorx looks first. Without versioning on, a change someone makes in that same instant can be overwritten for good.
• Tags are lost when a file is copied or uploaded in parts (large files), so BucketWorx sets them again right after.
• Lifecycle rules: deleting by age and cleaning up incomplete uploads, without tag filters. In our test Spaces turned a rule limited by file size into one for the whole bucket, so BucketWorx refuses size filters there.

Tested again November 9, 2026, with the full test suite, including the beta 5 features.

MinIO

• No permissions on single files (ACLs).
• It accepts a website redirect and keeps nothing, so that field is hidden.
• It ignores "only if still the one you chose" on copies and deletes, so BucketWorx looks first.
• A folder's list of unfinished uploads comes back empty, so BucketWorx finds them from the whole bucket's list. MinIO keeps that list in memory, so after the server restarts it only shows uploads started since.
• It refuses file names with an empty part (a//b) or a . or .. part.

Tested again November 9, 2026, on a current MinIO server, with the full test suite including the beta 5 features.

Wasabi

• In a bucket where versioning was turned on and then paused, Wasabi says it deleted files that were written while versioning was on, and keeps them. BucketWorx checks after each delete and move there, and tells you which files are still there. To delete them, turn versioning back on and delete again, or delete their versions.
• It accepts a website redirect and keeps nothing, so that field is hidden.
• Object Lock works as on Amazon S3 (tested in governance mode). From beta 5, editing a hold or retention works too, including shortening governance retention with the bypass permission.
• No Public Access Block or policy status. From beta 4, the security scan reads the bucket policy itself and says "Public" or "Not public" instead of "Couldn't check". A policy it can't judge still says "Couldn't check", never a wrong "Not public".

Tested again November 9, 2026, with the full test suite including the beta 5 features, on a trial account. Trial accounts can't make files public, so that part wasn't tested.

Neon

• Neon stores a bucket's versioning setting but keeps no old versions. BucketWorx treats every Neon bucket as having versioning off, so it never tells you a deleted file can be brought back.
• It ignores "only if still the one you chose" on copies and deletes, so BucketWorx looks first. A change someone makes in that same instant can be overwritten for good.
• Tags are lost on large files uploaded or copied in parts, so BucketWorx sets them again right after. Editing the headers of a tagged file over 5 GB is refused, as the tags couldn't be kept safely.
• No permissions on single files, website redirects or storage classes, and no tabs or line breaks in file names.
• Each Neon database branch has its own storage address. Use the one from the branch you want.
• Neon stores lifecycle rules but never runs them, so BucketWorx shows them read-only.

Tested again November 9, 2026, with the full test suite, including the beta 5 features.

Supabase Storage

Supabase gets its own provider choice in beta 4. Enter your project ref and BucketWorx fills in the S3 address (https://<project-ref>.storage.supabase.co/storage/v1/s3). The region defaults to us-east-1; your project's own region is under Storage > S3 in the Supabase dashboard. In beta 3 and earlier, use "Other S3-compatible" with that address and path-style addresses on: browsing, uploads, downloads, copies, renames and deletes work, but the checks below fail with an error instead of being hidden.

• No permissions on single files, versions, tags, lifecycle rules or website redirects, so BucketWorx doesn't offer them. Editing headers is refused, with the reason.
• It ignores "only if still the one you chose" on every write, so BucketWorx looks first. With no versions to fall back on, a change someone makes in that same instant can be overwritten for good.
• File names can only use English letters, digits, spaces and _ / ! . * ' ( ) & $ = @ ; : + , ? -, with no . or .. folders and no empty folder names (a//b). So a file with an accented name can't be uploaded. BucketWorx says which character is the problem before sending anything.
• Files over 50 MB are refused by Supabase itself, unless you raise the project's file size limit.
• A file uploaded without a Cache-Control header gets no-cache from Supabase. An upload rule (from beta 5) that sets Cache-Control is kept as you set it.

Tested again November 9, 2026, with the full test suite, including the beta 5 features.

Storj

Storj gets its own provider choice in beta 4, which fills in Storj's S3 gateway (https://gateway.storjshare.io). Create the keys in the Storj console under Access Keys > New Access Key, with the type S3 Credentials. In beta 3 and earlier, deleting a folder or several files at once fails on Storj, so wait for beta 4.

• Storj's version list never marks which version is current, so BucketWorx treats the newest one as current. Undelete and restoring an old version work.
• It ignores "only if still the one you chose" on writes, deletes and copies, so BucketWorx looks first. A change someone makes in that same instant can be overwritten.
• No permissions on single files, CORS rules, bucket policies, lifecycle rules, website settings or storage classes, as Storj documents, so BucketWorx doesn't offer them.
• Storj deletes a bucket that still holds old versions. From beta 4 BucketWorx refuses to, on every provider, until the old versions are gone.
• Large files go up in parts of at least 64 MB, as Storj recommends. One copy inside Storj can be up to about 600 GB.
• Editing headers in a bucket with versioning makes a new version, as on Amazon S3.
• Object Lock works: locked files can't be overwritten or deleted, and editing headers keeps the lock. Storj doesn't allow the governance bypass.
• Storj refuses a file name with a . or .. folder in it (such as reports/../a.txt), and writes nothing. BucketWorx passes its message on.

Tested again November 9, 2026, with the full test suite, including the beta 5 features.

Leaseweb (NetApp StorageGRID)

Connect it with "Other S3-compatible" and the endpoint Leaseweb gives you.

• It ignores "only if still the one you chose" on every write, so BucketWorx looks first. A change someone makes in that same instant can be overwritten.
• A key that isn't allowed to set tags can't copy a file that has tags at all: StorageGRID refuses the copy, and refuses it again without the tags. BucketWorx says which permission the key needs.
• It refuses lifecycle rules that clean up incomplete uploads. The lifecycle rule builder (from beta 5) can't tell which server is behind "Other S3-compatible", so it offers that rule; saving it fails with StorageGRID's message, and nothing is changed.

Tested again November 9, 2026, with the full test suite, including the beta 5 features.

Self-hosted servers

We ran a shorter set of tests on these open-source servers, each in Docker on November 5, 2026: browsing, uploads, downloads, overwrites, versions, restore, delete, headers, tags and listing. Connect them with "Other S3-compatible", your server's address and path-style addresses on.

Ceph (RADOS Gateway) 19.2

• Close to Amazon S3: versions, tags, permissions, bucket policies, Object Lock and website redirects all work. It ignores "only if still the one you chose" on deletes, so BucketWorx looks first there.
• It doesn't recognise S3's usual form of a file's fingerprint on an upload, so replacing an existing file was refused (safely: nothing was overwritten). BucketWorx now retries a plain upload once in the form Ceph takes, when the file hasn't changed. Copies, restores, header edits and large uploads over an existing file are still refused there, with the reason.
• It drops tags when headers are edited and on large uploads. BucketWorx refuses to edit the headers of a tagged file (remove the tags first), and a large upload that loses its tags says so, naming them.
• DigitalOcean Spaces runs on Ceph and shares some of this; see its section above.

Garage

• No versions, tags, permissions or bucket policies, and it ignores every "only if still the one you chose", so BucketWorx looks first.
• Editing headers is refused, with the reason: Garage can't report a file's permissions or tags, so a rewrite could change them.

RustFS

• Holds to "only if still the one you chose" and keeps versions as Amazon S3 does.
• Its bucket policies don't refuse everything a policy denies, so don't rely on a deny rule there.

SeaweedFS

• Deleting a folder leaves an empty folder/ entry behind.
• Restoring an old version is refused by SeaweedFS (BucketWorx says so, and nothing is written).
• Website redirects on files aren't kept.

Other S3-compatible servers

For a server we haven't tested, BucketWorx assumes the least: it still asks for "only if still the one you chose", looks itself just before each write as well, and in a bucket with versioning it checks after each delete that the files are really gone. Most things will work. If something doesn't, tell us which server it is.