S3 and compatible

One API, an entire industry: Amazon S3 and every store that speaks its protocol — R2, Wasabi, B2, Scaleway, MinIO and more.

Live-tested Verified against a live server

What Mountit does with it

Mount
Read and write, in Finder
Offline cache
Metadata cache, read-ahead and write-back — the same volume stack as every other service
Encryption layer
Available on this connection: client-side, rclone-compatible crypt over the data before it leaves your Mac
Editions
Both. Either edition mounts it through File Provider, so it appears in Finder — and, on Standard, in the Files app on iPad and Vision Pro

Limits

What S3 and compatible cannot do, read from the app's own service_traits() — the same answer its connection picker shows before you connect, not a judgement typed onto this page.

Prefixes, not directories
There are no real directories in this store — a “folder” is a shared prefix on the object keys. Making one writes a zero-byte marker object so the empty folder you just created is still there when you look again; a folder that only ever existed because files were under it has no marker, and goes when its last file goes. Anything that depends on an empty directory persisting has to know that.
A move is a copy, then a delete
This service has no server-side rename, so renaming or moving a file copies the bytes to the new name and only then deletes the old one — that order, so an interrupted move leaves your file where it was rather than nowhere. What it costs is a full transfer of the bytes, which is worth knowing before you drag a large folder. On this store a folder move is refused as a single operation and done file by file, because moving the one key that names the folder would leave everything under it orphaned.

The engineering ledger lists S3 and compatible among the services run against a real server. Which of those two things it says is read out of docs/BACKEND-COVERAGE.md in the app repository when this site is built, not typed here — so the level above moves when the ledger does, and the build stops rather than leave the paragraph above it saying something else.

The conformance record

Blocked by a finding. A lane ran and 5 findings stand between this service and a clean record. They are the return on running the corpus, and they are published rather than filtered. Every service’s standing, side by side.

Being mounted once is the floor. The conformance harness runs the same corpus of assertions at every backend — must for the contract the volume layer relies on, should for a well-behaved server, and probe for observations that become capability data — and commits the verdicts as a file. These numbers are read out of that file.

A failure here is a finding about this protocol, not a broken test. They are published rather than filtered because a page that showed only the green ones would be worth nothing.

LaneRunMustShouldProbe
minio-s32026-09-0161 passed, 3 failed17 passed, 7 failed, 4 skipped28 passed, 2 skipped
moto-s32026-09-0161 passed, 2 failed17 passed, 7 failed, 4 skipped28 passed, 2 skipped
  • minio-s3 — 122 assertions. 3 assertions tagged must failed. 1 capability the backend claimed was contradicted by what the server actually did. On the harness's own rule — no must failure and no capability disproved — this lane does not by itself promote the service.
  • moto-s3 — 121 assertions. 2 assertions tagged must failed. On the harness's own rule — no must failure and no capability disproved — this lane does not by itself promote the service.

Preset endpoints

The picker pre-fills the endpoint, region and addressing style for these providers — the well-established endpoints, chosen because anything whose URL shape varies per account is worse than no preset at all: it looks authoritative and does not work.

