@robi Didn't know there was one. I'm guessing it's an Electron wrapper like almost every other "app" nowadays? In which case, I already roll my own with WebCatalog for the extra features.

@YurkshireLad The memory recommendation is the absolute minimum memory below which the app won't run reliably. Like even with 1 user, it won't run properly below that recommendation.

The amount of memory required to host 100 users... is hard to know. Usually, the answer to this depends on the how all these users user Rocket.Chat. If they use simultaneously and if they use it from multiple devices etc. Cloudron will give you a notification (email) if an app is running out of memory. So, you can just take it slow and increase the app's memory limit as you go. You can also look into the upstream project's memory recommendation for 100 users.

@girish Ah yes, sorry. Should've looked. At least maybe this will direct someone to the docs if they end up here again.

The answer depends on how many students are there in a class. mongo db also needs to be scaled up according to the number of instances you install. I don't have a specific recommendation but I would put atleast 2GB per app install. From what I have seen, rocketchat is not that CPU intensive, so 16 core should be OK for ~10-15 installs.

@girish Thanks .

@sstefan I guess you are referring to https://github.com/RocketChat/Rocket.Chat/tree/develop/packages/rocketchat-i18n/i18n ? Is an entire file missing or does a file need to be updated?

Ideally, if you can just contribute your changes upstream, then we can pull it down from there in the next release. Please see https://rocket.chat/docs/contributing/translating/ . Alternately, I can tell you how to build rocket.chat package from Cloudron source package until your changes are merged (it's very easy).

Hi @micmc is this still an issue?

@alex-adestech And the web app requires mongodb? I am wondering why you want mongo username and password. But as @murgero pointed out, please create a new thread and we will help you out.

I understand the upsides of OAuth and initially we attempted to use OAuth in more apps, however more users prefered using ldap for tighter integration, as ldap usually gives a better user experience inside the app not leaving the app first for the redirect. Also the auto login mechanism in OAuth was sometimes confusing. We won't put up the effort at the moment to support multiple auth backends directly in the app installation/configuration out of the box as that increases the testing amount to ensure proper updates.