While working on migrating our S3 object storage layout away from the deprecated Bitnami MinIO chart, I am seeing a critical upstream shift that impacts the long-term security and engineering footprint of the openmrs-contrib-cluster repository.
MinIO Community Edition is Permanently Archived
MinIO Inc. has officially archived both the community minio/minio and minio/operator repositories on GitHub. They have frozen the open-source community track to focus entirely on their commercial, closed-source product line (AIStor), which requires paid enterprise licensing.
Why this matters for OpenMRS:
-
Unpatchable Security Risks: Because the open-source track is frozen, it is actively accumulating high-severity vulnerabilities that will never receive official community patches. For instance, flaws like CVE-2025-62506 (IAM policy bypass/privilege escalation, CVSS 8.1) mean that pinning our backend to frozen community MinIO images introduces significant security debt.
-
Supply Chain Fragility: If legacy community image tags are eventually purged or restricted behind commercial registry walls, our automated cluster deployments will completely break.
Because the official MinIO Operator chart is no longer a viable path forward for a secure, production-ready stack, I have evaluated two active, open-source alternatives to serve as our unified S3 compatible storage engine, SeaweedFS and Rook/Ceph.
1. SeaweedFS
-
Pros: Highly active Apache-2.0 project with a robust, production-grade, built-in Amazon S3 API layer that actively receives security patches.
-
Local Development (Kind): Exceptional. It is highly memory-optimized and lightweight. It runs smoothly on standard developer laptops without triggering Out-Of-Memory (OOM) crashes in local Kind clusters.
-
AWS Production Pipeline: Seamless. It consumes standard AWS cloud block
StorageClasses(gp2/gp3) natively out-of-the-box via clean Helm chart values. No underlying infrastructure adjustments are needed. -
Code: GitHub
2. Rook / Ceph
-
Pros: CNCF Graduated, enterprise-grade, battle-tested unified storage (Object, Block, and File).
-
Local Development (Kind): Highly Problematic. Rook OSDs require raw, unformatted block devices. Forcing this inside containerized Docker nodes (Kind) requires an
allowLoopDevices: trueworkaround, which the official documentation flags as test-only with zero data redundancy. It is also incredibly resource-heavy for personal laptops. -
AWS Production Pipeline: Heavy Footprint. It requires modifying our core
terraform/codebase to provision and attach raw EBS disks directly to EKS node groups so Rook can claim them as OSDs. -
Code: GitHub
Looking for Community Input!
-
SeaweedFS is structurally the most elegant, lightweight, drop-in replacement for MinIO that preserves the local developer onboarding experience perfectly.
-
Rook/Ceph provides deeper enterprise block-level consistency but introduces a heavy local machine overhead and a broader Terraform refactor.
To help us guide this infrastructure transition smoothly, we would love to hear your thoughts:
-
For Developers/Contributors: How constrained are your local development machines? Would a heavier storage layer (like Rook) impact your ability to test OpenMRS locally?
-
For Implementers/DevOps: Do you have specific storage policies or preferences regarding SeaweedFS vs. Ceph backends in your target cloud environments?
I am leaning towards SeaweedFS because it offers a clean implementation. But what are your thoughts.