For the coming weeks, we are going to focus on getting some new apps packaged. The list is:

• OnlyOffice
• Bitwarden - @Felix and @iamthefij have done much of the heavy lifting, we just have to get it across the line.
• OpenVPN - We will add an admin interface that let's the admins configure some popular vpn settings.
• BigBlueButton or Jitsi (we will evaluate which works well for conferencing. We have used both and they both work well but BBB might win). If you have any thoughts here, please leave a comment.
• Development apps - basically provide a git push workflow for hosting custom nodejs/php apps (and make it work so that they can be mixed with various caches and databases).

If we should prioritize something else, please let us know! But the above should keep us occupied this month.

Hi all,
We released Cloudron 4 now. The blog has more details about the release.

Changes:

• SFTP access is built into the platform. As of this release, WordPress, Surfer and LAMP apps support SFTP access. You can get the SFTP credentials from the i button in the app grid. Note that the username for each app is different!
• App tags and labels - this lets you easily categorize and search app. The current UI is very basic, we hope to iterate on this. Feedback welcome.
• Scaleway Object Storage backend for backups
• Easier email import. There is some basic docs on how to use imapsync here
• Unmanaged WordPress app - this app allows you to edit WordPress code unlike the existing WordPress app. Since, we let you edit the code, we won't deal with updates either. You can to use the WPs built-in updater for that. Docs for this app are here. Currently, this app is marked as unstable. So, you have to enable the unstable flag in settings before you can install it/see it in your Cloudron.
• Immediate App Update notifications
• Backups created right before an app update are retained for upto 3 weeks. This lets admins roll back in case they notice some breakage late.
• Community/Unstable apps. There's been a lot of app packaging going on and we can't keep up with testing of all the apps. So, we will get them all listed in the coming weeks, so others can easily test them out.
• Upstream app version is now listed in the app info dialog
• Support for email relays that do not require authentication and self-signed certificates
• Cloudron updates can now be applied without taking a full backup. This was added for situations where there might a bug in the backup logic and an upcoming Cloudron update fixes the backup issue.
• Add a way to disable outbound mail for a domain. Email -> Outbound -> Select Disabled

We are working on pushing out 2.2 early next week. The main feature planned is 2FA/TOTP support for the cloudron.io login and the dashboard.

Users will see a button in their profile section to setup 2FA. You can use Google Authenticator, FreeOTP or similar app to generate one time passwords.

To keep things simple this option will only enable 2FA for the dashboard login. App logins will not requires 2FA. From our initial investigation, many apps already support 2FA and making up some scheme like password+otp will have to carefully thought through from a UX perspective.

An update on this. We tried to push the update today with a plan to roll out later this week. We found some issues with the database migration which we are currently working on. Over all, it's unlikely this gets pushed out this week.

Now for some good news: we have updated all apps to use the latest base image 1.0.0 (which is based off ubuntu 18 and contains many security fixes).

Time for some progress updates!

There is now a system menu:

Inside which, there are services list. You can monitor and configure the services:

Backups can now be cancelled. Updates can also be cancelled. Yes, the layout is bit off here but it will be fixed before the release:

Also, we have reworked the email handling for apps a bit to support some use cases. Currently, apps are create a mailbox of their own and one cannot easily access these mailboxes (if someone replied to the email). We have fixed this so that apps can now be associated with any existing mailbox. By default, an address is auto-generated for the app. You can then change this to an existing mailbox which you can access using your credentials. It's also possible now to share the mailbox name across apps.

https://github.com/hooram/ownphotos

Starting today, we are making a Free Plan available. This plan will provide the
complete Cloudron experience for 2 Apps and 5 users. This plan includes automatic
updates and the Email solution. It's perfect suited for situations like:

• Newly registered domains where one just wants to setup a web site and email
• Users who just want to run a single app like NodeBB, GitLab or Rocket.Chat.

Please note that this does not affect current paid users.

You can see our latest pricing page here.

