I'm reworking this now that 6 is out and proxyAuth is an option. Currently got the latest version building and running on the latest node. Waiting for some details on how to do proxyAuth configuration to not break webhooks (rather important for this one!) and then I'll need to get to fixing up the websockets, but overall is looking okay. Switching from file-based to env-based configuration only because it seems better supported by the docs as well.
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!
I had a breakthrough with the dumb websockets issue. Hooray! This one should be ready shortly. I know it's been highly requested and hotly anticipated (for me as well) so it's my top packaging to finish. At this point, after a few other tweaks, I'm fairly sure I've got this working. I'll do some final testing tonight, but I expect that I should have an initial build together by this weekend.
Z-Push EAS interface for IMAP/CardDav/CalDAV/LDAP/Kopano/MailDir/SQL/more
https://z-push.org
I would like to be able to configure the autoexpunge option for certain special folders globally for all mailboxes, to allow the mail server to clean up after users who don't purge their Junk or Trash folders periodically. Ideally, this could be optionally configurable for any of the predefined folders so that a clear retention policy, to whatever degree the administrator desires, can be applied to all mailboxes.
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.
Not only is this an awesome find and great-looking app (wish I knew of this in May), but something I have a distinct use for. As such, I've begun an initial packaging effort.
I've extracted the following from one of my projects: https://gist.github.com/jimcavoli/b390565eb98f62faae821c83c8e87100
It has some added substitution for using secrets for all configurable values (I hard-coded a couple of them in the actual project), but is otherwise exactly what I use. It has a built-in cache registry that tries to minimize the build time, some simplistic retry logic, and as written is triggered when a new release is published on the repo. I've had a pretty good experience using it, so figured it might be handy for others, in case you've got some fully-custom app you're deploying from a private registry. The only built-in assumption is that you use the Dockerfile.cloudron naming scheme, but you could edit that as well if you like.
Love the conversation this has kicked off, and I think there's a few good things to consider here:
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.
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?
At least for the hotmail/outlook addresses, you can check out SNDS - https://sendersupport.olc.protection.outlook.com/snds/index.aspx - to verify status and/or request unblocking if you're currently being blocked.
@jdaviescoates Loomio has priority over Zammad to me. I've been made unfortunately busy by other forces in the world lately, but trying to decipher where past Jim left off, it does appear Loomio is ready other than perhaps being re-updated to latest and whatnot, but mostly is held up by the Cloudron team from the app store right now.
Hopefully I can get back to poking at Zammad shortly
@jdaviescoates Yes, "not alpha" is very much the thing I was talking about 
Certainly nothing wrong with getting it packaged unstable and so on while it's still under more active development, but my experience with how much of the critical components of an app that can break the building of a package are much more likely in alpha-land than in beta-land at least. YMMV, and words are made up with different meanings to different teams/people, especially in this one, but that's where my brain's at presently.
@girish Yeah, what @jdaviescoates posted is the thing - it's largely not documented all that well from the technical setup perspective. I just sort of...figured it out? There's not that many components and it's a pretty standard python app. Because it's not well-documented on the project's part insofar as running is concerned, that's a large part of why I made the readme and put all the notes in that I did.
You should see if they'd take a patch upstream for this! Nice work
@atrilahiji That sounds like a good approach; we do similar things in other apps for unnecessarily obtuse LDAP setups, for example.
@girish I see what you're saying. Perhaps an ability to log into one's Cloudron.io account and post via a subcommand cloudron publish with the CLI tool would be able to send a payload of the current docker repository URL and manifest to an endpoint, which could then be sanity-checked that it doesn't require authentication, and added into the app store updates/listings (optionally with a review step), marked as community-supported. The review step is probably fairly important to see that there's a support email and such listed, but we could get additional forum topics and a process for contributing to the documentation as well set up in time.
Looking the other way, there's really no reason that the Manifest can't itself specify the image repository URL, right? Then it would just be a matter of POSTing that manifest to an endpoint for the proper delivery to be possible downstream. Opens up a lot of options the more that I think about it. Sort of an elegant way to do continuous delivery automation for any custom apps as well.
Maybe it's because of the brilliant person who posted the request, but it strikes me that mutual TLS optionally and globally on the frontside reverse proxy is a more elegant way to achieve a similar result: https://forum.cloudron.io/topic/3826/support-optional-global-https-mutual-tls-certificate-based-authentication
This is on my radar for packaging, though at the moment I'm holding off until the codebase is more stable, unless consensus build that packaging sooner is a good idea