Show HN: CallFS – S3-style object store in one Go binary (MIT)
29 comments
·July 15, 2025TheDong
> Speaks the S3 API
Let's test that lol.
First, I looked at the docker compose file, seems like an easy way to run it right? Wrong, the docker compose file just runs minio, a real s3 compatible thing: https://github.com/ebogdum/callfs/blob/16e1096095c809f31aa93...
Why check in a docker-compose that only runs someone else's code, not your own project?
Okay, fine, let's run it normally:
./callfs server -c ./config.yaml.example
failed to load config file ./config.yaml.example: file provider does not support this method
But running it without a config flag works, so let's do that:
{"level":"info","ts":1752571569.821955,"caller":"cmd/main.go:251","msg":"Starting HTTPS server","addr":":8443"}
AWS_CA_BUNDLE=./server.crt aws --endpoint-url https://localhost:8443 s3 mb s3://foo
make_bucket failed: s3://foo An error occurred (404) when calling the CreateBucket operation: Not Found
Reading the actual docs, this is _not_ s3 compatible, not even close. So much for "Speaks the S3 API".
Just use minio, or one of the other actually functioning things in this space.
mdaniel
I can't quite square up your "speaks the S3 API" with https://github.com/ebogdum/callfs#file-operations seeming to do its own thing, which for sure would not leverage existing tooling
And it would have been better if in your "static binary" sentence you had included its dependence upon both PostgreSQL and Redis
jasonjmcghee
I had the same question, and started looking more deeply at the project.
Would be interested to hear if this was built by OP or vibe-coded.
evil-olive
> if this was built by OP or vibe-coded
I hope we start to see some etiquette / conventions developed around this, especially for open source projects.
if I showed up to a dinner party with homemade cookies, my friends would be appreciative.
if I showed up with store-bought cookies, my friends would probably still be appreciative.
but if I showed up with store-bought cookies and tried to claim they were homemade, my friends would probably feel insulted. even if the cookies were amazing, they'd be overshadowed by my dishonesty about them.
the problem, of course, is that if we had some standard section in a readme for expressing the spectrum between "0% LLM output, entirely whittled by hand as a labor of love" vs "100% LLM output, human eyes have never actually looked at any of it" we'd have LLMs hallucinate that readme section, saying they were human-coded.
pjc50
Then the more serious one of "do these cookies contain allergen X?"
Any of the answers "yes, no, I don't know" is OK, although the latter is irritating, but if you claim "no" when the allergen actually is present it's a disaster. Whether that's because you bought them and didn't look at the ingredients or made them yourself in a careless shared environment.
For code from the Internet there's the related question "how likely is this to contain security holes or data-loss bugs?" And being LLM-written currently makes that a lot more likely.
thomascountz
Likewise, if I show up with homemade cookies, after your friend asks "who are you and why are you in my house," if they then assume my cookies must be store bought and I probably wouldn't be able to have made them myself, I'd think them rather judgmental.
ebogdum
Will not argue, pro or against, everyone is entitled to their own opinion. But this reminds me of the early 2000 interviews when every one was asking if you used Google search, and now we use "google it" as a verb.
There was a meme at one point with a dude at an interview answering that with something like this: If you google a recipe, it doesn't mean the food is done, you still need someone to cook it.
As for the "xx% LLM" or not, I would argue the same for "xx% Googled", "xx% Stackoverflow" "xx% Learned in school vs copied from the interned", "xx% actual development and engineering vs library importing and glueing".
ebogdum
Very fair points, thank you very much for taking the time. I will make the changes later today to mention the dependencies.
As for the "speaks the S3 API", the idea is that this has two backends right now, Local File System and any S3 compatible API, like AWS S3, MinIO, DigitalOcean Object Storage ... and so on. In other words you can use them all at the same time, provided you have an instance for each.
But you did give me an idea, as to the fact that I need to add some directory/bucket discovery for existing files.
Thank you very much for your feedback.
MOARDONGZPLZ
This is a vibe coded project. It doesn’t work very well at all, not going to rehash what others have found, but these projects have been a major plague to the Go community over the last six months. They’re essentially the code version of littering.
null
techn00
I am so sick of AI generated README's, they follow the samn damn format.
MOARDONGZPLZ
KEY FEATURES :key-emoji:
CONTRIBUTING :handshake-emoji:
CORE FEATURES :apple-core-emoji:
cowboyscott
I was wanting this to exist today :) Thanks for sharing the work
mt42or
evil-olive
https://github.com/seaweedfs/seaweedfs is excellent as well
ebogdum
SO COOL. This is way more than what my scope was, maybe I can learn some stuff.
I do have some future plans on replication and mutex and specific files from specific instances.
Thanks for sharing this.
ebogdum
Well, glad to be of service and I really hope it gives you what you need. If not, just open an issue and we will see what we can do. :)
Thanks for sharing your thoughts.
We started CallFS after yet another late-night “why did the uploads vanish?” incident. Our small team had stitched together rsync, a fragile NFS mount, and an S3 bucket—none of it observable, all of it waiting to bite us.
So we wrote a single-process file service in Go that: • Speaks the S3 API (so existing tooling works). • Stores hot data on local disks for speed; cold data can sit in any S3-compatible bucket. • Exposes Prometheus metrics and JSON logs by default, because “what happened?” shouldn’t be guesswork. • Ships as a ~25 MB static binary—no external deps, MIT license.
Today it’s stable for single-node or side-by-side deployments. Clustering is on the roadmap, replication will follow, but we wanted to share the code early and hear real-world pain points. If storage glue code ever ruined your weekend, we’d love feedback and PRs.