> 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 ju

> 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/16e1096095c809f31aa938856ca7cc21e2b29fdb/docker-compose.yml#L34 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=./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 "404" is not the response AWS gives to a make bucket request. 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.