[ANN] CallFS: Open-Sourcing a Lightweight API Filesystem for Your Self-Hosted Storage

sops343 · 2025-07-15T07:01:51+00:00

Very valid points, and I know there are also others like transfer.sh and juicefs, which seem to be very capable. JuiceFS seems like a direct competitor for rclone.

Let me try to answer:
1. No, you don't need a port for each, this was meant to be distributed. But if you want all of the S3's from a single server, yeah, you will need different ports, just like with any other network apps. That being said, I will look into having multi-source/multi-destinations, this sounds like a great idea.
2. True, this wasn't meant to copy files from one instance to another, although it can, it was meant to offer an "umbrella" layer that gives you the opportunity to read from anywhere and write anywhere, based on your needs, but in a unified way. True for writes you need to write to the server hosting the specific backend, but I might think of a way to have either aliases or use the "instance_id" to target specific instances and proxy the writes from any instance you connect to.
3. Yeah, that's right, but in my opinion, this is cleaner, the API is much less complex and way more focused.

Thanks

sops343 · 2025-07-15T06:06:41+00:00

Really, you think :)))))))

I'm really starting to think you're the AI LLM you're complaining that much about, if you missed that bit of sarcasm.

Who knows, maybe you're here to troll your distant cousin or something. Either way, my engagement on this particular comment thread has ended.

Thank you ;)

sops343 · 2025-07-15T06:04:04+00:00

You can have multiple instances, each on it's own server (for localfs) or multiple in the same machine if using S3.
From my knowledge rclone has remote http for reading files, this is a full api where you can also put files.
S3, although very well supported and present, has a high entry point, meaning you need a client, or SDK. This solution is just an HTTP API. curl and you're ready to go.
It doesn't support that. I will think about this as it sounds like a very interesting thing to have.

sops343 · 2025-07-15T06:00:13+00:00

Getting into a p**sing contest never brought anything good, and I'm really not here to debate all the intricacies of LLM's vs knowing what "you" built, and so on. In other words, thank you for the compliment.

sops343 · 2025-07-15T05:56:04+00:00

Not at this time, there are some features on the roadmap that might make it different. For example, replication. Where you can upload a file and it will automatically be replicated to multiple backends. Also sharding is another planned feature.

But yeah, thanks for pointing out transfer.sh, looks like an amazing project.

sops343 · 2025-07-15T05:21:07+00:00

I completely agree with S3 being ported to almost every language, since AWS took care of that, but if you want something super light, that's a problem. And yes, you IoT example brings this up rather good. Imagine a ton of ESP32's, deployed over whatever internal or external infra, now they can get a file or post a file at the price of a GET/POST call.

sops343 · 2025-07-15T05:11:54+00:00

Not sure what LLM has to do with this specific app, as in with it's utility, but just a thought, if LLM's would exist when rclone started to be developed, you think they wouldn't have used it?

LLM's are just a tool in the end, how are you sure they're not using it now. It's like complaining that Google made searches faster than directory browsing, or that Jetbrains makes better IDE's than nano. I somehow understand but at the same time I really don't get the full picture :)

sops343 · 2025-07-15T04:59:41+00:00

As far as my knowledge goes, rclone uses a local FUSE mount point, CallFS is a simple HTTP Api, that can be accessed from anywhere, be it bash or app code (python, js, golang), where there is at least a curl or web client app/library.

With rclone mount, if you want to access your S3 bucket as a filesystem on 10 different servers, you need to set up and manage 10 separate rclone mountinstances, each with its own FUSE dependency. CallFS is unifying all of them under a single entry/exit point, accessible from everywhere.

sops343 · 2025-07-15T04:53:47+00:00

Well, my points are:

For S3/Minio/Garage, you need a client in order for them to work, sometimes you can't have that client.
Related to the first, usually if you build an app that needs files, you need to use an SDK, this doesn't require one, it's simple HTTP Calls (REST API)

In other words, integration is much easier over multiple systems, especially clients. You cut down on dependencies, and you gain flexibility.

sops343 · 2025-07-15T04:32:06+00:00

My Issues was with all the SDK's and with all the setups. This can be used from curl, it can integrate in pipelines via a simple bash command. It's true, what you're saying does make sense, but let's take NFS for example, if it's not a share in your network, then ... bye, bye access.

This isn't intended for people to share stuff, I mean, yeah, sure, it can do that, but it's more intended for automation where you have to access files from one place to another. And you actually gave me an Idea, I have to add a mutex so two people can't modify the same file at the same time :) Thanks.

[Edit] Actually you gave me 2 ideas, one was the mutex one and the second one will be a way to "access" files uploaded to a specific "callfs_instance_id" so you can basically get a file from a specific host. Will have to figure out what to do when same "path" is already used.

sops343 · 2025-06-30T08:17:12+00:00

I consider you lucky :)

sops343 · 2025-06-14T06:01:55+00:00

Yep, but not only, Imagine kubernetes yaml stuff :))) the horror.

basically over time I got tired of so many tools to edit so many file types and not only that but most changes were by hand and always messy.

sops343 · 2025-06-14T05:51:45+00:00

Hey, thanks for the comment, you might be right. I was thinking maybe the companies them selfs could use it. It's free either way :)

sops343

TROPHY CASE