This is something I've been batting around implementation ideas on for a little while now. There's a ton of variability provider-to-provider to account for on automating some of it, so I was leaning toward more capable cluster managers that are already available off the shelf. Easily the most capable is Kubernetes, but it comes with a lot of added complexity. It's distinctly possible based on the way Cloudron works to entertain some of this stuff, and I've been sketching out a number of different ideas. Nothing is formally roadmapped afaik right now.

That said, it would be helpful in thinking about options what you see as the changes in your experience that these sorts of ideas would enable. Adding an additional node, which seems to be what 3 of your 5 ideas are focused on (load balancing, hot stand-by, and auto-scaling), may or may not be the best approach to minimize downtime depending on how the "normal" use would pan out. It's already not all that difficult to keep an alternate machine restored from backups as a standby, but given the way the system handles app-level failures, it's hard to say in what cases that would be useful; there's added difficulty in reversing that failover and keeping it real-time.

Ultimately, what probably does make the most sense to close the gap on those goals while not messing too much with the underlying architecture and existing packaging is some sort of coordinated cluster manager that keeps the single-container approach but allows the system to reallocate those app containers across k different servers. Something short of Kubernetes could achieve this pretty easily, but will need a lot of work to pull off. For these reasons, I've started looking more at Hashicorp's Nomad as a potential solution to the cluster management side of things, but I'm still in the very early stages of what a Cloudron implementation would look like. At its full potential, this could enable things like multi-region and even multi-provider deployments. Ideally, the details of managing this would be hidden away behind the Cloudron interface, but I've not even yet begun to start spiking out an actual implementation.

I'd love some more thoughts and feedback on the approach generally though!

Likewise - this seems tantalizingly close to ready - and it's high up my list of things I'd like to get to deploying. What's the remaining to-do list or best way(s) to contribute at this point?

I recently stumbled across the MIT-licensed SPFToolbox project and it got me thinking a lot more about more comprehensive mail server features and management tools that would be good to have in Cloudron. SPFToolbox has some nice functionality for running checks for all sorts of things, but its blacklist checker is what started to get my mind running about that feature and potentially others that would be awesome additions to the Cloudron email system to help administrators manage deliverability and so on.

This probably starts to creep into a bigger re-vamp of the email management area of the product, but IMO since mail servers objectively suck to maintain, the ease of use of the Cloudron mail system is a huge selling point. While it's probably not realistic to target everything that services like MXToolbox do, but there could be some more built-in and automated to make life even easier.

Some thoughts out of the gates:

