In the field of GIS development, on-premises deployment is an extremely common requirement, and MinIO is almost synonymous with private object storage. Whether storing hundreds of terabytes of remote sensing imagery or billions of loose map tiles, MinIO has consistently been the "cornerstone" of WebGIS architecture due to its simple deployment, excellent S3 compatibility, and the high performance of the Go language. However, just last week, the official MinIO GitHub repository announced an update to the project's status, moving it to maintenance mode and ceasing to accept new feature requests. The main changes are as follows:

  • The codebase is now in a maintenance-only state.
  • No new features, enhancements, or pull requests will be accepted.
  • Critical security fixes may be evaluated on a case-by-case basis.
  • Existing issues and pull requests will not be actively reviewed.
  • Community support will continue on a best-effort basis via Slack.
  • For enterprise support and actively maintained versions, please refer to MinIO AIStor.

To summarize the key point: if you wish to use a continually updated version of MinIO in the future, you must pay for the commercial version, MinIO AIStor. According to my research, the price is quite steep, requiring a subscription service. The annual fee is $96,000 to manage 400TB of data (a price point that is essentially unfeasible within the domestic GIS community in China).

Main Impacts

As MinIO adopts a stricter business model, it presents several challenges for GIS projects that primarily focus on domestic procurement and on-premises deployment. First, the cost of private deployment projects increases significantly, especially for scenarios involving terabytes of imagery data. Government agencies or enterprises will face pressure from licensing costs, compliance risks for existing systems, and budget re-evaluations. Secondly, risks associated with long-term upgrades and maintenance grow. Over a typical 5 to 10-year system lifecycle, the free version may receive fewer security patches, potentially affecting storage stability. The lack of official technical support also poses a threat to critical functions like tile caching and 3D tile services. Furthermore, if MinIO's S3 ecosystem compatibility changes, it could disrupt GIS platforms (like GeoServer, MapProxy) and front-end applications already adapted to the S3 API, leading to additional adaptation costs. Finally, DevOps and automated deployment pipelines that incorporate MinIO may become more fragile, impacting the stability of production workflows such as data transfer and model result management.

In reality, MinIO's current decision shouldn't come as a complete surprise. As early as 2019, MinIO changed its open-source license from Apache 2.0 (which allows free use, modification, and redistribution) to AGPLv3 (which requires service providers to open their source code), despite considerable opposition. The stated reason was that as the project's popularity grew, some large companies were using MinIO for commercial SaaS or cloud services without contributing back to the community, placing a significant resource burden on the maintainers. The license change was an attempt to protect the project's interests and encourage community contributions. However, this seems to have had little effect and may have contributed to the shift in focus towards the commercial version.

Alternative Solutions

There's no need to be overly concerned, however. The open-source world is a vast treasure trove; as one door closes, another opens. Several viable alternative solutions are currently available. Here are a few recommendations:

PS: I haven't had the time to test each of these personally, so please evaluate them yourself. Feel free to suggest other better solutions in the comments.

1. SeaweedFS

Official Address: https://github.com/seaweedfs/seaweedfs

If your primary focus is on map tiles and massive numbers of small files, SeaweedFS might be the best open-source alternative currently available. Designed based on Facebook's Haystack paper, it is specifically optimized for small file storage, merging multiple small files into larger "Volumes" for storage, which greatly reduces file system metadata pressure. For GIS development, its read/write speeds for hundreds of millions of tiles far surpass MinIO's. It also provides a directory structure similar to a file system, making it ideal for managing layer directories. It uses the Apache 2.0 license, which is business-friendly.

2. Ceph (RadosGW)

Official Website: https://github.com/ceph/ceph

If your project is a provincial or national-level fundamental geographic information platform with petabyte-scale data and a professional operations team, then Ceph might be suitable. It is a unified storage system (block, file, object) with extremely powerful features and a mature ecosystem, suitable for storing large remote sensing images. However, its operation and maintenance are highly complex, requiring not only GIS expertise but also dedicated storage engineers. Its support for small files (tiles) is not as strong as SeaweedFS's.

3. Garage

Official Website: https://github.com/deuxfleurs-org/garage

If your scenario involves edge GIS (e.g., UAV ground stations, field survey vehicles) with limited resources, consider Garage. Written in Rust, it is extremely lightweight, focusing on cross-region replication and consistency. It is suitable for deployment on industrial control computers with constrained hardware resources, used for temporary field data collection and synchronization.

4. Domestic Object Storage (Suitable for Government Projects)

Domestic private object storage solutions such as Alibaba Cloud OSS (which has several on-premises versions), Tencent Cloud COS, Huawei Cloud OBS, and UCloud UFile support on-premises deployment, have comprehensive documentation, and offer enterprise-grade SLAs. They are suitable for government projects with strict delivery requirements and sufficient budgets.

Conclusion

The current version of MinIO is still usable. Whether you need to migrate away from it in your existing projects requires a case-by-case evaluation. My rough suggestion is: if you are using an older, stable version of MinIO, you might not need to change immediately in the short term, but you should assess any potential compliance risks. If the project demands long-term stable operation (e.g., government, real estate, public utilities), it is advisable to seek alternatives sooner rather than later, as future security patches cannot be guaranteed.

In plain terms: if an old project works, keep it running. For new projects with less stringent requirements, it might still be okay to use MinIO. As for the future... we'll deal with that later.