@jdaviescoates

@nebulon For sure, yeah I figured it may need more interest before it's implemented, and realistically I'm probably the only Cloudron user who's hosting on LunaNode (though I'd love to know if others are too), as I think LunaNode is a nice hidden gem that's not overly used yet and I switched to them recently as I had heard great things and their pricing is pretty good. Brief recommendation at the bottom for anyone interested. I'll let them know too about Cloudron in case they can do anything to help out too. On the topic of DNS at LunaNode though... it seems pretty awesome from what I can tell, as it has integrated load balancing and failover which is perfect and works with their included monitoring feature too (which is like Uptime Robot but provided by LunaNode), and so if my monitor fails and I have a second DNS entry, it'll automatically remove the failed one from the DNS records temporarily until it's back online, giving only the backup DNS entry for the "hot standby" server. Hoping to take advantage of those features in the not too distant future if it's feasible for me to run a second "hot standby" server. Waiting on Cloudron to add in some functionality to clustering which I think is coming in v6. Once that's there, I hope to be able to do that. Nudge nudge. haha. Brief recommendation based on my initial tests so far for other Cloudron users who want a good inexpensive hosting provider: I recently moved my Cloudron server from OVH to LunaNode to test out their performance, and the exact same Cloudron server in OVH used to take 10 minutes to fully come online after a reboot in OVH, and having restored that same server in LunaNode it now takes only 2-3 minutes to fully come online. That's also with some memory-intensive applications like Mastodon and NodeBB (which are always the last two to start in my environment given their resource usage). Same 8 GB nodes between OVH and LunaNode too. This performance improvement now cuts my downtime after reboots for security updates by almost 75%! That's my brief recommendation for LunaNode. haha.

@murgero (you probably know this but just writing it out for the wider audience)... Cloudron was primarily made to install and manage pre-packaged apps. This meant that addons were defined by the package and we don't want end users to make difficult decisions as to what database to use and what caching backend to use. Lesser choices cover 90% of the use cases. But over time, we saw a lot of demand about custom apps. And thus LAMP app and even allowing custom packages. And now we probably also need dynamic addons (ie. select which database post installation or just before installation). While this is doable, this moves Cloudron more and more into PaaS territory. My initial instinct is that it's fine to venture into this space and maybe cover 90% of the use cases but we have to think through it

This is possible but will increase complexity in deploys and maintenance. I have also noticed that MySQL changes things between patch releases a lot. Maybe because their release numbers don't follow semver .

Good morning, that sounds acceptable for me. Have a nice day!

@girish yes, that’s a much better idea. Essentially the ability to “swap” app instances, or in other words the ability to easily promote from staging app instance to production app instance on the same server. That’d be ideal.

Yeah, email ids don't go via LDAP. Email ids and aliases are restricted because in other email systems people can use _, - and + as subaddress. Cloudron only supports + right now but might extend it to - and _. @nebulon IIRC, the _ restriction comes when we had 1-1 mapping between username and email. Maybe it's not relevant anymore. I am more open in allowing it in usernames than mailbox names.

Firefox Monitor Server -- breach data is powered by haveibeenpwned https://github.com/mozilla/blurts-server https://monitor.firefox.com/

I like this idea! I have sorted the graphs by usage for now.

I absolutely would love this option - and by "option" i mean like maybe we can make it "optional". So that you can activate on your cloudron if you want, but if you don't want thats fine as well!

This is awesome!!! Thanks @nebulon

Thanks for clarifying. I could do that, but I’m only looking to put certain apps behind IP restriction, not all of them.

Maybe we could at least introduce an optimization of the databases from time to time. The size of the referenced "ttrss_entries" table went from an insane 1,238 MB (!) to 583 MB after optimization. The following command, maybe via a button, should to the trick: mysqlcheck -Aos --user=${MYSQL_USERNAME} --password=${MYSQL_PASSWORD} --host=${MYSQL_HOST};

@necrevistonnezr Still evaluating what is the best option to update existing installations. Most likely we won't do dist-upgrade automatically. Also, new installations will default to 18.04.