@marcusquinn Yeah that's an interesting approach, kinda like the dedicate cloudron for the build service..?

Very much so agree with your critique of mist.io and its potential value/use case
Also "For me, Cloudron is the classic example of built on the shoulders of giants, and making the access to those giants so quick and easy is where the greatest value lays." +1

My feeling with this is that if it is already dedicated to what it does, then it would be better to have that App in Cloudron for multi-platform management and make use of that, instead of reinventing some of those features in Cloudron where the responsibility scopes would be increasing but the dedication to each responsibility would be thinning.

If mist.io has already solved a of the multi-cloud management needs, then best to have that App as the feature manager, and use it's API with any cloudron development to tap into those features.

Similar principles to being used with OpenVPN as I understand.

For me, Cloudron is the classic example of built on the shoulders of giants, and making the access to those giants so quick and easy is where the greatest value lays.

Let me know if there's anything we can do to help with app packaging because that seems to be the biggest bottleneck at the moment, and maybe if we can do something for ElasticSearch, that will help on the app packaging options.

My feeling is it is likely more performant on a dedicated VM without docker and if Cloudron were to pick up this as a feature, it should be a box add-on, with an option to configure use of separate Cloudron instances.

So you could have it within one Cloudron with the disclaimer your resource needs will be higher, but also the option to setup Cloudrons with no other addons running than Elastic Search, and then other Cloudrons could be configured to make use of others so that resources could be set per the need of each instance.