Skip to content
BloberThe Safest, Easiest Way to Move Cloud Files
Articles
On this page

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

· 5 min read · Updated

Add as preferred source
Copy page
View as MarkdownOpen in ChatGPTOpen in Claude
Self-hosted and open-source S3-compatible storage servers

You can get an S3 endpoint without a cloud account. Open-source servers give you S3-compatible storage on your own hardware, in your own data center, or on a laptop for testing. They expose the same core S3 object-storage API as AWS, so a tool that works with a cloud bucket can point at http://localhost:9000 just as easily.

Self-hosted servers are one category in our complete list of S3-compatible storage providers. Blober connects to all of them through the generic S3-Compatible provider. Self-hosted servers almost always want path-style addressing (bucket in the path), so if browsing or uploads fail, enter the address in Path-style endpoint URL. The endpoint setup notes explain how path-style and virtual-hosted addressing differ. Endpoint and compatibility notes come from each project's own documentation, cross-checked against rclone's S3 page[1].

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. It is the reference target for "does this tool support custom S3 endpoints," and a common front end for other storage backends[2]. For a quick local test, the default keys are often minioadmin / minioadmin.

  • Endpoint format: http://<host>:9000 (for example http://localhost:9000).
  • Addressing: path-style.

Ceph (RADOS Gateway / RGW)

Ceph is an open-source distributed storage system, and its RADOS Gateway (RGW) exposes an S3-compatible object interface on top of a Ceph cluster. 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].

  • Endpoint format: https://<your-rgw-host> (your own gateway address).
  • Addressing: path-style is the safe default.

SeaweedFS

SeaweedFS is a fast distributed storage system for blobs and files, with an S3-compatible gateway. Lightweight and quick to stand up, it can also cache a remote S3 store with asynchronous write-back, which makes it good for edge and on-prem caching in front of a remote bucket[4].

  • Endpoint format: http://<host>:8333 (for example http://localhost:8333).
  • Addressing: path-style.

Garage

Garage, from Deuxfleurs, is a lightweight, self-hosted S3-compatible object store designed for geo-distributed deployments on modest hardware. It is built for resilience across home-server-grade nodes and is a popular choice for self-hosters and small co-ops[5].

  • Endpoint format: http://<your-garage-host>:3900 (your own configured address).
  • Addressing: path-style.

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. It is part of the wider Zenko project, which targets multi-cloud data management with an S3 front end[6].

  • Endpoint format: http://<host>:8000 (your own configured address).
  • Addressing: path-style.

Versity Gateway (VersityGW)

Versity Gateway is an open-source S3 gateway with pluggable backends, so you can put an S3 API in front of a POSIX file system or other stores. That makes it useful for exposing existing file storage, including tape-backed archives, over S3[7].

  • Endpoint format: http://<your-gateway-host>:7070 (your own configured address).
  • Addressing: path-style.

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. It is a common way to give non-S3 backends an S3 face, and one of the standard tools when you specifically need S3 in front of Azure[8].

  • Endpoint format: http://<your-proxy-host>:80 (your own configured address).
  • Addressing: path-style.

Apache Ozone

Apache Ozone is a distributed object store for big-data and Kubernetes workloads, with an S3 Gateway component. It is designed to scale to billions of objects alongside Hadoop and Spark[9].

  • Endpoint format: the S3 Gateway address you deploy (commonly port 9878).
  • Addressing: path-style.

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 as well as its native Swift API. Many regional and academic clouds run Swift, and if yours has s3api turned on, you can connect over S3[10].

  • Endpoint format: your Swift proxy address with s3api enabled (your own deployment).
  • Addressing: path-style.

OpenIO

OpenIO is an open-source object storage platform (now part of OVHcloud) with an S3-compatible gateway, designed for grid-style scaling on heterogeneous hardware[11].

  • Endpoint format: your OpenIO S3 gateway address (your own deployment).
  • Addressing: path-style.

LeoFS

LeoFS is an open-source distributed object store with an S3-compatible interface. Take the gateway endpoint and credentials from your LeoFS configuration[12].

  • Endpoint format: your LeoFS gateway address (your own deployment).
  • Addressing: path-style.

Riak CS

Riak CS (Cloud Storage) layers S3-compatible object storage on top of a Riak key-value cluster and suits multi-tenant, highly available deployments[13].

  • Endpoint format: your Riak CS proxy address (your own deployment).
  • Addressing: path-style.

rclone serve S3

With rclone serve s3, rclone serves any of its remotes over the S3 protocol, turning anything it supports into a temporary S3 endpoint. That is handy for bridging an odd backend to S3 tools for a one-off transfer[14].

  • Endpoint format: http://<host>:8080 (your own configured address).
  • Addressing: path-style.

Exaba

Exaba is an on-premises, S3-compatible storage server for service providers and enterprises, with a free container edition. Set up the container through the admin interface first, then use the S3 service port[15].

  • Endpoint format: http://<host>:9000 (your own configured address; the admin interface runs on a separate port).
  • Addressing: path-style.

Gateways that put S3 in front of another backend

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 a non-S3 cloud like Azure Blob. A gateway is the usual answer when a non-S3 store has to look like S3. If you only want to move data between an S3 store and a non-S3 store, there is no gateway to run: Blober connects to S3, Azure Blob, Dropbox, Google Drive, and more, and copies files between them through your computer.

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, and 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, and self-hosted servers want path-style. In Blober, enter the address, for example http://localhost:9000, in Path-style endpoint URL.

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, then browse to confirm the connection.

Can I put an S3 API in front of Azure or Google Drive? A gateway can do it. s3proxy supports Azure Blob and Google Cloud Storage as backends, and rclone serve s3 works with any backend rclone supports. If you only need to move files between those services and an S3 store, skip the gateway: Blober connects to Azure Blob and Google Drive directly.