alt Hacker NewsI just want simple S3
Comments
`rclone serve s3` is actually a thin wrapper around this: https://github.com/rclone/gofakes3
That repo is a fork of this project: https://github.com/johannesboyne/gofakes3
They bill it as being for testing, but it works great if all you want is a no-fuss S3-compatible API on top of a filesystem. I've run it on my NAS for a few years now to provide a much faster transfer protocol compared to SMB.
I just need something that can do S3 and is reliable and not slow.
I'm a simple man, I just need edge delivered cdn content that never fails and responds within 20ms.
I've used Garage to some success, the garage.toml configuration file could be a bit more user friendly https://garagehq.deuxfleurs.fr/documentation/reference-manua... but with some tweaks there I could get it working nicely both for HDD and SSD use cases, e.g. storing a bunch of Sentinel-2 satellite tiles, alongside thumbnails and some metadata.
SeaweedFS and RustFS both look nice though, last I checked Zenko was kinda abandoned.
Also pretty simple when I can launch a container of whatever I need (albeit bootstrapping, e.g. creating buckets and access keys SHOULD probably done with env variables the same way how you can initialize a MySQL/MariaDB/PostgreSQL instance in containers) and don't have to worry too much about installing or running stuff direcetly on my system. As for unsupported features - I just don't do the things that aren't supported.
S3 isn't "simple" tho.
It doesn't need to care about POSIX mess but there is whole swathes of features many implementations miss or are incomplete, both on frontend side (serving files with right headers, or with right authentication) and backend (user/policy management, legal hold, versioning etc.)
It gets even more messy when migrating, for example migrating your backups to garagefs will lose you versioning, which means that if your S3 secret used to write backups gets compromised, your backups are gone vs on implementation that supports versioning you can just rollback.
Similarly with password, some will give you secret and login but won't allow setting your own so you'd have to re-key every device using it, some will allow import, but only in certain format so you can restore from backup, bot not migrate from other software.
I find it fascinating that a list of OSS/self-hosted S3 projects is on the front page of Hacker News. Familiar with most of these from working with on-premises customers with OpenFaaS. Minio was one of the first we integrated with in 2017 - back then it didn't support webhooks for notifications on object mutation, so ended up sending them a PR and showing it on the stage at Dockercon Austin.
I don't have a horse in this game, but have had pretty reasonable results using SeaweedFS for GitHub Actions caching. RustFS is on my list to test next, and a team mate is quite keen on Garage.
I think we get a "S3 clone" about once every week or two on the Golang reddit.
It strikes me as a classic case of "we need all the interested people to pull in one project, not each start their own". AI may have made this worse then ever.
Personally I would suggest that the "easiest S3" would be simply using NFS. You can get replication with RAID.
S3 is simple for the users, not the operators. For replicating something like S3 you need to manage a lot of parts and take a lot of decisions. The design space is huge:
Replication: RAID, distributed copies, distributed erasure codes...
Coordination: centralized, centralized with backup, decentralized, logic in client...
How to handle huge files: nope, client concats them, a coordinator node concats them...
How will be the network: local networking, wan, a mix. Slow or fast?
Nature of storage: 24/7 or sporadically connected.
How to handle network partitions, pick CAP sides...
Just for instance: network topology. In your own DC you may say each connection has the same cost. In AWS you may want connections to stay in the same AZ, use certain IPs for certain source-destination to leverage cheaper prices and so on...
I don't cet how people are developing app using s3 without actually having a local s3 server ? Everyone is like "just use aws / whatever trendy host atm" but while developping ? I use garage but the main issue i have is the mandatory random keys which means i cannot hardcode them in my compose file. For prod, sure you want that. In dev ? Absolutely not I want to be able to clone my repo, dc up -d and lets go.
I also had quite a hard time to chose one for my homelab too. Settled on garage too but why is it that complicated ? I just want a "FS api" for remote storage in my app. Over http so that i dont have to do weird custom setup just to have a network share and handle everything manually
I wanted the same, so I made my own. Initially I started it without vibe coding, but as I wanted to add more features than the initial working S3 API, I decided it's not worth the time to not vibe simple API stuff. I use it for backups, for a Minio replacement in a Milvus database and other random stuff. Not bad for a week work. It's single node so far and not meant for distributed computing.
Garage has worked well for me and gives a good sense of stability. They provide helm charts for deployment and a CLI. There's also very few concepts to learn to start to use it, while e.g. for SeaweedFS I feel like you need to parse a lot of docs and understand more specific terminology.
This is an interesting write up, but I'm curious about the use case. If you don't need to scale, and you don't need to replicate anything, why do you want S3 specifically? Are you using a tool that wants to write to something S3-like? Do you just like reading and writing objects via HTTP POST and GET? Are you moving an app to or from the cloud?
Better title: I just want local storage with a simple S3 interface.
I was thinking similar to OP and decided to vibe code my own…which was quite a journey in itself.
Can’t say I super trust it so will probably roll it out only for low stakes stuff. It does pass the ceph S3 test suite though and is rust so in theory somewhat safe-ish…maybe.
Garage "unnecessarily complex" . If anything it's the simplest solution in the list especially compared to Ceph or Apache Ozone
I made https://github.com/uroni/hs5 -- focus is on single node and high performance. So plenty of alternatives available.
Unlike the author, I run SeaweedFS without issue locally and with acceptable transfer speeds.
Riak doesn't get a mention? https://docs.riak.com/riak/cs/latest/index.html
How about s3proxy: https://github.com/gaul/s3proxy Among other things, it can serve local folders as s3 api.
Call me crazy, but wouldn't 15 minutes on GLM 5.1 produce a working implementation? I haven't looked at the code, but a non-production-grade Go implementation can't be that complicated.
Edit: Minio is written in Go, and is AGPL3... fork it (publicly), strip out the parts you don't want, run it locally.
Fwiw, yesterday I was messing about with GitLab backups. One of the options for direct off-site is S3. But I want that S3 bucket to live on a box on my own Tailnet.
So I too just want simple S3. Minio used to be the no-brainer. I'll checkout RustFS as well.
It does not sound hard (although it is hard for me!). It sounds like it should be some LinuxServer io container. Doesn't it? At this point S3 is just as standard as WebDav or anything right?
Is the problem here that everyone wants a different like 45% of the S3 API? Or is it that minio sucked all the oxygen out of the air in this space by being good at this, and now we need something else to show up?
Wouldn't RustFS be something?
Not that long ago someone on hn poster this [0] a zig based s3 server in 1k lines, (warning not production ready) but if you really look for something simple, it might fit your case.
Wouldn't Blossom fit this? https://github.com/hzrd149/blossom
Settled with SeaweedFS for replacing minio and getting a good chunk of S3 feature parity. I wonder about the problems OP is posting about. Never seen that behaviour but usually only having a bunch of smaller files.
Hugging Face Buckets are pretty simple: https://huggingface.co/docs/huggingface_hub/en/guides/bucket...
Disclaimer: I work at HF
microceph is pretty nice and straightforward for throwaway s3 endpoints
https://canonical-microceph.readthedocs-hosted.com/stable/tu...
I wanted to try NVIDIA’s aistore for our datasets, but I couldn’t figure out how to get a small version up and running so I gave up (a few years ago, today I’d get an LLM to show me how k8s works).
100% - i really wanted Render to add this, feels like there is potential for a startup here
I use rustfs (for local development, not scaled usage) and it seems solid.
Check out Floci. It is a self hosted AWS clone with multiple services functional, including S3 and Dynamodb.
Based on the list of contenders feels like you might be missing rsync.net?
Well, OP, your requirements section is seriously lacking. You need "s3", but only local, non horizontally scalable?
You failed to answer why you even need s3... Why not a filesystem? Full stop. The entire point of s3 is distributed.
Simple S3 sooooooo S4 ? xD
Why do rust compile times matter for a production deployment?
S3-compatible storage solution: https://www.hetzner.com/storage/object-storage/
If anyone wants an s3 browser with folder counts, and object rendering based on its extension, dm.
someone is 100% going to write the 'i just want simple S4' post next month
vibe code a s3 implementation build on tikv.
[dead]
I only recently realized how much I like using Cloudflare more than AWS :) R2 (their version of S3) is no exception. Much more pleasant figuring out how to use and configure it in Cloudflare than the craziness inside AWS.
Simple for you is not simple for me, and vice versa.
10 users with simple needs = complex software.
Since this has come up 4-5 times on the thread already, the clear subtext of this post is that this developer wants to build to the S3 API, but run their storage locally --- maybe for testing reasons, maybe for data hygiene reasons, maybe for performance reasons. So things like "what about Hugging Face's object storage product" don't really answer their question.