callfs

> 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 Okay, fine, your example config doesn't work with an inscrutable error. 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"} Let's see if it's really s3 compatible now: AWS_CA_BUNDLE=./ser

But you brought it here to get feedback? Our feedback is things like, the docs (https://github.com/ebogdum/callfs/blob/main/docs_markdown/02...) have a pile of references to things that just don't exist in your code? You have a change-log that isn't used? Your main file references a site that doesn't exist "https://github.com/ebogdum/callfs/blob/main/cmd/main.go".

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

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.