See our blog post for some background.

The upstream wallabag authors have enabled support for PG10. This means that Wallabag now works in the latest Cloudron version. We have pushed out a new version and it's now available for all -https://cloudron.io/store/org.wallabag.cloudronapp.html

Note that for installations "stuck" in Cloudron 3.2.3, we will enable updates so that they catch up to the latest release (which is 3.5.2)

We have added a user active flag for the next release. When you de-activate a user, it simply won't let them login to the dashboard or any of the apps. No notification is sent to the user that he/she was disabled. In the admin view, you will see a grayed out user (which you can re-activate).

We are working on pushing out 2.1 early next week. The main feature in 2.1 is improved mailbox management.

In Cloudron 1.x, the users/groups and mailbox/lists were tightly coupled. This meant that if you have a user named foo, they got the email id foo@domain.com. If you wanted to create a new mailbox bar@domain.com, you had to create a new user bar and also setup a new password for this user.

In Cloudron 2.1, we have decoupled the mailbox management and user management. You can create a mailbox (in a domain) and then assign a user. So in the case above, you can create a mailbox named bar and then assign the user foo to it. You can thus use a single password to manage any number of mailboxes.

@jimcavoli I am just speaking by reading the docs which might be outdated. https://docs.bigbluebutton.org/2.2/install.html#minimum-server-requirements says:

• 4 GB of memory with swap enabled (8 GB of memory is better)
• 4 CPU cores (8 is better)
• TCP ports 80 and 443 are accessible
• UDP ports 16384 - 32768 are accessible
• Port 80 is not in use by another application

Memory requirements aside, those port requirements are quite extreme. Though maybe they are just trying to say "keep a domain available" to host it, not sure.

@cloudron_account Are you able to join our chat at https://chat.cloudron.io and ping @girish or @nebulon there? Since, this seems to be mostly networking related, it helps to speak directly.

Thanks for reporting upstream. https://gitlab.com/commento/commento/issues/240 for anyone looking for the bug report.

So far, we have finished OnlyOffice, OpenVPN and the development apps (with 3.4). Bitwarden and Jitsi/BBB remain. BBB seems to take a LOT of resources, so I am not sure this is a good bit for our users for the moment despite it possibly having a better UI. That said, we use Jitsi everyday and it works great.

@oatwalker Did that work? I will improve the docs to provide the exact commands

We investigated this offline. The root cause was that the S3 storage service (strato hidrive) does not support multi-part copy. The workaround is to use the rsync format (Backups -> configure -> Format) when you have backups > 5GB.

@yusf Correct, it is best to run the build service app in a separate cloudron. Essentially, the build service is building a lot of docker images. It "cleans up" old images periodically. For both of these operations, it requires full access to docker. There is a chance that it removes containers/images of the other apps on Cloudron by mistake. As in, this would be a bug but if someone hits that bug on a production Cloudron that would be a disaster. This is the reason why we recommend running it on a separate Cloudron.

Finally, the build service app is not required at all. You can just build and push images from your laptop or a linux VM or some VPS which has docker.

This is fixed now, will be part of next release.

I can confirm this is a bug. We are working on a fix.

$ host -t TXT icloud.com
icloud.com descriptive text "google-site-verification=knAEOH4QxR29I4gjRkpkvmUmP2AA7WrDk8Kq0wu9g9o"
icloud.com descriptive text "v=spf1 ip4:17.36.0.0/16 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.110.0.0/15 ip4:17.111.110.0/23 ip4:17.120.0.0/16 ip4:17.133.0.0/16 ip4:17.139.0.0/16 ip4:17.142.0.0/15 ip4:17.151.1.0/24" " ip4:17.158.0.0/15 ip4:17.162.0.0/15 ip4:17.164.0.0/16 ip4:17.171.37.0/24 ip4:17.172.0.0/16 ip4:17.179.168.0/23 ~all"

Adding the above to example.com's SPF maybe is a start.