• Blacklist monitoring
• Rspamd - Haraka is ready (https://github.com/haraka/haraka-plugin-rspamd) - with some of its handy modules:
  • Possibly include web ui to shortcut the configuration management; definitely an "advanced" option though
  • Antivirus - https://rspamd.com/doc/modules/antivirus.html
  • Phishing - https://rspamd.com/doc/modules/phishing.html
  • Greylisting - https://rspamd.com/doc/modules/greylisting.html
  • Metric Exporter - https://rspamd.com/doc/modules/metric_exporter.html
    • would let rspamd feed metrics into graphite for graphing in the box ui
  • I'd favor probably pushing some of what are currently haraka plugins' responsibilities around the SPF/DKIM/DMARC space down to rspamd as well given its much higher configurability/visibility if well-implemented
• Perhaps getting into automatic cryptographic signing/encryption with something like CipherMail in the mix - definitely needs some more thought
  • This might be best done by rethinking the way haraka fits in the MTA chain - maybe making other MTA-interfaced apps available via the app store like this one would be a good thing, then in the mail server admin, you could choose which one(s) of those installed are inserted for each domain?

I'm just sort of thinking out loud here, and would like to see what others think about those ideas or any other ideas about the mail server here.

So I have an initial packaging for this done at https://git.cloudron.io/jimcavoli/n8n-app

HOWEVER, I'm honestly not sure I'd be comfortable putting this software into production as-is. It's pretty weak on some security features, but maybe its not the end of the world for people and I'm just super paranoid. There seems to be an undocumented way to do JWT auth, which I'm not going to even try to get into that, since I'm only aware of it from looking at the config file handling typescript code. The only supported authentication right now is basic auth as documented - with a single username/password set by ENV or config file (I went with the latter since it's easier for end-users to edit in /app/data/.n8n/config by terminal).

Either way, everything basically works, and by launching via supervisord with the working directory set to /app/data/output we're able to contain its binary file writing to system (probably a bad thing to do in prod as well, but it works).

Custom nodes can be added to /app/data/custom, the config file is JSON at /app/data/.n8n/config, and the package writes cloudron-provided postgresql configuration to that file at launch.

Some stuff only works in Chrome. That's just an issue with the app. Something about they way they're handling web sockets means other browsers see "Connection lost" in the top right, which is where the Activation toggle should be. Most other things actually work fine, but that's necessary for executing workflows in-browser manually and activating them.

I packaged this one because it seems to have some popularity in asks, but it definitely deserves some due diligence before heading to production for anyone or the app store. It's also pre-1.0 so not sure how much is changing how fast, and the setup as is was a pretty delicate thing to get done. Maybe my concerns are overplayed, maybe not, but either way, there's something we can start to kick the tires on for this app now.

Love the conversation this has kicked off, and I think there's a few good things to consider here:

• The main thing I was originally aiming at first was better visibility into the mail subsystem and second to that more control over those various components
• Expanding the capability of the mail system to include additional processing by farming out additional processing to external servers like CipherMail, Proxmox, etc. could be done easily for even sparsely-resourced servers. However, optionally enabling certain processing like Antivirus on the same machine is still likely a good idea.

A lot of us are also running fairly beefy servers for large production setups and it seems disingenuous to rule out completely more resource-intensive operations from the core packaging just because some machines at the lower end couldn't support them. Making them optionally available, even subject to certain resource constraints and so on, is exactly what I'm hoping we can get to - a lot more control over the mail system so that administrators can choose how much in terms of resources to invest in that system. A combination of more inspectable, optional services available on the core offering as well as allowing external smtp-based components to slot into the workflow sounds like the best of all worlds.

The main issue with Nextcloud Talk that I see is that it's part of the Nextcloud-as-a-monolith model that they push, for understandable reasons. However, a lot of organizations have serious needs around chat with deeper integrations. For example, Rocket.Chat can enable one-click video conferencing, on top of all the other myriad of features, right there where users already are communicating with each other and with services, bots, and notifications by using either BBB or Jitsi, which is great, and means we don't need to have users switch tools just for video calling. Talk lacks this kind of integration in general, which just makes it tough, and it's (imo) not quite mature and suited as the alternatives described.

Similarly, between BBB and Jitsi, there are lots of options to do more advanced things than just integrate them with another chat client, like embedding those conferences into web pages via Jitsi's API for that or BBB's Wordpress plugin / API or into an LMS like Moodle (also on the wishlist) via plugins (for BBB or Jitsi). Jitsi also has the ability to live stream in addition to record meetings (BBB can also do recording). Basically, if I'm going to spend valuable server resources (and transitively money) to run a video conferencing solution, I want more mileage/"bang for my buck" than Nextcloud meet offers.

I think Talk is a great starting point for anyone with casual interest, limited needs, or just exploring video conferencing as a tool, but once we get to the proverbial big leagues with heavier-duty use cases, it's hugely beneficial to have one of these more fully featured tools. That's also striking at one of the huge advantages of the Cloudron platform - everyone can deploy the right-sized solution for their needs with ease and spend the energy on evaluating and transitioning tools as it's necessary, rather than getting mired in the administrative overhead of operating an existing one.

As a parting thought, I'll add that today I find myself leaning more toward Jitsi than BBB after (finally) a positive experience with an event leveraging the public meet.jit.si and thinking about the live streaming capabilities...frankly, as I've sworn up and down repeatedly in this thread, either would be great. If the hardware demands are too extreme on BBB, then let's go Jitsi. The control and privacy are really the banner features, imo, and both do an excellent job on those core requirements.

An initial skeletal packaging of Grafana is up at https://git.cloudron.io/jimcavoli/grafana-app and everything works as expected. There's an outstanding issue around outgoing mail for notifications...details are on the chat server...but essentially, it's waiting on a fix to STARTTLS handling in the mail add-on. After that's fixed, this should be pretty much ready to move forward.

So far:

• Cloudron LDAP for SSO works and Cloudron admins are automatically mapped as Grafana admins
• App settings are stored in a postgres database
• Provision for user-specified configuration by environment variables set in /app/data/env
• Ability to add plugins to /app/data/plugins
  • A thin wrapper for grafana-cli is also provided and set first in PATH - this also allows simply opening the terminal and pasting the grafana-cli commands from the plugins directory to work as expected
• Installs and uses the new grafana-image-renderer plugin automatically (no "using phantomJS" deprecation warnings)

Group-/sub- admin accounts remain high on my list and I certainly look forward to seeing that in 4.5. Overall, this is a really good list of features that is clearly being developed and prioritized with a lot of weight to community feedback, which I think deserves some major applause!

Initial packaging: https://git.cloudron.io/jimcavoli/snipeit-app

With all the activity on this thread, is it likely that Bitwarden will see release in the App Store any time soon? Even as an "unstable" package for easier trial by others?

Love the conversation this has kicked off, and I think there's a few good things to consider here:

• The main thing I was originally aiming at first was better visibility into the mail subsystem and second to that more control over those various components
• Expanding the capability of the mail system to include additional processing by farming out additional processing to external servers like CipherMail, Proxmox, etc. could be done easily for even sparsely-resourced servers. However, optionally enabling certain processing like Antivirus on the same machine is still likely a good idea.

A lot of us are also running fairly beefy servers for large production setups and it seems disingenuous to rule out completely more resource-intensive operations from the core packaging just because some machines at the lower end couldn't support them. Making them optionally available, even subject to certain resource constraints and so on, is exactly what I'm hoping we can get to - a lot more control over the mail system so that administrators can choose how much in terms of resources to invest in that system. A combination of more inspectable, optional services available on the core offering as well as allowing external smtp-based components to slot into the workflow sounds like the best of all worlds.

@girish Thanks! trying to figure out where to submit changes for additional extensions - unclear on that from what you've linked, but bumping the infra version got citext out of the way. This time I got smart and checked the rest of them - I believe hstore is already enabled, and plpgsql, so that just leaves pg_stat_statements - which I hadn't brought up previously, but is handy for many reasons, but also required in to get loom up.

Full list of extensions used by loomio:

  enable_extension "citext"
  enable_extension "hstore"
  enable_extension "pg_stat_statements"
  enable_extension "plpgsql"

Bit of the way through packaging, running up against a permission failure with PostgreSQL:

PG::InsufficientPrivilege: ERROR:  permission denied to create extension "citext"
HINT:  Must be superuser to create this extension.

Not the first time I've hit a hard stop due to the PG extensions missing - wonder if there's a more systematic way to solve for PG extensions going forward?

Initial packaging: https://git.cloudron.io/jimcavoli/snipeit-app

@yusf Not as of yet...last few weeks have been very long hours for me on a litany of other things. I'll hopefully be getting some time back in a week or two

@girish There is pending IMAP support in https://github.com/discourse/discourse/pull/8301 which has been going through some back-and forth for review since November, but it's looking pretty positive as far as actual merge/release possibility in the next few months. If that happens, it's definitely the easiest option on the board.

From a cursory glance, it looks like the latter may be possible, though with some custom records and the like, it would be a somewhat more involved setup. Frankly, the most appropriate way to do that would be for box to have a DNS add-on that could handle things like this...also would help automate install on certain things requiring SRV or TXT records and the like. After that, there's the problem of handling the transport on port 25 which would require another round of changes to the shared mail server (haraka) to answer correctly and pass those emails off to the app...also not impossible, but another thing to do. Turns into a bit of a feat, but it is possible. I see no reason it couldn't be pulled off in a generally-useful way, but it would definitely be a serious set of work and not be done super fast. The ROI for other use cases than just discourse is likely to be a major consideration along the way. The mail server changes are more the issue than the DNS ones, imo. Worth thinking about though.

Another +1 for group managers (I've mentioned this before of course ). This would relieve a lot of my reservation on granting user manager to certain folks in some organizations!

So I have an initial packaging for this done at https://git.cloudron.io/jimcavoli/n8n-app

HOWEVER, I'm honestly not sure I'd be comfortable putting this software into production as-is. It's pretty weak on some security features, but maybe its not the end of the world for people and I'm just super paranoid. There seems to be an undocumented way to do JWT auth, which I'm not going to even try to get into that, since I'm only aware of it from looking at the config file handling typescript code. The only supported authentication right now is basic auth as documented - with a single username/password set by ENV or config file (I went with the latter since it's easier for end-users to edit in /app/data/.n8n/config by terminal).

Either way, everything basically works, and by launching via supervisord with the working directory set to /app/data/output we're able to contain its binary file writing to system (probably a bad thing to do in prod as well, but it works).

Custom nodes can be added to /app/data/custom, the config file is JSON at /app/data/.n8n/config, and the package writes cloudron-provided postgresql configuration to that file at launch.

Some stuff only works in Chrome. That's just an issue with the app. Something about they way they're handling web sockets means other browsers see "Connection lost" in the top right, which is where the Activation toggle should be. Most other things actually work fine, but that's necessary for executing workflows in-browser manually and activating them.

I packaged this one because it seems to have some popularity in asks, but it definitely deserves some due diligence before heading to production for anyone or the app store. It's also pre-1.0 so not sure how much is changing how fast, and the setup as is was a pretty delicate thing to get done. Maybe my concerns are overplayed, maybe not, but either way, there's something we can start to kick the tires on for this app now.

Gets a little technical about ruby and how discourse manages the plugins, but that all sort of goes hand-in-hand. Depending how the next day or two go, I'll see about doing something that we can use in order to keep the conversation moving and have a base to tackle some of those features from. Appreciate the context of your goals; I'll bear that in mind when the code starts flying