This is great news. Cloudron could now compete as a free, open source, self hosted email solution

Now that letsencrypt provides wildcard certs, cloudron should consider switching over to wildcard cert.

Benefits

1. No more hitting registration limits for users with a large number of apps.
2. Slight security improvement of not making app subdomains immediately public

This might help:
https://cloudron.io/documentation/domains/#changing-the-dashboard-domain

It's already available but not publicly listed.

The biggest limitation of the current configuration is the absence of authentication, which allows anyone to create new spreadsheets.

Although onlyoffice or collabora would be more featured, ethercalc is still a good lightweight collaboration app in addition to etherpad.

Thank you so much. This is amazing!

@girish ofc we need a working (reliable) backup mechanism!

imo the current disable option is already good enough and allows me to easily go around backup errors that prevent upgrades etc.

Maybe...

• differential backup/hard-linking support for some remote backup destination will help with stability
• btrfs, zfs offers more stable snapshots and should be supported in the future

I'd like to make a correction to the docs, but couldn't find its repo on git.cloudron.io

I'd like to correct
https://cloudron.io/documentation/domains/#changing-the-dashboard-domain

Correction:

Change adminDomain to the domain added above.

Original:

Change adminFqdn to the domain added above

Also,

Change adminFqdn to my.example.com, where example.com is your new domain.

might provide more clarity than

Change adminFqdn to my.example.com

It'd be nice if the 20 apps limit could be more lenient. I didn't recall any app limits in the last pricing scheme

Should ideally provide an option to limit access to the local network only. I wonder if this would entail changes to box though

User limits

Since many apps are packaged to have their own user management and thus not bound by the user limits, user limits are not entirely enforceable, cause confusion and dis/advantages users of certain apps. Removing user limits altogether would be a good move.

Premium apps

The advantage is to incentivise users who can likely afford to pay more. In the long run, however, it may stifle community development efforts. Existing apps that are marked premium may receive less development efforts from the community as only Business plan users can use them. Apps yet to come may also see less community help to package and test because of uncertainties on whether they'll become premium. So I would recommend against doing premium apps. Alternatively we at least need clear communications on how new apps will be designated as premium if we're sticking with premium apps.

App limits

It seems limits on the number of apps that a client can run is the only enforceable method that won't inadvertently disincentivise community efforts. And it is easily justifiable that a client pays more for unlimited apps, as (for example) more app installations will likely increase the chance for requiring support from the Cloudron team. Given the choices right now, I would recommend keeping app limits for the "Basic" plan. The "Business" plan, or whatever the top tier plan, still calls for unlimited apps as we don't want to put a ceiling on business opportunities

Naming

Call the "Basic" plan "Standard" or "Essential". It feels better as a customer to pay $15 for something I need rather than some lowly minimum.

Call the "Business" plan "Unlimited" or "Premium". You want to get the customers with deeper pockets who might not run a business.

tl;dr

• Main concerns
  • enforceability
  • community devlopment dis/incentive
• All apps are the same
• No user limits
• App limits for a more affordable plan
• Unlimited apps for an unlimited plan

Ps. There's a missing space on the pricing page: "All plans include atmost 5 instances of the same app."
atmost --> at most

From what you wrote, are you running the server behind your home server in a NAT by any chance?

Yes indeed.

@uiharu Does host cloudflare.com 127.0.0.1 work?

I'll update later

@girish when I run service unbound status it's active (running)
but there's indeed something wrong with the internal dns as firefox (on the server) couldn't resolve anything.

ping 1.1.1.1 looks normal

but nslookup cloudflare.com took more than a few seconds and return answers from my router's dns

so, things have got downhill since I last posted and now I have more than the image problem

For some reason, when I looked in the logs, dns with cloudflare failed before pulling the image...

and then I decided to set dns to noop to test...

and after restart, I'm stuck at "waiting for domain and certificate setup"

So, is there a config file I can edit to change the dns settings?

Many thanks

I just reconfigured my out-dated Nextcloud app, but got errored out because it Failed to pull image.
Could it be that the image is no longer available? If so, could it be republished for a while?

Lots of thanks

User limits

Since many apps are packaged to have their own user management and thus not bound by the user limits, user limits are not entirely enforceable, cause confusion and dis/advantages users of certain apps. Removing user limits altogether would be a good move.

Premium apps

The advantage is to incentivise users who can likely afford to pay more. In the long run, however, it may stifle community development efforts. Existing apps that are marked premium may receive less development efforts from the community as only Business plan users can use them. Apps yet to come may also see less community help to package and test because of uncertainties on whether they'll become premium. So I would recommend against doing premium apps. Alternatively we at least need clear communications on how new apps will be designated as premium if we're sticking with premium apps.

App limits

It seems limits on the number of apps that a client can run is the only enforceable method that won't inadvertently disincentivise community efforts. And it is easily justifiable that a client pays more for unlimited apps, as (for example) more app installations will likely increase the chance for requiring support from the Cloudron team. Given the choices right now, I would recommend keeping app limits for the "Basic" plan. The "Business" plan, or whatever the top tier plan, still calls for unlimited apps as we don't want to put a ceiling on business opportunities

Naming

Call the "Basic" plan "Standard" or "Essential". It feels better as a customer to pay $15 for something I need rather than some lowly minimum.

Call the "Business" plan "Unlimited" or "Premium". You want to get the customers with deeper pockets who might not run a business.

tl;dr

• Main concerns
  • enforceability
  • community devlopment dis/incentive
• All apps are the same
• No user limits
• App limits for a more affordable plan
• Unlimited apps for an unlimited plan

Ps. There's a missing space on the pricing page: "All plans include atmost 5 instances of the same app."
atmost --> at most

Smooth upgrade, thank you!

Thank you so much. This is amazing!

In /app/data/env
HASH_SALT is ChangeMeBy20+KeyLength

Is this of any security concern?

Also, on a Monica instance upgraded from earlier versions, the APP_KEY also appeared to be an unchanged default. I've since reinstalled the app.

Thanks

It'd be nice if the 20 apps limit could be more lenient. I didn't recall any app limits in the last pricing scheme

I forgot to post a follow up on this thread. I'd like to thank @girish for solving my problem. He responded quickly and arranged to ssh into my server to diagnose. He's been very patient and professional and I really appreciate it.

Basically the problem is due to MySQL addons not properly starting/building, so all apps using MySQL error out and cannot start or install. Hope the problem has been resolved in the final 2.4 releases