@girish personally I would enjoy the option to limit the E-Mail manager to the groups they are part of. For example some clients use so little resources like only a website with E-Mail that it doesn’t make sense to give them a dedicated server but instead put a few on the same.
Very good points as well, however as @girish says, as this would require to implement shared resources the idea is easier said than done. On the other hand, I personally can't see why it would not make sense to provide dedicated VPS at low cost for its own little resources needs to such client. In when you think about it, any client can grow and in such case the client is already set to scale without any more hassle. Cloudron is not too heavy for a simple basic use as it will adjust its own resources need only for the needs of the installed apps.
Now it would be nice if they could configure their own emails without being able to see let alone change the configuration of others.
Moreover, as explained previously if you install Cloudron for the client, a 10 bucks per month VPS would be more than perfect for such low needs, as superadmin you keep full control of the instance's management for the client and you give it admin privileges so it can fully manage its mail server. And with the upcoming multiple instances of Cloudron feature that should should become easier to manage from your side as well. 😊
Matomo is also not the only web analytics software in the Cloudron appstore, so a generalised solution would be better.
Since Cloudron manages the reverse proxy it could theoretically even inject the tracking code directly into the webserver response. An example of this can be found at https://stackoverflow.com/a/51664342.
@girish I believe they are separate, so need to be added separately as-such.
It seem that FileBase uses Storj as one of its layers, but adds additional features and redundancy beyond the Storj layer, hence the value-add higher pricing.
I just think both ethically aligned with the vision here, and having named support, as opposed to generic, is a nod to their efforts in providing a decentralised and competitive alternative to the incumbents.
I think recent events certainly show us that censorship is an ongoing concern, and replicated redundancy is a necessity to mitigate the risks of what might have been unlikely one day, and has suddenly happened another.
@nj not sure if this would be a good idea to map Cloudron dashboard labels of apps into the apps as such. It will be quite hard to explain where such labels within the app might come from. Further an app label is not required, so it may be unclear what to be used as the fallback default. Or maybe I haven't really understood what kind of label this might be. If you look for general env variable support, the cloudron cli tool support adding further env variables https://docs.cloudron.io/packaging/cheat-sheet/#environment-variables
@girish yeah, that's one option, as is the SSH tunnel, but thinking about a more user friendly approach so DBAs can simply do DBA things with a few clicks from the admin instead of setting up tunnels, etc.
@BrutalBirdie I think this somewhat depends on the use-cases. For production systems, a full restore is probably the best option to get back up. However for non-critical systems, often things are worth debugging to actually find the root cause and fix that to ensure the next update from the restored system does not break again.
@girish No I actually meant instead of storing those files in the box folder, moving them into a standartly installed surfer instance on the same server where one can easily update/modify them etc. without the fear of having them replaced on an update