Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: CallFS – S3-style object store in one Go binary (MIT)

github.com

Post reply on HN
Print view View original

1–10 of 31 posts

Show HN: CallFS – S3-style object store in one Go binary (MIT)

#1

Post by ebogdum »

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.

Show HN: CallFS – S3-style object store in one Go binary (MIT)
github.com

Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)

#4

Post by ebogdum »

cowboyscott wrote: post #2

I was wanting this to exist today :) Thanks for sharing the work

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.

Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)

#5

Post by ebogdum »

mt42or wrote: post #3
cowboyscott wrote: post #2

I was wanting this to exist today :) Thanks for sharing the work

https://github.com/juicedata/juicefs

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.

Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)

#6

Post by 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

Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)

#7

Post by ebogdum »

mdaniel wrote: post #6

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

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.

Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)

#8

Post by jasonjmcghee »

mdaniel wrote: post #6

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

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.

Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)

#10

Post by ebogdum »

jasonjmcghee wrote: post #8
mdaniel wrote: post #6

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

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.

A bit of both, as you can imagine, there are so many tedious tasks that consume time for so little in return, so yeah.
Post reply on HN