@robi Ahh, i completely understand now. This is a much complex level of what @girish and I are building right now with the VPN Client being one network you can choose to connect multiple other networks to. We’ve scoped that out pretty well so as we work on that and as it gets more fleshed out, I’ll update this ticket with advancements of how we might be able to have take this “sharing networks” basic concept further. I really like this train of thought though so I won’t forget it! ️

Oh, interesting, I hadn't thought of those other use cases for this, but I really like that you brought them up, thanks for the feature request! I'll keep this thread updated with any development on that end if @girish doesn't beat me to it! ️

@atrilahiji I prefer the tag / label approach, and since tags are already built in, I figure they could pull this off first before getting into a more "drag and drop" kind of interface (as well as being able to toggle turning tag-based organization on and off).

@girish I think the key point here is that simplelogin is self-hostable! https://github.com/simple-login/app#self-hosting So we can have this cake and eat it too! I'll add it to the app request list here.

I've added a task in gitlab for this now at https://git.cloudron.io/cloudron/box/-/issues/738

@nebulon anything here - https://bitwarden.com/help/article/website-icons/ ?

Thank you for the quick reply. But even in my testing environment, telling me my backup method is unsafe once a day is just a hassle to weed them out of the Cloudron update (valuable) notifications. I bet I can just trick Ubuntu into seeing the path as a volume to get rid of the notification. But for normal Cloudron users, I bet an option to acknowledge and disable the “backup is unsafe notification” would be valuable for them especially in their first non-production use of Cloudron (where I’m personally at for now).

I guess some webhook api could be supported. It is a bit of work though and lets first see if this feature is also relevant to more people.

@rmdes I think from a user point of view it just needs to work with either, they don't really care as long as typing results in what they were hoping for. From a Sys Admin point of view, www. is more flexible for scaling and high-availability setups. As an example, if you use Odoo enterprise, it must be www. for the websites.

To add to what @nebulon said, https://cloudron.io/documentation/api/#tag/Services/paths/~1services~1{service}~1logs/get is for the addon logs and https://cloudron.io/documentation/api/#tag/Tasks/paths/~1tasks~1{taskId}~1logs/get for task logs.

This is a good idea. I've added it and it will be part of the next release.

it is much better now !! [image: 1598707309146-80a17127-6013-4785-97ca-0433750b3ec8-image.png]

Just leaving a note to myself here . memcached has mechanism for doing auth easily which makes it hard to make it an addon. There is some complicated SASL based auth setup.

Sorry @marcusquinn dident see that you was using ghost for your blog. in that case, SP_mod will be really a bad choose because front-end and back-end are separate similar on how angular/react works. I really advice you do optimize your image manually for now, and w8 ghost will release some improvement on that.

@marcusquinn Great summary! I've similarly found that ingress transaction costs are more than my monthly storage costs with rsync option and tar zip backups keep timing out. @girish Thanks for adding the additional advanced backup configuration in 5.5! I've tried increasing it for my backups and am excited to see if it helps.

@d19dotca I have added some docs now. https://cloudron.io/documentation/backups/#schedule has info on the timeout and nice. https://cloudron.io/documentation/backups/#concurrency-settings on the concurrency settings.

Yeah, I was hoping to get a picture of the storage used by a user or usergroup across all apps on Cloudron. Apart from companies or single user installs of Cloudron, the thinking was that enabling groups of people to share a server and switch to self hosted open source software would involve having insight into the main variable resource - the storage - in order for the cost sharing to be transparent. I understand that's it's not feasible to implement, so will need to think of other community models for resource sharing. Mounting a users own NFS storage is an option, but Cloudron apps are restricted to a single storage location per app instance. Perhaps users mounting their own external storage in an app like Nextcloud is an option. Any thoughts on a clean model for this kind of resource sharing scenario? This seems to me an important consideration for "regular" users of Cloudron, who might want to get together in order to make switching over from Google etc. financially viable.

This seemed trivial to add, so I fixed it for next release. Thanks for the suggestion!

@Hillside502 embarrassing, yeah I accidentally posted here thinking it was the wishlist. I’m on mobile and can’t see a way to move the topic over... @girish, can an admin do that?