Un vistazo en 30 segundos
- VaultS3 es un servidor de almacenamiento de objetos compatible con S3 en un único binario, con panel web incluido y sin servicios externos obligatorios.
- Licencia AGPL-3.0, escrito en Go, de Kodiqa Solutions. En la práctica lo mantiene una sola persona, y el propio README lo avisa antes que nada.
- Su cifra bandera: 17 MiB de RAM en reposo. Bajo carga sube hasta unos 185 MiB escribiendo objetos de 64 MiB con concurrencia 16, y la medida es del propio proyecto.
- Trae más de 80 operaciones de la API S3, IAM con políticas y OIDC, cifrado AES-256-GCM con claves por bucket, versionado, Object Lock, ciclo de vida, erasure coding Reed-Solomon y métricas Prometheus.
- Lo maduro es el nodo único, incluido el erasure coding entre discos locales. El clustering Raft, la replicación activa-activa y los metadatos repartidos siguen en beta, con dos fallos conocidos documentados por el autor.
- Nace de un cabreo concreto: MinIO archivó su repositorio open source y movió la gestión a su producto de pago.
- Metadatos en BoltDB, objetos como ficheros normales en disco. La vía de salida es un
rclone sync a cualquier otro S3.
Casi todo lo que se instala hoy en una infraestructura sabe hablar S3. Las herramientas de copia, los repositorios de artefactos, los registros de contenedores, los conjuntos de datos que alimentan modelos, media a montones. Y montar el otro lado de esa conversación en casa siempre ha salido caro en operación: o levantas un clúster de almacenamiento distribuido, o dependes de un producto que un día cambia de licencia.
VaultS3 propone lo contrario. Un ejecutable, un puerto, y ya tienes un endpoint compatible con S3 sirviendo. Lo que llama la atención es cuánto ocupa: 17 MiB de memoria residente cuando no hace nada.
La cifra es buena para un titular, pero lo interesante del proyecto está en otras dos cosas: en el hueco que ha dejado MinIO al retirarse del código abierto, y en la honestidad con la que documenta lo que todavía no está listo.
Qué es y quién está detrás
| Dato | Valor |
|---|
| Autor | Kodiqa Solutions (un mantenedor) |
| Licencia | AGPL-3.0, con complementos de pago aparte |
| Lenguaje | Go 1.25+ |
| Primer commit | 22 de febrero de 2026 |
| Versión actual | 4.4.64, del 24 de agosto de 2026 |
| Popularidad | ~1.400 estrellas y 79 forks en GitHub |
| Metadatos | BoltDB embebido, sin base de datos externa |
| Distribución | Binario estático, imagen Docker, paquetes .deb, .rpm y .apk, chart de Helm |
El propio README abre con un aviso que no suele verse en un proyecto que quiere adopción:
Este es un proyecto de una sola persona, y deberías saberlo antes de confiarle tus datos.
Y explica el origen sin rodeos: el autor usaba MinIO, las piezas de las que dependía se fueron detrás de un nivel de pago, y no le apetecía alquilar lo que ya tenía. Así que escribió el suyo.
Esa frase importa más que los 17 MiB, porque marca el tipo de riesgo que asumes. No hay empresa detrás con un contrato de soporte. Hay alguien que corre esto en su propia producción y arregla las cosas porque se las encuentra él también.
Los 17 MiB, en su contexto
La comparativa que publica el proyecto mide seis servidores S3 en reposo, en el mismo host, con Docker y sin tráfico:
| Servidor | RAM en reposo | Licencia | Componentes que hay que correr |
|---|
| VaultS3 | 17 MiB | AGPL-3.0 | 1 |
| Garage | 23 MiB | AGPL-3.0 | 1 |
| RustFS | 70 MiB | Apache-2.0 | 1 |
| SeaweedFS | 98 MiB | Apache-2.0 | 3 |
| Silo | 101 MiB | AGPL-3.0 | 1 |
| MinIO | 184 MiB | AGPL-3.0 (archivado) | 1 |
Dos advertencias antes de sacar conclusiones. La primera, que la medida la hace el propio proyecto, en agosto de 2026, sobre una máquina y con docker stats: no es un banco de pruebas independiente, aunque publican cómo reproducirlo. La segunda, y más importante, que en reposo no significa nada para dimensionar un servidor. El mismo README dice que VaultS3 llega a unos 185 MiB escribiendo objetos de 64 MiB con 16 operaciones en paralelo, y que bajo carga todos suben.
Lo que sí dice el dato es que el proceso base es minúsculo, y eso tiene consecuencias prácticas: cabe en una máquina virtual de 256 MB, en un contenedor LXC de un nodo Proxmox que ya va justo, o en un equipo pequeño de una delegación sin que tengas que reservarle medio servidor.
Hay otro número que conviene mirar antes que el de la RAM. El proyecto sitúa el techo de un nodo en torno a 10 millones de objetos, y calcula que llegar a mil millones pide unos 30 nodos. Si tu caso son millones de ficheros pequeños, ese es el límite que te va a doler, no la memoria.
Qué trae dentro del binario
La lista es larga para un proyecto de seis meses, y ahí está buena parte de su gracia: lo que en otros sitios son piezas que montas aparte o funciones de pago, aquí viene en la caja.
- API S3: más de 80 operaciones, firma SigV4, multipart, peticiones por rango, condicionales, checksums y URLs prefirmadas. Se mide contra
ceph/s3-tests, la batería con la que se comprueba el resto del sector, no contra su propia idea de la especificación.
- Panel web: navegador de ficheros, subida arrastrando, estadísticas, IAM, auditoría y búsqueda, en cuatro idiomas.
- Control de acceso: usuarios, grupos y políticas, SSO por OIDC/JWT, LDAP, STS, CORS por bucket, listas de IP permitidas y registro de auditoría.
- Cifrado: AES-256-GCM en reposo, SSE-S3, SSE-KMS y SSE-C, con claves por bucket, rotación y destrucción criptográfica. Es la misma idea que aplicamos cifrando el almacenamiento por debajo del hipervisor, solo que aquí vive dentro del servidor de objetos.
- Durabilidad: erasure coding Reed-Solomon con un reparador en segundo plano, número de réplicas por bucket y recuperación de huérfanos.
- Gestión del dato: versionado con diff y vuelta atrás, Object Lock, ciclo de vida, compresión, escalonado entre discos rápidos y lentos, y copias programadas.
- Integraciones: notificaciones a webhook, Kafka, NATS, Redis, AMQP, PostgreSQL y Elasticsearch, disparadores tipo lambda y análisis antivirus.
- Importación: trae buckets desde MinIO, SeaweedFS, Garage, Ceph, AWS, R2, Wasabi o B2 conservando fechas, metadatos, políticas y etiquetas.
- Operación: métricas Prometheus, trazas estructuradas, endpoints de salud,
pprof y un vaults3 diagnose que empaqueta el informe de fallo.
Arrancarlo es un docker run con dos variables de entorno, sin fichero de configuración. La primera vez imprime un secreto de administración y crea sus directorios. A partir de ahí, el aws s3 de toda la vida apuntando a --endpoint-url.
Lo que está maduro y lo que no
Aquí es donde el proyecto se gana el respeto. En vez de un «listo para producción» genérico, publica una tabla de madurez por subsistema y cuenta los fallos conocidos de cada uno.
| Camino | Estado | Qué significa |
|---|
| Nodo único (API S3, versionado, IAM, panel) | Estable | El despliegue por defecto, con cobertura de pruebas amplia |
| Erasure coding en varios discos del mismo nodo | Estable | Con pruebas de inyección de fallos: pierdes discos, reconstruye y repara |
| Escalonado y copias | Estable | Migración caliente/frío y copia completa e incremental. La restauración es copia manual de ficheros |
| Clustering multinodo con Raft | Beta | Validado en un clúster real de 3 nodos, pero sin curtir a escala ni entre sedes |
| Metadatos repartidos en varios grupos Raft | Opcional, muy nuevo | Desde la 4.4.54, desactivado por defecto |
| Replicación activa-activa | Beta | La resolución de conflictos por reloj vectorial tiene pruebas unitarias; el sincronizador entre sedes está poco rodado |
Los dos fallos que documenta merecen leerse con calma, porque son justo el tipo de detalle que uno descubre tarde:
En nodo único, borrar un objeto que se escribió antes de activar el versionado en su bucket deja una marca de borrado sin versión detrás. Quitar esa marca después ya no recupera el objeto, y sus bytes se quedan huérfanos en disco. La receta es activar el versionado antes de necesitarlo, y vaults3-cli storage reclaim libera lo que ya se haya quedado atascado.
En clúster, sobrescribir una clave y leerla justo después puede devolverte los bytes anteriores con el ETag y la fecha del objeto nuevo, porque la lectura de metadatos espera a la réplica pero el fichero de datos ya presente en el nodo se sirve sin comprobar si sigue vigente. Converge en un par de segundos y se evita activando versionado en el bucket.
La recomendación del propio autor es la que firmaríamos nosotros: nodo único, con erasure coding entre discos locales si quieres redundancia, y el clustering como función avanzada que validas antes de confiarle nada. Y copia independiente siempre, que para eso está la regla 3-2-1.
Un apunte más que juega a favor: en agosto de 2026 pasó una revisión de seguridad externa de caja blanca con 14 hallazgos, todos corregidos en la 4.4.56 y publicados como aviso público. Que un proyecto joven pague una auditoría y luego cuente los resultados con nombre y apellidos dice bastante de cómo se lleva.
El hueco que ha dejado MinIO
Durante años, «S3 en casa» y «MinIO» eran casi sinónimos. Eso se acabó.
MinIO retiró la consola de administración de su edición comunitaria en 2025 y el repositorio minio/minio de GitHub está archivado, en solo lectura, con su último cambio del 24 de abril de 2026. El desarrollo se ha movido al producto comercial, AIStor, y la licencia que distribuye hoy la compañía es de las que hay que leer entera: sin un acuerdo Enterprise en vigor solo permite «una instancia del software, para evaluación interna no productiva».
Traducido: quien tenga MinIO corriendo en producción con la idea de que es software libre, tiene deberes pendientes. Y comparar «MinIO» con «VaultS3» bajo la etiqueta común de S3 de código abierto ya no describe la realidad.
Ese vacío ha llenado el terreno de candidatos. Silo, el fork que mantiene la gente de Pigsty, conserva el formato en disco, la API y las variables MINIO_*, así que una instalación existente sigue funcionando tal cual: es la salida natural si lo que quieres es no tocar nada. RustFS y SeaweedFS están bajo Apache-2.0, por si la AGPL te da problemas. Y VaultS3 apuesta por otra cosa, recuperar la experiencia que hizo popular a MinIO en su día —descargas, ejecutas, tienes S3— con el panel y las funciones dentro y sin nivel de pago que las retenga.
El autor lo pone por escrito con fecha: nada de lo que hoy es gratis se mueve detrás de un muro de pago, el núcleo sigue siendo AGPL, no hay telemetría, no hay cuenta que crear ni clave de licencia. Lo comercial son complementos aparte para flotas grandes (consola multiclúster, operador de Kubernetes, pasarela multiinquilino y un paquete de cumplimiento), programas distintos que hablan con el núcleo por su API. También reconoce que los colaboradores firman un CLA y que, por tanto, podría relicenciar si quisiera. Preferimos esa clase de aviso a un silencio elegante.
Frente a Ceph, Garage y SeaweedFS
Que consuma poco no lo convierte en la opción correcta. Cada una de estas plataformas resuelve un problema distinto:
| Solución | Qué es | Complejidad | Dónde encaja |
|---|
| VaultS3 | Servidor S3 en un binario | Baja en nodo único | Laboratorios, edge, delegaciones, endpoint S3 local de una aplicación |
| Ceph RGW | Pasarela S3 sobre un clúster Ceph | Alta | Plataformas grandes que ya tienen bloque y ficheros sobre el mismo clúster |
| Garage | Almacén distribuido deliberadamente estrecho | Media-baja | Réplica entre sedes con hardware y enlaces desiguales |
| SeaweedFS | Object y file storage distribuido | Media | Cuando hace falta montaje FUSE y capa filer, no solo objetos |
| Amazon S3 | Servicio gestionado | Baja para quien lo usa | Escala que no quieres planificar y durabilidad que no quieres ingenierizar |
Ceph juega en otra liga y hay que decirlo claro: da objetos, bloque y ficheros sobre el mismo clúster, su RADOS Gateway implementa una parte muy amplia de la API de S3 con políticas IAM, OIDC, LDAP, cifrado y configuración multisede, y lleva más de una década en producción en sitios serios. El precio es operativo, empezando por los tres OSD que la documentación pone como mínimo para tener redundancia de verdad, y siguiendo por todo lo que hay que saber para operarlo un martes a las tres de la mañana.
Garage es la comparación más directa por filosofía: también es pequeño, también es un binario, también idle en decenas de MiB. La diferencia está en el alcance. Garage renuncia a propósito a erasure coding y versionado para hacer muy bien una cosa, replicar entre nodos poco fiables. VaultS3 mete más funciones dentro, con lo que eso implica de superficie que mantener.
SeaweedFS es otra cosa distinta: tres componentes —master, volume y filer—, montaje FUSE maduro y un modelo pensado para muchísimos ficheros pequeños. Más posibilidades, más piezas que administrar.
El software no da los once nueves
Conviene no confundir dos capas. Amazon S3 no es solo una API, es una infraestructura con redundancia entre zonas de disponibilidad, sustitución de hardware y una durabilidad anunciada de once nueves que no la firma un binario, la firman miles de discos y un equipo operándolos.
Cuando montas tu propio S3, esa parte pasa a ser tuya. La durabilidad final de tus objetos no la decide VaultS3: la deciden cómo están montados los discos, si hay erasure coding o no, si existe copia en otra ubicación, si alguien verifica que esa copia se puede restaurar y con qué frecuencia. El software es la interfaz; el resto es diseño de plataforma, y es exactamente el mismo trabajo que hay detrás de mandar las copias de PBS a un S3 fuera de sitio.
A cambio, la ecuación económica cambia por completo. Sin coste por petición ni por gigabyte de salida, con los clientes en la misma red que el almacenamiento y con una factura que no se mueve con el tráfico. Es el mismo cálculo que empuja las repatriaciones desde el cloud público, y el mismo que hace que el argumento de soberanía del dato deje de ser abstracto en cuanto el dato es tuyo y está en tu sala.
Una cosa más a favor, y no es menor en almacenamiento: la vía de salida. Los objetos son ficheros normales en disco y el índice es un fichero BoltDB, servidos por la API S3. Migrar a otro sitio es un rclone sync o un aws s3 sync al ritmo que quieras, con el origen sirviendo lecturas mientras tanto. Esa pregunta —cómo me voy si esto se muere— habría que hacérsela a cualquier producto de almacenamiento antes de meterle un terabyte.
Dónde lo pondríamos y dónde no
Para un laboratorio, una máquina de desarrollo, un homelab o un endpoint S3 local de una aplicación, VaultS3 nos parece una elección muy razonable: tarda dos minutos en estar arriba, no arrastra dependencias y trae panel, IAM y cifrado sin pedir nada a cambio. También encaja bien como destino S3 en una delegación pequeña, donde el hardware es el que es.
Para almacenar el dato que sostiene un negocio, nuestro criterio es más cauto y coincide con el del propio autor. Nodo único con erasure coding entre discos, versionado activado desde el primer día, Object Lock donde haya que protegerse de un borrado malicioso, y una copia independiente en otra plataforma y otra ubicación. El clustering y la replicación activa-activa, a laboratorio hasta que salgan de beta y las hayas roto tú mismo con tu carga.
Y la comprobación que no se salta nadie: restaura. Un almacén de objetos del que nunca has recuperado nada no es un almacén, es una carpeta con buenas intenciones.
Si estás valorando montar almacenamiento compatible con S3 en tu propia infraestructura y quieres que la parte aburrida —discos, redundancia, copia fuera de sitio, quién responde a las tres de la mañana— esté resuelta, mira nuestra página de almacenamiento de objetos o cuéntanos qué tienes que guardar. La conversación empieza siempre por cuánto puedes permitirte perder, no por qué binario instalar.
Preguntas frecuentes
¿VaultS3 es realmente compatible con Amazon S3?
Implementa más de 80 operaciones de la API y se mide contra ceph/s3-tests, la batería de pruebas que usa el sector. Funciona con los SDK y herramientas habituales, pero implementar la API no es reproducir el servicio de AWS: quedan operaciones fuera y el comportamiento en los bordes puede diferir.
¿De verdad funciona con 17 MiB de RAM?
Es lo que consume el proceso en reposo, medido por el propio proyecto con docker stats. En cuanto entra tráfico sube: unos 185 MiB escribiendo objetos de 64 MiB con concurrencia 16. Tómalo como señal de que el proceso base es ligero, no como un requisito de dimensionado.
¿Está listo para producción?
El nodo único sí, incluido el erasure coding entre discos locales, y así lo recomienda su autor. El clustering con Raft, los metadatos repartidos y la replicación activa-activa están en beta, con fallos conocidos publicados. Para datos críticos: nodo único, versionado activado y copia independiente.
¿Puede sustituir a Ceph?
En un laboratorio o una instalación pequeña, sí y con ventaja de simplicidad. En una plataforma grande, no: Ceph da objetos, bloque y ficheros sobre un mismo clúster distribuido, con multisede y años de rodaje. Son escalas distintas.
Si venía de MinIO, ¿qué opciones tengo?
Tres, según lo que busques. Silo, el fork de Pigsty, mantiene formato en disco, API y variables MINIO_* para que la instalación siga funcionando sin tocarla. RustFS o SeaweedFS si la AGPL es un problema en tu caso. Y VaultS3 si prefieres un binario pequeño con panel y funciones incluidas, aceptando que lo mantiene una persona.
¿Cómo me llevo los datos si un día quiero irme?
Los objetos son ficheros normales en disco y el índice es un BoltDB, todo servido por la API S3. Un rclone sync o un aws s3 sync a cualquier otro almacén compatible basta, y el origen sigue sirviendo lecturas durante la migración.
Fuentes
