For a lot of project that would be sufficient. I've worked on projects that "required" an S3 storage solution. Not because it actually did, but because it needed some sort of object/file storage which could be accesses from somewhere, might be a Java application running in JBoss, might be a SpringBoot application in a container, on Kubernetes, Nomad or just on a VM.

Like it or not, S3 has become the de facto API for object storage for many developers. From the operations side of things, managing files is easier and already taken care of by your storage solution, be it a SAN, NAS or something entirely different. Being able to backup and manage whatever is stored in S3 with your existing setup is direct saving.

If you actually use a large subset of S3s features this might not be good solution, but in my experience you have a few buckets and a few limited ACLs and that's it.

I use a local garagefs on my NAS for small/new side projects, and it’s on my Tailscale for easy access

- Lets me deploy stateless containers easily

- Let’s me leverage the NAS for local redundancy and a more centralized place to do backups

- When a project grows it’s easy to promote it to use a hosted S3

- Local S3 becomes a target for Litestream and Restic

- Developing against the local fs and then handling file storage is a huge friction, unless I’m using something like Rails that already has a good abstraction

At this point S3 is an API spec more than a particular system. Plenty of things only work against the S3 API spec since the implementations have become such popular and relatively cheap and performant storage systems. It gives a nice limited surface area that doesn't allow you to do things that can get too complex or can vary too much across filesystems, etc.