@RoboMod Thanks for the script and @ruihildt thanks for the suggestion. We will look into this in a coming release. It makes sense to keep them in sync. I have long wanted better backup rotation policies as well - https://git.cloudron.io/cloudron/box/issues/441

I would say: Learn docker. This is the base deployment tool for Cloudron. No need to learn compose/swarm etc. Take some time to learn Heroku. Also see 12 factor app. A lot of ideas for Cloudron app deployment are inspired from these two PaaS concepts. Heroku can deploy lots of different frameworks/stacks, so just pick one you are comfortable with. And then the tutorial link above should be easy to follow. Without knowing 1 & 2, the tutorial can be hard to understand. Finally, there is lots of code at https://git.cloudron.io/box (looks for -app suffixed repos).

@rfg You have to setup a mail relay for your outbound mails. The big cloud providers like aws, gce, azure will all block emails from VMs directly. See https://cloudron.io/documentation/email/#relay-outbound-mails

@girish this all sounds great - looking forward to the next release! It would also be really nice if there was a simple way to limit the visibility of apps by domain (perhaps using groups?). I realise that at present it's possible to create groups and then limit access to specific apps to specific groups, and that could be used now to achieve this, but I'd like a quicker and easier way to say to Cloudron: "this group has access to all apps on this domain" (but none of the other domains) than having to do it app by app. Make sense?

We are quite attached to hastebin since it's one of the first apps that we packaged on Cloudron For mail client, I use thunderbird on desktop and k9 on android. I use rainloop to setup filters. The thunderbird managesieve extension is not the best.

@girish said in I believe in Cloudron's mission 200%. How can I help?: what the issue is here sometimes warning are only to warn you such as asking you to take a look, often if you able to explain why it's like that and it sound reasonable from a security perspective it's fine. The grub and kernel issues (which are the bulk of it) are outside the scope of Cloudron especially on a VPS. I also don't applied all recommendation because it restrain too much the instance such as an example it will be impossible to login as root from the console unless you reboot at the level 1

@iamthefij Well the you can make it so you're not discoverable unless you message the person. Thats pretty anonymous

Thanks for reaching out, sounds like a very interesting conference. I will send you a mail to get in touch. Best, Johannes

Can you describe the use-case a bit further? Cloudron already collects logs for each application and addon, as well as the Cloudron related platform components. Generally it is not supported to install other daemons on the side of Cloudron on the same server, since we cannot test such configurations during updates. FYI all the logs are collected currently as described here https://cloudron.io/documentation/troubleshooting/#logs

@nebulon said in Other pricing model for small installation: dev license and for the dev license, it is one dev license per server/installation ?

Our subscriptions are per Cloudron instance, so per server. We might add multihost or some kind of cluster feature in the future, but so far there was no strong focus on this yet.

@nebulon said in Do the Cloudron MailServer have a TRACKER_ID ?: thunderbird plugins installed? you got me, I forgot my mailhop plugin ;s

OK, I did another round of searching for answers.. I understood a lot from these two posts - https://schub.wtf/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html and https://schub.wtf/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html (from one person behind diaspora). It seems the apps started out initially just federating with instances of themselves. When this was the case, they used webfinger for discovering accounts and information about an account. All the apps are just using @username@installation_domain (and not root domain). Peertube has no setting like LOCAL_DOMAIN - https://github.com/Chocobozzz/PeerTube/blob/develop/config/production.yaml.example#L6 . Same for pixel fed - https://github.com/pixelfed/pixelfed/blob/dev/.env.example#L7 . I guess nobody has gotten to the point of having the same @username@rootdomain to be used across apps. This makes sense because the apps don't really talk to each other apart from providing an activitypub stream. Think of it as each of those document editors supporting MSXML. None of them could load each others stuff in the very early days. In essence, the correct approach for Cloudron for now is to not let LOCAL_DOMAIN be configurable in mastodon. It's just confusing that it even exists without the surrounding standards to support it across apps.

Thanks, I have added both to 4.5 roadmap

wow that’s way more than cool! i’m gradually discovering the magic of Cloudron. Loving it!

Great news! Than I can install on my small server. Have a nice evening

@jdaviescoates You are welcome to suggest merge requests to https://git.cloudron.io/cloudron/docs if you have lots of minor changes (and it feels painful to open a forum thread/suggestion).