This is now fixed with the next release.

From https://github.com/gary-kim/riotchat#installation, it requires Node, npm, yarn (for compiling Riot.im), and Make. The latest base image 2.0.0 should have it all.

Only recently did Calendar and aliases start working reliably in the Cloudron SOGo package. I think mailbox sharing still doesn't work but it's in our TODO list.

Because of this, my personal and cloudron.io email setup doesn't use SOGo. @nebulon and I both use thunderbird for day to day use. We have a rainloop installation just to manage our mail filters (in my personal install, I use roundcube for this instead just for variety 🙂 ). This too was because thunderbird's sieve extension was previously not working with Cloudron Email. That problem has since been fixed but thunderbird's sieve extension is not very user friendly, so we stick to rainloop/roundcube. For calendar/contacts, we use our Nextcloud's caldav/carddav. Both Gnome and Thunderbird, have excellent integrations for caldav/carddav. One important consideration here is that we moved out of another provider which let us export carddav. Nextcloud has an importer that works, I haven't tested out the importers of other apps.

Shared mailboxes (like sales@, support@) was quite complicated with thunderbird (because the mail read/unread flag is not per-user). You also have to configure thunderbird to bcc replies so that the other user can see the replies. Recently, we have moved our shared mailboxes to freescout to solve this.

I don't know if this directly answers the question 🙂 I do think if SOGo was in the state it was now when we started, we probably would have used that from the get-go.

@seeker
Open educational resources - Wikipedia
https://en.wikipedia.org/wiki/Open_educational_resources

Not to mention that if your software is closed source you do not need to publish it for all cloudron users if only you want to use it. With a bit of technical knowledge you can build apps yourself (see the link from @mehdi), push it to a private registry and then use the cloudron cli to install it yo your instance.

I am actually hosting a few apps on my Cloudron that I am just building locally (Bitwarden for example before it was available as an official app).

If you don't make your app official you are of course on the hook for maintaining it, but you still benefit from the user management of Cloudron, automatic ssl and backups/easy restore.

https://simply-how.com/free-docker-container-registry lists a few hosted docker registries that offer free private repositories if you don't want to host your own.

Edit: as long as you only need one container you could even use the Docker Hub, as it offers one private image as well.

Just my 2 cents here : like girish said, if you want to run other things besides cloudron, you should install cloudron in a VM.

If you really want to dedicate the whole machine to cloudron, there is really no need to bother with the additional layer of complexity, another OS to keep up to date and such. I would go bare-metal in this case. That's how I've been running cloudron for 2 years, and it's great.

@avatar1024 A lot of the same thought process as here, on block vs file sync.

https://www.enterprisestorageforum.com/storage-networking/nas-vs.-san-differences-and-use-cases.html

"SANs are the higher performers for environments that need high-speed traffic such as high transaction databases and ecommerce websites. NAS generally has lower throughput and higher latency because of its slower file system layer, but high-speed networks can make up for performance losses within NAS."

Here is the thing, Nextcloud is half baked on just about everything outside of file sync. I'd be VERY wary to trust it to handle external syncing. It might be easy to setup, but you're betting on their external storage plugin working as advertised under all conditions.

An interesting idea to be sure!

FWIW, I filled yet another form now to get a response from them. 🤞

@d19dotca Thanks for the write up, I will repurpose it for some our docs.

Another user had actually informed us about this and it's been working reliably for them. So, we already had added OVH storage in the backups UI for the next release.

357c53be-e4aa-4bcc-8cac-b8d7d543e388-image.png

I can attest that it is definitely NOT a good idea to add more Docker images to a CR box outside of CR. CR assumes it has full use of the box, so, anything additional you add can and possibly will break things 🙂

It basically means it's in Beta ^^

OK, @Trankery informed that this happens more most/all freenom domains. This includes .tech as well.

@girish Will do. It's actually not the first time I've run into the problem and a re-fresh of the API credentials solved the problem, although this is the first time I specifically observed that it was a 500 error vs. a 401.

@Hillside502 yes, that was a ui bug!

That makes sense. BlobFuse is what MS uses for Azure and it is definitely, not amazing.

@nebulon Oh! That's awesome, thank you for being patient and clarifying that for me. I appreciate it. So I see that now, it looks like if I'm reading it right it will only run that part to deploy the plugins if that directory does not already exist, and since it will exist of course then it would never be executed. Makes sense. Thanks again! This definitely helps, I appreciate the education on it too. 🙂

@yusf ah