I think it’s mainly to make it easy to run your own RS server. Both standalone as well as perhaps integrating into the many self-hosting systems that use Docker images these days.
I imagine, without payment gateway integrations, it’d not be feasible to just take the containers and stand them up as a general remotestorage for the public. Would need to repeat the work 5apps must have done for their offering. I mean, the “free” Web still costs money.
Also, out of the box, when standing up an instance for your own apps’ needs, I don’t think there is a mechanism to prevent people from using the instance for any other remotestorage compatible apps out there.
I think I can make both usages more feasible with ‘ledger based authorizations’… We’ll see.
FWIW, there is a possible mechanism to restrict the apps that can use a RemoteStorage instance: CORS. If the server sends the header Access-Control-Allow-Origin: https://myhost.com, (rather than the * that is often sent) then requests from web apps not running on https://myhost.com will be rejected. I don’t know of any RS server that can be configured to do that, but it would be straightforward to add.
CORS by itself doesn’t restrict non-browser apps from accessing a host, so this would not be a security measure, so much as a “cut down the traffic” measure.
I wouldn’t advocate adding anything to Armadietto in and around this anyways, especially the containerized one.
This business I’d leave to the reverse proxy in front of the cluster.
The original question was really more about intention, not technical solutions. How is the docker image positioned to be used.
The logging you’ve added, with ability to limit file logging and control stdout, that’s a value-add for my docker/k8s cluster I appreciate (opinion, others run different). But SSL termination, preflight controls, rewrites, that’s what I personally leave for the reverse proxy.