Self-Hosted and Open-Source S3-Compatible Storage (MinIO, Ceph, and More)

Self-hosted and open-source S3-compatible storage servers

Jun 28, 2026

You do not need a cloud account to get an S3 endpoint. A whole category of open-source software gives you S3-compatible storage on your own hardware, in your own data center, or on a laptop for testing. These servers expose the same core S3 object-storage API shape as AWS, so the same tools can point at http://localhost:9000 as easily as at a cloud. This page lists the self-hosted and open-source S3 servers and how to connect each one.

This is one category in our complete list of S3-compatible storage providers. All of these connect to Blober through the generic S3-Compatible connector. Self-hosted servers almost always want path-style addressing (bucket in the path), so use the path endpoint field in Blober if browsing or uploads fail. The endpoint and compatibility notes below come from each project's own documentation, cross-checked against current S3 client references^[1]. The endpoint setup notes explain the difference between path-style and virtual-hosted addressing.

MinIO

MinIO is the most widely deployed self-hosted S3 server: a single Go binary that exposes an S3-compatible API, used for everything from local testing to large production clusters.

Endpoint format: http://<host>:9000 (for example http://localhost:9000).
Addressing: path-style.
Notes: for a quick local test, the default keys are often minioadmin / minioadmin. MinIO is also the reference target for "does this tool support custom S3 endpoints," and it is a common front end for other storage backends^[2].

Ceph (RADOS Gateway / RGW)

Ceph is an open-source distributed storage system; its RADOS Gateway (RGW) exposes an S3-compatible object interface on top of a Ceph cluster.

Endpoint format: https://<your-rgw-host> (your own gateway address).
Addressing: path-style is the safe default.
Notes: Ceph powers many commercial object stores (DreamObjects and Contabo among them). Leave the region blank and set the endpoint. Older Ceph (pre-Jewel) may need v2 signatures^[3].

SeaweedFS

SeaweedFS is a fast distributed storage system for blobs and files, with an S3-compatible gateway. It can also cache a remote S3 store with asynchronous write-back.

Endpoint format: http://<host>:8333 (for example http://localhost:8333).
Addressing: path-style.
Notes: lightweight and quick to stand up; good for edge and on-prem caching in front of a remote bucket^[4].

Garage

Garage, from Deuxfleurs, is a lightweight, self-hosted S3-compatible object store designed for geo-distributed deployments on modest hardware.

Endpoint format: http://<your-garage-host>:3900 (your own configured address).
Addressing: path-style.
Notes: built for resilience across home-server-grade nodes; a popular choice for self-hosters and small co-ops^[5].

Zenko CloudServer

Zenko CloudServer (formerly Scality S3 Server) is an open-source Node.js S3 server that can store locally or proxy to cloud backends.

Endpoint format: http://<host>:8000 (your own configured address).
Addressing: path-style.
Notes: part of the wider Zenko project, which targets multi-cloud data management with an S3 front end^[6].

Versity Gateway (VersityGW)

Versity Gateway is an open-source S3 gateway with pluggable backends, letting you put an S3 API in front of a POSIX file system or other stores.

Endpoint format: http://<your-gateway-host>:7070 (your own configured address).
Addressing: path-style.
Notes: useful for exposing existing file storage (including tape-backed archives) over S3^[7].

s3proxy

s3proxy is an open-source proxy that presents an S3 API backed by a local file system or by other cloud stores, including Azure Blob and Google Cloud Storage.

Endpoint format: http://<your-proxy-host>:80 (your own configured address).
Addressing: path-style.
Notes: a common way to give non-S3 backends an S3 face. If you specifically need S3 in front of Azure, this is one of the standard tools^[8].

Apache Ozone

Apache Ozone is a distributed object store for big-data and Kubernetes workloads, with an S3 Gateway component.

Endpoint format: the S3 Gateway address you deploy (commonly port 9878).
Addressing: path-style.
Notes: designed to scale to billions of objects alongside Hadoop and Spark^[9].

OpenStack Swift (with the s3api middleware)

OpenStack Swift is the object storage component of OpenStack. With the s3api middleware enabled, it accepts S3 API calls in addition to its native Swift API.

Endpoint format: your Swift proxy address with s3api enabled (your own deployment).
Addressing: path-style.
Notes: many regional and academic clouds run Swift; if yours has s3api turned on, you can connect over S3^[10].

OpenIO

OpenIO is an open-source object storage platform (now part of OVHcloud) with an S3-compatible gateway.

Endpoint format: your OpenIO S3 gateway address (your own deployment).
Addressing: path-style.
Notes: designed for grid-style scaling on heterogeneous hardware^[11].

LeoFS

LeoFS is an open-source distributed object store with an S3-compatible interface.

Endpoint format: your LeoFS gateway address (your own deployment).
Addressing: path-style.
Notes: confirm the gateway endpoint and credentials from your LeoFS configuration^[12].

Riak CS

Riak CS (Cloud Storage) layers S3-compatible object storage on top of a Riak key-value cluster.

Endpoint format: your Riak CS proxy address (your own deployment).
Addressing: path-style.
Notes: suited to multi-tenant, highly available deployments^[13].

Rclone Serve S3

Rclone can serve any of its remotes over the S3 protocol with rclone serve s3, turning anything rclone supports into a temporary S3 endpoint.

Endpoint format: http://<host>:8080 (your own configured address).
Addressing: path-style.
Notes: handy for bridging an odd backend to S3 tools for a one-off transfer^[14].

Exaba

Exaba is an on-premises, S3-compatible storage server for service providers and enterprises, with a free container edition.

Endpoint format: http://<host>:9000 (your own configured address; the admin runs on a separate port).
Addressing: path-style.
Notes: set up the container through the admin interface first, then use the S3 service port^[15].

A Note on Gateways: S3 in Front of Something Else

Several tools here (s3proxy, Versity Gateway, Zenko, MinIO, and SeaweedFS) can act as gateways: they present an S3 API in front of a different backend, such as a local file system, tape, or even a non-S3 cloud like Azure Blob. If your goal is to make a non-S3 store look like S3, a gateway is the usual answer. If your goal is simply to move data between an S3 store and a non-S3 store, Blober already bridges S3, Azure Blob, Dropbox, Google Drive, and more directly, with no gateway to run.

Frequently Asked Questions

Which self-hosted S3 server should I start with? MinIO, for most people. It is a single binary, well documented, and the de facto standard for a local or on-prem S3 endpoint. Ceph RGW suits larger clusters; Garage and SeaweedFS suit lightweight or distributed setups.

Why do uploads fail against my self-hosted server? Almost always because the tool is using virtual-hosted (subdomain) addressing. Self-hosted servers want path-style. In Blober, use the path endpoint field, for example http://localhost:9000.

Can Blober connect to a server on my own machine? Yes. Point it at http://localhost:9000 (or your server's address) with path-style addressing and your keys, and browse to confirm.

Can I put an S3 API in front of Azure or Google Drive? You can with a gateway like s3proxy. But to just move data between those services and an S3 store, Blober connects to each one natively, so you do not need a gateway.

Get Blober

Connect Blober to MinIO, Ceph, SeaweedFS, Garage, or any self-hosted S3 server by URL, and move data between your own storage and the cloud directly, without filling your local disk.

Download Blober at blober.io