Suggestion: Cloudron Base Version
marcusquinn last edited by marcusquinn
Here's the thing - Cloudron is awesome, and I'd be happy to pay another licence costs at the same price for this - a "Cloudron Base Edition", since it's really only for Enterprise or Power users. Or maybe less on condition you have another full Cloudron license, so an up-sell?
This would be a lightweight single-app Cloudron instance - just for apps that are intended to be installed to run in the base root of a single server, eg:
- Others intended or wanted not to run within Docker?
It would just have these specific apps designed to work in partnership with parent apps hosted on other Cloudron servers.
There would be no email server, no multi-apps, no app store. Perhaps no Docker at all?
Just a login, User management, Statistics, Settings, Firewall, SSL, OS & Services Updates, Terminal, Logs, File Browser maybe.
It might even be that you have choose what App you are setting up for on Setup, that part I'm not sure of.
This would be for Apps that are not intended to work within the Cloudron Docker containers.
Bonus if it could be controlled from the new multi-Cloudron Dashboard too?
Contained by design, it only has one thing in each server. You want another App? that's another server & Cloudron Base Edition Licence.
It might even be that this is a better way to do High Availability Cloudrons too, since if you want true HA, you probably want root performance and isolation too.
What exactly is the difference to a current Cloudron version where only one app is installed?
Generally there is a reason for why we have this package format we have and providing some other Cloudron edition to run apps in some other package format (docker or not) does not really fall into our territory, there may be better solutions for those apps.
@nebulon My main reason is scaling. Managing one of everything is easy, managing 3 or more is hard.
Let's say you have 10, 20, 50, 100+ needs for ElasticSearch / BBB / whatever should be root software instances.
Best practice suggests they should be on dedicated servers.
That's 10, 20, 50, 100+ servers to manage user, OS updates, firewalls, settings, DNS, SSL, Sendmail, monitoring. All the base things that Cloudron takes care of otherwise.
Maybe there are other solutions - but they tend to also do lots of other unrequired things.
What I don't have is a shortage of clients that would signup to managed services. What I do have is a shortage of time for manual recreation of setups per client.
And I keep seeing "we probably shouldn't package this as it belongs on a separate server", so how about a "this is packaged for you to run on a separate server" answer to that?
I can get dev help with these things but you guys are in charge of the framework and roadmap there, so it makes sense for me only to direct attention where it's building frameworked infrastructure.
I've been down the road of manual setups for each thing, they are never maintained in good time, if ever, when there's always competing interests for time.
It's easy to have something maintained if it's a task in one instance that then happens for all instances. As soon as you have multiple instances, and that person faces logging in to do the same thing in multiple places many times, pre-empted monotony fatigue sets in, and that task gets procrastinated for more creative work.
I'm looking for clarify to design our infrastructure planning because there's a fair few apps that I can see never getting packaged because of this recommendation for separate servers, so I need to plan out how that many server management will look and cover all those things that those servers won't have without Cloudron managing the common base stuff.
Or perhaps having Rudder packaged as a Cloudron App would be an alternative solution?
When we have multi-host on Cloudron 7, I guess you can add a node and deploy just one app on that node. Then you have a single dashboard to manage all the OS updates, firewalls, settings, DNS, SSL, Sendmail, monitoring etc as well. Seems doable!
@girish Exactly, that's where the inspiration comes from, and thought to suggest in case it necessitated any consideration at decision-junctions in that design.
I suppose the consideration then is for if it would be safe and appropriate to have things like ElasticSearch, BBB etc installed "alongside", as opposed to in Docker.
So the Server itself would be a single "container" if you like, there would be no "Apps" as such, just the main system Logs would be the only available for example.
Food for thought anyway because, even though it seems like a less capable version of a Free 2-app install. I'd pay for something like this to have less just for the convenience factor in managing many servers with these isolated single-apps.
Holy crap, this.
Though not PfSense due to their pfsene plus BS coming up. Id go with opnsense. But yes, this would be a phenomenal value add that I would absolutely love to see. A BBB one click install that is autodeployed on a dedicated server via cloudron, hell yeah.
robi last edited by
@marcusquinn this is a good use case for [Sysbox] (https://forum.cloudron.io/post/21281) making the 'server' an actual container with proper isolation.
@robi It's not for a server within a server though, it's for separate VPSs. We already have separate VPSs for ElasticPress & pfSense.
They have all the isolation they need, just that setup & maintenance is manual.
The point is that big servers for lots of things is all well and good when they are lightweight apps - but when you reboot the server, you reboot all of them.
Some things either should have their own dedicated resources they can max out if they need, and other things you don't want rebooting when other things are.
robi last edited by
@marcusquinn Ah so you don't really need to run docker or containers at all.. just manage a VPS resource in a better way.
@robi Yuup - and with a multi-Cloudron control panel it will get even easier!
Your easiest customer to sell more to are your existing customers