ProviderEndpointYou pasteNotes
Amazon S3https://s3.{region}.amazonaws.comRegion docsfor Amazon S3
Cloudflare R2https://{account_id}.r2.cloudflarestorage.comAccount ID R2 has one region, `auto`; the account id is in the R2 dashboard URL. docsfor Cloudflare R2
Wasabihttps://s3.{region}.wasabisys.comRegion docsfor Wasabi
Backblaze B2 (S3 endpoint)https://s3.{region}.backblazeb2.comRegion Mountit also speaks B2's native API, which skips this gateway. docsfor Backblaze B2 (S3 endpoint)
DigitalOcean Spaceshttps://{region}.digitaloceanspaces.comRegion docsfor DigitalOcean Spaces
Scaleway Object Storagehttps://s3.{region}.scw.cloudRegion docsfor Scaleway Object Storage
Akamai / Linode Object Storagehttps://{region}.linodeobjects.comRegion docsfor Akamai / Linode Object Storage
OVHcloud Object Storagehttps://s3.{region}.io.cloud.ovh.netRegion docsfor OVHcloud Object Storage
IBM Cloud Object Storagehttps://s3.{region}.cloud-object-storage.appdomain.cloudRegion Needs HMAC credentials, not the default IAM ones. docsfor IBM Cloud Object Storage
Storjhttps://gateway.storjshare.ioCredentials only The hosted S3 gateway. Storj's native protocol is not this. docsfor Storj
Filebasehttps://s3.filebase.comCredentials only docsfor Filebase
MinIO (self-hosted)https://{host}Serverpath-style Path-style addressing, which is what a self-hosted MinIO serves. docsfor MinIO (self-hosted)
Garage (self-hosted)https://{host}Serverpath-style docsfor Garage (self-hosted)
Ceph RADOS Gateway (self-hosted)https://{host}Serverpath-style docsfor Ceph RADOS Gateway (self-hosted)
Exoscale Object Storagehttps://sos.{zone}.exo.ioZone docsfor Exoscale Object Storage
UpCloud Object Storagehttps://{instance}.upcloudobjects.comInstance The hostname is a per-instance id shown in the UpCloud panel, not a region name. docsfor UpCloud Object Storage
Vultr Object Storagehttps://{region}.vultrobjects.comRegion docsfor Vultr Object Storage
Contabo Object Storagehttps://{region}.contabostorage.comRegionpath-style Path-style addressing, which Contabo requires. docsfor Contabo Object Storage
Infomaniak Object Storagehttps://s3.{cluster}.infomaniak.cloudClusterpath-style Public Cloud only; Swiss Backup has its own per-device endpoints. docsfor Infomaniak Object Storage
IONOS Object Storagehttps://s3.{region}.ionoscloud.comRegion docsfor IONOS Object Storage
Bunny Storagehttps://{region}-s3.storage.bunnycdn.comRegion The access key is the storage zone's name; S3 works only on zones created with S3 compatibility enabled. docsfor Bunny Storage
Hetzner Object Storagehttps://{location}.your-objectstorage.comLocation docsfor Hetzner Object Storage
DreamHost Objectshttps://s3.us-east-005.dream.ioCredentials only SigV4 only. docsfor DreamHost Objects

Presets tagged path-style in the table above address the bucket from the path rather than the host — the self-hosted ones because a wildcard TLS certificate per bucket is not something a self-hoster sets up, the hosted ones because that is the addressing they document.

This table is not written on this page. It is generated from the preset list compiled into the app, and the build fails if the two disagree — which is the only way a page of endpoints stays worth trusting.

S3 and compatible questions

Can Mountit mount S3 and compatible?

Yes — S3 and compatible is one of the 38 services selectable in the app. It mounts read-write, with the same cache, read-ahead and write-back as every other service.

What we will not do is claim it works before it does: this page carries the ledger’s evidence level for S3 and compatible, and it changes the day the evidence does.

Which providers does the S3 and compatible preset list cover?

Amazon S3, Cloudflare R2, Wasabi, Backblaze B2 (S3 endpoint), DigitalOcean Spaces, Scaleway Object Storage, Akamai / Linode Object Storage, OVHcloud Object Storage, IBM Cloud Object Storage, Storj, Filebase, MinIO (self-hosted), Garage (self-hosted), Ceph RADOS Gateway (self-hosted), Exoscale Object Storage, UpCloud Object Storage, Vultr Object Storage, Contabo Object Storage, Infomaniak Object Storage, IONOS Object Storage, Bunny Storage, Hetzner Object Storage and DreamHost Objects. Anything else that speaks S3 and compatible works too — you paste the endpoint yourself, and the preset only saves you finding it.

That list is not typed on this page. It is generated from the 47 presets compiled into the app, and the build fails if the two ever disagree — which is the only reason it is safe to publish endpoints at all.

Which edition do I need?

Either — this service is in both editions. The difference is the surrounding app, not the protocol: Mountit Pro is the unsandboxed build with the block protocols; Standard is the Mac App Store build, and on iPad and Vision Pro every service appears in the Files app. Both mount this service through File Provider.

Is it really the same protocol?

That is the whole trick: these stores implement the S3 API deliberately, so one backend covers the family. What differs per provider is a hostname, a region convention and whether the bucket goes in the host or the path — exactly the three things a preset fills in.