Alternativas autoalojadas a S3 en 2026 (RustFS, Garage, SeaweedFS, Ceph)
Elegir un S3 autoalojado tras MinIO
Amazon S3 se ha convertido en la API de facto para el almacenamiento de objetos. Tras el archivo del repositorio de código abierto MinIO en abril de 2026, quedan siete alternativas autogestionadas (self-hosted) creíbles.
Estas opciones no son intercambiables. Algunas son motores completos de almacenamiento de objetos que gestionan su propio esquema de datos; otras son pasarelas finas que exponen archivos que ya posees. Esa división — almacén nativo frente a pasarela basada en sistema de archivos — decide más sobre respaldos, recuperación y migraciones que cualquier lista de características.
Este artículo compara RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy y rclone. Cada sección cubre el modelo de almacenamiento, la cobertura de características de S3, el lugar que ocupa el proyecto y la limitación que suele determinar la elección. Una guía de decisión para implementaciones de servidor único y multi-servidor cierra el artículo.
Para una visión más amplia — almacenamiento de objetos, bases de datos, búsqueda y capas de datos nativas de IA —, consulta la Infraestructura de datos para sistemas de IA.
Comparación de almacenamiento S3 autogestionado
La pregunta más importante es si necesitas un almacén de objetos distribuido o una interfaz S3 delante de almacenamiento que ya existe.
| Software | Modelo de almacenamiento | Distribuido | Compatibilidad S3 | Archivos simples en disco | Complejidad | Mejor uso |
|---|---|---|---|---|---|---|
| RustFS | Almacén de objetos nativo | Sí | Alta, subconjunto probado | No | Baja a media | Reemplazo general de MinIO |
| Garage | Almacén de objetos nativo | Sí | Buena, API más estrecha | No | Baja a media | Clústeres distribuidos pequeños |
| SeaweedFS | Almacén distribuido de blobs y archivos | Sí | Alta | No | Media | Grandes cantidades de archivos y almacenamiento mixto |
| Ceph RGW | Pasarela de objetos Ceph | Sí | Alta | No | Alta | Infraestructura de almacenamiento a gran escala |
| VersityGW | Pasarela S3 sobre POSIX | Depende del backend | Buena | Sí | Baja | S3 sobre archivos normales |
| S3Proxy | Capa de traducción S3 | Depende del backend | Moderada | Sí con filesystem-nio2 | Media | Pasarela y traducción de protocolos |
| rclone serve s3 | Pasarela S3 | Depende del backend | Básica, experimental | Sí con backend local | Muy baja | Implementaciones simples y ligeras |
RustFS es el reemplazo directo más cercano para una implementación convencional de MinIO. Garage encaja en clústeres distribuidos pequeños. SeaweedFS y Ceph resuelven problemas de almacenamiento más amplios. VersityGW puede exponer un sistema de archivos POSIX existente a través de S3, manteniendo las cargas de los objetos como archivos ordinarios. Para una matriz de características por característica de Garage, MinIO y AWS S3, consulta Garage vs MinIO vs AWS S3.
Dos tipos diferentes de almacenamiento S3
Un almacén de objetos nativo posee su esquema de almacenamiento:
RustFS, Garage, Ceph RGW y SeaweedFS pertenecen a esta familia. Los archivos visibles en los discos subyacentes son detalles de implementación, y las aplicaciones no deben manipularlos directamente.
Una pasarela S3 basada en sistema de archivos tiene una relación diferente con el almacenamiento:
Con software como VersityGW, el sistema de archivos puede seguir siendo la representación autoritativa. Un objeto como:
s3://archive/documents/2026/report.pdf
puede corresponder directamente a:
/storage/archive/documents/2026/report.pdf
RustFS: El reemplazo de MinIO más cercano
RustFS es un sistema de almacenamiento de objetos distribuido escrito en Rust y publicado bajo la licencia Apache-2.0. Proporciona un modelo de operación orientado a S3 familiar para los usuarios de MinIO, lo que lo convierte en el primer proyecto a evaluar al reemplazar MinIO.
Su implementación actual de S3 cubre las operaciones que la mayoría de las aplicaciones esperan: buckets, objetos, cargas multipart, solicitudes condicionales, metadatos de objetos, etiquetas, versionado, gestión de ciclo de vida, bloqueo de objetos, URLs presigned, políticas de bucket, CORS, notificaciones, configuración de replicación y cifrado en el lado del servidor.
RustFS publica una matriz de compatibilidad S3 que es un subconjunto probado, no una afirmación de cobertura completa de Amazon S3. La instantánea verificada contra el commit 1e6f5f1e el 9 de agosto de 2026 enumera 455 pruebas estándar implementadas, 5 pruebas de comportamiento de ciclo de vida, 17 pruebas estándar no implementadas y 270 casos excluidos que no bloquean la puerta de compatibilidad. Las listas ejecutables bajo scripts/s3-tests son la fuente de verdad cuando esas cifras cambian.
Dónde encaja RustFS
RustFS es un candidato cuando una aplicación espera un verdadero almacén de objetos S3.
Los usos típicos incluyen almacenamiento de objetos para aplicaciones, repositorios de respaldo, almacenamiento de medios, artefactos de IA y pipelines de datos, infraestructura S3 interna, cargas de trabajo de Kubernetes y reemplazo de endpoints de MinIO existentes.
Funciona con SDK de AWS y clientes S3 comunes. Las aplicaciones generalmente necesitan un endpoint personalizado, credenciales, configuración de región cuando sea necesario y direccionamiento por estilo de ruta (path-style).
La limitación importante
RustFS posee la representación del almacenamiento. Los archivos bajo su directorio de datos son internos de RustFS.
Eso hace de RustFS la respuesta incorrecta cuando el requisito es que cada objeto S3 permanezca como un archivo ordinario que puedes inspeccionar, copiar, rsync o recuperar sin el software de almacenamiento de objetos. Ese requisito selecciona una pasarela basada en sistema de archivos.
Garage: S3 distribuido sin la complejidad a escala de Ceph
Garage es un almacén de objetos distribuido compatible con S3 para instalaciones autogestionadas pequeñas y medianas. Deuxfleurs lo desarrolla bajo la licencia AGPL v3 y lo ha estado operando en producción desde las primeras versiones del proyecto en 2020.
Garage está diseñado para ejecutarse en varios servidores comunes, incluidos servidores en diferentes ubicaciones físicas. La replicación es parte del diseño.
Garage es atractivo cuando tienes tres servidores pequeños en lugar de un rack de hardware de almacenamiento dedicado. Una ruta de configuración funcional, desde Docker hasta el layout del clúster, la replicación y TLS a través de un proxy inverso, está en el Inicio rápido de Garage.
Dónde encaja Garage
Garage tiene sentido para homelabs, pequeñas plataformas de alojamiento, servidores distribuidos geográficamente, respaldos replicados y clústeres donde Ceph sería excesivo.
Su alcance es más estrecho que el de AWS S3. La tabla de compatibilidad de Garage omite políticas de bucket, ACL y versionado de buckets. Elige Garage sobre RustFS cuando la replicación multi-nodo ligera sea el requisito principal. Elige RustFS cuando un comportamiento S3 más amplio y la compatibilidad de aplicaciones similar a MinIO importan más.
SeaweedFS: Más que un almacén de objetos
SeaweedFS comenzó almacenando enormes cantidades de archivos de manera eficiente. Ahora es una plataforma de almacenamiento distribuido que expone S3, un sistema de archivos FUSE, WebDAV, SFTP y HDFS. SeaweedFS 4.48 se lanzó el 28 de septiembre de 2026.
Los servidores de volumen empaquetan blobs en archivos de volumen solo de anexión (append-only). Los maestros rastrean volúmenes en lugar de archivos individuales. Un filer proporciona semántica de sistema de archivos jerárquico. El diseño se dirige a cargas de trabajo con millones o billones de objetos relativamente pequeños.
Soporte S3
SeaweedFS documenta versionado, bloqueo de objetos, reglas de ciclo de vida, etiquetado, CORS, sumas de verificación, URLs presigned, cargas multipart, políticas de bucket, IAM, STS y varios modos de cifrado en el lado del servidor.
El mismo clúster puede servir buckets de tablas S3 y un catálogo REST de Iceberg integrado, de modo que Spark, Trino, DuckDB y motores similares pueden usar tablas Iceberg sin un Hive Metastore o Glue separados. El ejemplo de S3 de un solo comando del proyecto escucha en el puerto 8333.
Dónde encaja SeaweedFS
Considera SeaweedFS para rastreadores web y archivos, repositorios de imágenes y documentos, billones de objetos pequeños, lagos de datos, cargas de trabajo mixtas de S3 y sistema de archivos, y almacenamiento que crece añadiendo servidores de volumen.
Hay más componentes que entender que en una instalación directa de RustFS. SeaweedFS puede proporcionar semántica de sistema de archivos a través de su filer y montaje FUSE, pero los objetos se almacenan dentro de su formato de volumen. No cumple el requisito de que cada objeto S3 permanezca como un archivo ordinario e independiente en el sistema de archivos del host.
Ceph RGW: La opción a escala de infraestructura
Ceph es más amplio que el almacenamiento S3. Un clúster puede proporcionar dispositivos de bloque a través de RBD, un sistema de archivos a través de CephFS y almacenamiento de objetos a través de RADOS Gateway (RGW). RGW presenta una API compatible con S3 respaldada por RADOS.
Ceph admite replicación, codificación de eliminación, dominios de fallo, múltiples pasarelas, implementaciones multi-sitio, políticas de acceso y herramientas de gestión de clúster.
Dónde encaja Ceph
Ceph tiene sentido cuando el almacenamiento de objetos es una parte de una plataforma de almacenamiento más amplia: volúmenes persistentes de Kubernetes, discos de máquinas virtuales, sistemas de archivos compartidos, grandes repositorios S3 y clústeres que necesitan dominios de fallo explícitos.
Para un solo servidor con varios terabytes, instalar Ceph solo para obtener un endpoint S3 es difícil de justificar. Si ya operas Ceph, RGW es la elección S3 obvia. Si no lo haces, RustFS o Garage alcanza un almacenamiento de objetos útil con menos maquinaria.
VersityGW: S3 sobre archivos ordinarios
VersityGW es la opción a evaluar cuando el sistema de archivos en sí mismo importa. Es una pasarela S3 con licencia Apache-2.0 que puede exponer sistemas de archivos POSIX, ScoutFS, Azure Blob Storage, otros servicios S3 y backends personalizados.
Su backend POSIX mapea buckets y objetos S3 sobre directorios y archivos. Por ejemplo:
s3://website-assets/images/logo.png
se mapea a una ruta como:
/storage/website-assets/images/logo.png
La carga de logo.png permanece como un archivo normal.
Por qué los archivos simples son útiles
Puedes inspeccionar el almacenamiento con herramientas Unix ordinarias:
find /storage -type f
du -sh /storage/*
Puedes leer un objeto sin el servidor S3:
cat /storage/archive/2026/source.html
Las herramientas convencionales de respaldo de sistema de archivos aplican directamente: rsync, restic, borg, tar y zfs send. Si el software de la pasarela desaparece, las cargas siguen siendo archivos en un árbol de directorios.
Metadatos S3 en un backend POSIX
Los metadatos S3 no encajan en un archivo POSIX por sí mismos. VersityGW los almacena en atributos extendidos de forma predeterminada. Desde marzo de 2026, los metadatos del objeto son un único xattr user.metadata que contiene JSON, porque un xattr por clave llegó a los límites de longitud de clave del sistema de archivos. Un comando versitygw utils convert-xattr-metadata reescribe los atributos por clave anteriores. Las lecturas siguen recurriendo al layout antiguo cuando user.metadata está ausente.
Los sistemas de archivos sin xattrs pueden usar --sidecar (o VGW_META_SIDECAR) para mantener los metadatos en un árbol de directorios separado. El proyecto marca sidecar y --nometa como menos probados que los xattrs. --nometa deshabilita el almacenamiento de metadatos y está destinado al alojamiento de solo lectura de un conjunto de datos que ya existe; las políticas de bucket y ACL son metadatos, por lo que no están disponibles en ese modo.
Las versiones de objetos pueden vivir en un directorio separado. El ejemplo POSIX del proyecto pasa --versioning-dir para versiones anteriores, mientras que la carga actual permanece en su ruta natural.
Cambiar un archivo detrás de la pasarela puede dejar los metadatos S3, incluidos los ETags, inconsistentes con los nuevos bytes. Un modelo operativo viable es:
Acceso de la aplicación:
Leer a través de S3
Escribir a través de S3
Acceso del administrador:
Leer el sistema de archivos directamente
Inspeccionar el sistema de archivos directamente
Hacer respaldo del sistema de archivos directamente
Evitar modificar objetos detrás de la pasarela
VersityGW 1.8.0, ya la versión a la que apuntaba una liberación de driver COSI de septiembre de 2026, añade un servicio IAM independiente (versitygw iam), STS AssumeRoleWithWebIdentity y condiciones de política IAM.
S3Proxy: Una capa de traducción general
S3Proxy implementa la API S3 y traduce las solicitudes a varios backends: archivos locales, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP y otros servicios S3. Requiere Java 17 o superior.
El proveedor en disco recomendado es filesystem-nio2. El proveedor filesystem anterior está deprecado. Las claves de objeto se convierten en rutas del sistema de archivos, y los metadatos usan atributos extendidos de usuario, por lo que las cargas permanecen como archivos ordinarios.
El backend de sistema de archivos se niega al versionado de objetos y al cifrado en el lado del servidor. El versionado permanece sin soporte (supportsVersioning() es falso, y esas solicitudes permanecen como HTTP 501) porque un layout de versionado escrito en un disco real se convertiría en un formato que el proyecto tendría que mantener. El cifrado en el lado del servidor se niega por la misma clase de razón: informar AES256 sobre un archivo en texto plano que alguien puede leer sería una afirmación falsa. El backend en memoria transient-nio2 implementa ambos, y los datos mueren con el proceso. La lectura del proyecto (README) también lista políticas de bucket, etiquetado de objetos y ACL, otras que private y public-read, como no soportadas.
S3Proxy es la herramienta cuando necesitas esa traducción entre backends. Para una pasarela S3-a-POSIX directa, VersityGW es la superficie más pequeña.
rclone serve s3: Ligero pero experimental
rclone serve s3 expone un backend de rclone a través de una API compatible con S3. La documentación sigue etiquetando el comando como experimental.
Para un sistema de archivos local:
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
Sin --addr, el servidor se une a 127.0.0.1:8080. --auth-key habilita Signature Version 4. Las cargas multipart se escriben en orden de número de parte a un objeto temporal y se renombran en su lugar al completar, por lo que una carga fallida no reemplaza un objeto existente.
Los objetos escritos a través de un backend local se convierten en archivos bajo esa ruta. El mismo comando puede estar delante de otros remotos de rclone. Es una elección razonable para herramientas internas, un laboratorio o un salto temporal de migración. Es una capa S3 permanente débil para muchas aplicaciones de producción no relacionadas.
¿Qué pasa con MinIO?
El repositorio de GitHub de MinIO fue archivado el 13 de febrero de 2026, desarchivado brevemente y archivado nuevamente el 25 de abril de 2026. Es de solo lectura. El aviso del repositorio dirige a los operadores a AIStor, la distribución comercial de MinIO, y establece que la edición comunitaria es solo código fuente.
Una implementación existente de MinIO puede seguir funcionando, particularmente cuando está aislada y su comportamiento ya se entiende. La línea de tiempo completa, el riesgo operativo y un plan de migración por fases están en MinIO CE en 2026.
Para el comportamiento S3 del sistema que quizás estés dejando, MinIO como alternativa a AWS S3 documenta cómo MinIO se mapea sobre S3. La hoja de referencia de línea de comandos de MinIO es el compañero de auditoría para un clúster que sigue activo. Para una nueva instalación, una alternativa mantenida activamente es el estándar.
Archivos simples frente a almacenamiento de objetos nativo
Usa RustFS, Garage, SeaweedFS o Ceph cuando el almacén de objetos debe controlar la durabilidad, los metadatos, la distribución y el layout. Eso compra semántica S3 más rica, replicación o codificación de eliminación, escalado horizontal y versionado donde el proyecto lo implemente. El costo es la dependencia de la representación en disco del motor.
Usa VersityGW, S3Proxy o rclone cuando un sistema de archivos existente debe permanecer autoritativo. Eso compra archivos recuperables simples, respaldos convencionales, inspección directa y compatibilidad con ZFS, XFS, ext4 y NFS. La durabilidad distribuida entonces debe venir del sistema de archivos o del array de almacenamiento, no del proceso S3. En un solo servidor o un NAS, ese intercambio a menudo es el correcto.
Eligiendo el servidor S3 autogestionado correcto
Para un solo servidor que debería parecerse a MinIO, comienza con RustFS.
Para tres o más servidores modestos donde la replicación es el requisito principal, y la aplicación puede vivir sin políticas de bucket y versionado, elige Garage.
Para enormes cantidades de objetos pequeños, acceso mixto al sistema de archivos, o una carga de trabajo de lago de datos que pueda crecer a tablas Iceberg, considera SeaweedFS.
Cuando el mismo clúster también debe proporcionar dispositivos de bloque y un sistema de archivos distribuido, elige Ceph RGW.
Cuando el requisito es específicamente una API S3 sobre archivos ordinarios — un NAS, un archivo, un repositorio de documentos, un rastreador, o un objetivo de respaldo —, comienza con VersityGW.
Cuando el trabajo es traducir S3 a Azure, GCS, Swift, SFTP, u otro servicio S3, usa S3Proxy.
Cuando la implementación es pequeña, temporal, y puede tolerar un servidor experimental, rclone serve s3 puede ser suficiente.
Arquitectura recomendada para un servidor de almacenamiento único
Si las aplicaciones deben alcanzar los datos solo a través de S3, RustFS posee la capa de objetos y el sistema de archivos es un detalle de implementación:
Si los archivos en sí mismos deben sobrevivir a la pasarela, mantén los datos en un árbol POSIX:
En el segundo diseño, la redundancia es un espejo ZFS, RAID, instantáneas, replicación de sistema de archivos, o una herramienta de respaldo convencional. El servicio S3 se puede reemplazar sin reescribir el formato de datos.
Pensamientos finales
El S3 autogestionado mantenido aún existe después de que el repositorio público de MinIO pasara a solo lectura. La elección que importa es si S3 posee los bytes o solo frontea archivos que ya existen. Cada comparación anterior sigue de esa respuesta.
