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.

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.

Z-Push EAS interface for IMAP/CardDav/CalDAV/LDAP/Kopano/MailDir/SQL/more
https://z-push.org

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.

Given the split of box vs app concerns, and the new addition of being able to separate the mail server from the my subdomain, it would be a great added feature to have the option to check a box for setting up proxied records when using the Cloudflare DNS provider.

Previous discussion: https://forum.cloudron.io/topic/2806/is-the-cloudflare-auto-dns-setup-secure-using-dns-only-as-opposed-to-proxied/

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 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.

@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

You can edit/remove the information in $HOME/.cloudron.json that deals with that folder on your machine to correct the repository info or just delete the block to make the CLI re-prompt you on the next run.