We open-sourced S3 Explorer: a self-hosted console for any S3-compatible storage

For months we had a problem that will sound familiar to anyone running infrastructure across more than one cloud: files living in AWS S3 and in Vultr Object Storage, a team that needed to browse and manage them, and exactly zero desire to hand out cloud-console credentials to everyone who needed to download a PDF.

The AWS console is overkill for "find this file and share it". MinIO's console is great — but it only speaks to MinIO. Desktop clients like Cyberduck put credentials on every laptop. What we wanted was simple: one web app, self-hosted, where each person logs in with their own account and works with any S3-compatible storage.

So we built it. And after using it daily at work for months, we've now released it as open source under MIT.

What it is

S3 Explorer is a MinIO-style web console that works with any S3-compatible endpoint: AWS S3, MinIO, Cloudflare R2, Backblaze B2, Vultr, Wasabi, DigitalOcean Spaces. It's multi-user, runs on your own server as a two-container Docker Compose stack (Node app + Caddy with automatic TLS), and stays deliberately boring on the inside: TypeScript, Express, SQLite, and a framework-less vanilla TS frontend. No React, no build pipeline drama — tsc and done.

Highlights:

• Dual-pane explorer, FileZilla style — two connections side by side, with recursive copy/move between buckets and even between different providers.
• Full-bucket streaming search backed by a per-user SQLite FTS5 index, plus a local filter that persists as you navigate.
• Object versioning — browse, restore, and show deleted objects. Suspending versioning is rejected server-side, on purpose: that's a data-loss footgun.
• Presigned share links with configurable TTL caps, inline previews for images/video/PDF/code, uploads with conflict resolution.
• Bilingual UI (Spanish/English), auto-detected with a manual toggle.

The design decision everything hangs on

Early on we made the call that shaped the whole architecture: the server never stores S3 credentials. Not encrypted, not hashed — it simply doesn't have them.

Your access keys live in a vault encrypted in your browser (AES-256-GCM, key derived from a passphrase with PBKDF2) and travel to the server only as transient per-request headers, which are never persisted or logged. The server is a smart proxy with authentication, not a credential store. If someone walks away with the server's database, they get password hashes and TOTP secrets encrypted at rest — and zero S3 keys, because there are none to steal.

The authentication layer around that is deliberately strict: mandatory TOTP two-factor enrollment on first login (with replay prevention), argon2id password hashing, single-use recovery codes, login rate limiting, and SSRF protection that blocks cloud-metadata endpoints — because an app that accepts arbitrary S3 endpoints from users is one careless request away from handing out your IAM role credentials.

The part we're most excited about: AI-first

The newest release (v1.3.0/v1.4.0) makes S3 Explorer operable by AI agents, and we think this is where it gets genuinely interesting.

Two pieces make it work:

Personal Access Tokens — scoped Bearer tokens (read / write) with optional expiry, one-time display, instant revocation, and per-IP rate limiting. Machine auth, done properly.

A built-in MCP server (s3-explorer-mcp) that any MCP client — Claude Code, Claude Desktop, and friends — can launch to get six tools: list_buckets, browse, search_files, presign_url, upload_file, delete_object.

The security model composes beautifully here: the agent authenticates with a scoped token, your S3 credentials stay in the MCP client's local config, and the server still stores nothing. Give an agent a read token and it can search and share files but physically cannot delete anything — the scope is enforced route by route on the server, never inferred.

The repo also ships AGENTS.md, llms.txt, and a full API reference, so coding agents can orient themselves without spelunking.

Lessons from going public

Taking the project from a private repo to a public release taught us a few things worth passing on:

• Rewrite history before you publish. We ran gitleaks over all 96 commits (clean), but internal hostnames still lurked in old config files. git filter-repo purged three files from history; the public repo starts honest.
• Fake credentials should look fake. GitGuardian flagged our test fixtures because AKIATEST + super-secret-value pattern-match real AWS keys. Placeholders like test-access-key keep scanners calm. Name your fakes obviously.
• CI will find your flakes for you. Adding a new test suite changed Vitest's scheduling and exposed a TOTP window-rollover flake in a login fixture that had been silently lucky for months.

Try it

It's MIT, it's tested (321 tests), and contributions are welcome — internationalization is one dictionary file away, and there are good first issues waiting. If it solves a problem for you, a ⭐ on GitHub genuinely helps the project find its people.