Deprecation of the MinIO gateway

MinIO is deprecating the gateway and will be completely removed in six months. This should not come as a surprise, we began informing the community in 2020 and have steadily removed unpopular gateways. In the last ten months, MinIO has only made bug fixes.


The community can continue to use older versions of MinIO past that date. We also encourage any volunteers to step up and maintain open source forks as standalone projects. All modifications and improvements must also be released under the GNU AGPL v3 license.

Existing commercial customers of MinIO will be supported for as long as necessary.

The reasoning as to why we are deprecating the gateway is relatively straightforward.

We introduced the gateway feature early on to help make the S3 API ubiquitous. From legacy POSIX-based SAN/NAS systems to modern cloud storage services, the different MinIO gateway modules brought S3 API compatibility where it did not exist previously. The primary objective was to provide sufficient time to port the applications over a modern cloud-native architecture. In the gateway mode, MinIO ran as a stateless proxy service, performing inline translation of the object storage functions from the S3 API to their corresponding equivalent backend functions. At any given time, the MinIO gateway service could be turned off and the only loss was S3 compatibility. The objects were always written to the backend in their native format, be it NFS or Azure Blob, or HDFS.

Implementing different gateways proved to be more challenging than the server mode because it was easier to implement the S3 capabilities in our native erasure-coded backend as compared to competitors' products. The gateway was and still is a great implementation. It worked as advertised, was lightweight and non-intrusive.

So why are we depreciating it?

The answer has two parts. First, the MinIO gateway achieved its primary purpose of driving the S3 API's ubiquity.  The goal has been achieved. S3 API is the de facto standard for storage and has made object storage the storage class of the cloud and of Kubernetes. As a result, the gateway merely perpetuates legacy technologies. Gateway users have had years to transition; it is time to let the legacy technologies go.

Second, the S3 API has evolved considerably since we started, and what began as inline translation morphed into something much more. Critical S3 capabilities like versioning, bucket replication, immutability/object locking, s3-select, encryption, and compression couldn’t be supported in the gateway mode without introducing a proprietary backend format. It would defeat the purpose of the gateway mode because the backend could no longer be read directly without the help of the gateway service. The backends would merely act as storage media for the gateway and you might as well run MinIO in server mode. Thus it became a compromise that MinIO no longer wanted to engage in. This meant it was time for us to let go.

The class of problems faced by our customers today is suited for the capabilities of the full MinIO Server implementation. In fact, among our commercial customers, the gateway-only usage is less than 2%. Accordingly, we are investing in taking the MinIO server to the next level and so we are deprecating the gateway functionality.

If you have any questions, feel free to head over to our Slack channel and engage the team. We are happy to answer any questions you might have. If the questions are of a commercial nature, shoot us an email at hello@min.io and we will be sure to respond.

Previous Post Next Post