S3 Explorer: una consola self-hosted para cualquier storage
Durante meses tuvimos un problema que le va a sonar familiar a cualquiera que opere infraestructura en más de una nube: archivos viviendo en AWS S3 y en Vultr Object Storage, un equipo que necesitaba consultarlos y administrarlos, y cero ganas de repartir credenciales de consola de nube a cada persona que solo necesitaba descargar un PDF.
La consola de AWS es demasiado para "encuentra este archivo y compártelo". La de MinIO es excelente — pero solo habla con MinIO. Los clientes de escritorio tipo Cyberduck ponen credenciales en cada laptop. Lo que queríamos era simple: una sola web app, en nuestro propio servidor, donde cada quien entra con su cuenta y trabaja con cualquier almacenamiento compatible con S3.
Así que la construimos. Y después de usarla a diario en el trabajo durante meses, la acabamos de liberar como open source bajo licencia MIT.
Qué es
S3 Explorer es una consola web estilo MinIO que funciona con cualquier endpoint compatible con S3: AWS S3, MinIO, Cloudflare R2, Backblaze B2, Vultr, Wasabi, DigitalOcean Spaces. Es multi-usuario, corre en tu propio servidor como un stack de Docker Compose de dos contenedores (app Node + Caddy con TLS automático), y por dentro es deliberadamente aburrida: TypeScript, Express, SQLite y un frontend en TS vanilla sin frameworks. Sin React, sin dramas de build — tsc y listo.
Lo más destacado:
- Explorador de doble panel, estilo FileZilla — dos conexiones lado a lado, con copiado/movido recursivo entre buckets e incluso entre proveedores distintos.
- Búsqueda en todo el bucket en streaming, respaldada por un índice SQLite FTS5 por usuario, más un filtro local que persiste mientras navegas.
- Versionado de objetos — explorar, restaurar y mostrar eliminados. Suspender el versionado se rechaza del lado del servidor, a propósito: es una pistola cargada apuntando a tus datos.
- Links de compartir presignados con topes de vigencia configurables, previews inline de imágenes/video/PDF/código, y subidas con resolución de conflictos.
- UI bilingüe (español/inglés), auto-detectada y con toggle manual.
La decisión de diseño: lo más importante
Desde el principio tomamos la decisión que moldeó toda la arquitectura: el servidor nunca almacena credenciales S3. Ni cifradas, ni hasheadas — simplemente no las tiene.
Tus llaves de acceso viven en una bóveda cifrada en tu navegador (AES-256-GCM, llave derivada de una passphrase con PBKDF2) y viajan al servidor solo como headers transitorios por request, que jamás se persisten ni se loguean. El servidor es un proxy inteligente con autenticación, no un almacén de credenciales. Si alguien se roba la base de datos del servidor, obtiene hashes de contraseñas y secretos TOTP cifrados en reposo — y cero llaves S3, porque no hay ninguna que robar.
La capa de autenticación alrededor es deliberadamente estricta: TOTP obligatorio desde el primer login (con prevención de replay), hashing argon2id, códigos de recuperación de un solo uso, rate limiting en el login, y protección SSRF que bloquea los endpoints de metadata de nube — porque una app que acepta endpoints S3 arbitrarios de sus usuarios está a un request descuidado de regalar las credenciales del rol IAM del host.
La parte que más nos emociona: AI-first
La release más reciente (v1.3.0/v1.4.0) hace que S3 Explorer sea operable por agentes de IA, y creemos que aquí es donde se pone genuinamente interesante.
Dos piezas lo hacen posible:
Personal Access Tokens — tokens Bearer con alcance (read / write), expiración opcional, visualización única, revocación instantánea y rate limiting por IP. Autenticación de máquina, bien hecha.
Un servidor MCP integrado (s3-explorer-mcp) que cualquier cliente MCP — Claude Code, Claude Desktop y compañía — puede lanzar para obtener seis herramientas: list_buckets, browse, search_files, presign_url, upload_file, delete_object.
El modelo de seguridad compone precioso aquí: el agente se autentica con un token de alcance limitado, tus credenciales S3 se quedan en la config local del cliente MCP, y el servidor sigue sin almacenar nada. Dale a un agente un token read y podrá buscar y compartir archivos, pero físicamente no puede borrar nada — el alcance se valida ruta por ruta en el servidor, nunca se infiere.
El repo además incluye AGENTS.md, llms.txt y una referencia completa del API, para que los agentes de código se orienten sin espeleología.
Lecciones de hacerlo público
Pasar el proyecto de un repo privado a una release pública nos dejó varias lecciones que valen la pena compartir:
- Reescribe la historia antes de publicar. Corrimos gitleaks sobre los 96 commits (limpio), pero todavía acechaban hostnames internos en configs viejas. git filter-repo purgó tres archivos de la historia; el repo público nace honesto.
- Las credenciales falsas deben verse falsas. GitGuardian marcó nuestros fixtures de prueba porque el patrón AKIATEST + super-secret-value se parece a llaves AWS reales. Placeholders tipo test-access-key mantienen tranquilos a los escáneres.
- El CI encuentra tus flakes por ti. Agregar una suite de tests nueva cambió la calendarización de Vitest y destapó un flake de rollover de ventana TOTP en un fixture de login que llevaba meses teniendo suerte en silencio.
Pruébala
Es MIT, está probada (321 tests) y las contribuciones son bienvenidas — agregar un idioma es un archivo de diccionario, y hay good first issues esperando. Si te resuelve un problema, una ⭐ en GitHub de verdad ayuda a que el proyecto encuentre a su gente.