You’ve been there. You need to test an app locally. It expects an S3 bucket. So, you spin up MinIO. You configure the ports. You fight with the credentials. You map the buckets. Ten minutes later, you’re reading distributed systems documentation just to save a 5KB JSON file on your own laptop.
Why are we doing this to ourselves?
We’ve taken a protocol designed to survive a data center apocalypse and forced it to run on a single MacBook.
We’ve convinced ourselves that S3 API compatibility is a non-negotiable feature for local development. It’s not. It’s a cargo cult. The S3 API is a masterpiece of distributed systems engineering, built to handle exabytes of data across thousands of geographically dispersed servers. You are using it to store a backup of your docker-compose file on a machine with 16GB of RAM.
The comment sections of the internet are finally waking up. As one weary developer recently put it: “Just use the damn file system. Why does everyone have to put HTTP between everything?”
Exactly. But if your app absolutely demands an HTTP endpoint because someone hardcoded the AWS SDK, you still don’t need the heavyweight champions. You need a scalpel, not a sledgehammer.
Overengineering isn’t a sign of intelligence; it’s a tax you pay on your own time.
Enter the new wave of lightweight tools that actually respect your local environment. Take Garage. Instead of a ten-page configuration manual, they recently dropped a feature where you can spin up a single node with literally one command: garage server --single-node --default-bucket. Done. Or look at Rustfs, which is quietly winning over developers who just want things to work without the bloat. Even rclone serve can give you a quick local HTTP endpoint without pretending it’s a global CDN.
The twist here is that we think we are being pragmatic by ensuring local environments mirror production. But we’re not. We’re adding failure points, network overhead, and cognitive load to our daily workflow. If your app needs S3 in production, mock the interface in your tests. If it needs local storage, just use the local storage.
Stop worshipping at the altar of object-storage compatibility when all you really want is to save a damn file.
The best local storage backend is the one you never have to think about.
FAQ
Q: But what if my production environment actually uses S3? Don't I need local parity?
A: No, you need functional testing, not infrastructure parity. Mock the S3 API in your test suite. Running a full distributed storage protocol locally to test a file upload feature is like crashing a real car into a wall to test a seatbelt sensor.
Q: What's the practical implication of dropping MinIO for local dev?
A: You save hours of configuration, reduce Docker container bloat, and eliminate local network port conflicts. Tools like Garage, Rustfs, or even rclone serve give you the HTTP interface you need in seconds, without the distributed systems overhead.
Q: Is S3 compatibility actually a bad thing?
A: It's a brilliant thing—for distributed, multi-node, fault-tolerant systems. It's a terrible thing for a single laptop. The obsession with making every local tool S3-compatible is a leaky abstraction that forces developers to manage buckets and policies when they just want to write to a disk.