Custom /etc/nginx/applications/ entry allowed?

[annaooo]

If I would like to run another web service on the same host running cloudron would it be okay to add a custom nginx.conf to the /etc/nginx/applications/ directory of the root OS/server system? My objective is to have a myservice.mydomain.com running not-in a docker but sitting beside the other cloudron specific services such as my.mydomain.com and chat.mydomain.com, etc.

I'm sorry if this is covered somewhere else, I could not find details on best practice for this question.

[nebulon]

While this is technically possible, Cloudron does not support installing anything on the side. Since we cannot test all kinds of variations in such a case, your setup will break eventually after an update. Especially the reverse proxy configs are auto-generated and will cause issues.

The supported way to install something which is not yet part of the app library is to build your own package https://docs.cloudron.io/custom-apps/tutorial/

[girish]

Writing a custom app is the way to go since nginx is managed by Cloudron. If you need any nginx specific special configuration, let us know and we are happy to incorporate it into the cloudron platform itself.

[robi]

I think there is a good use case for exposing a custom URL mapping via Nginx that doesn't necessarily go to a container on the local system.

This has use cases for a single (sub)domain providing proxy and load balancing services, as well as cluster management down the road.

As of now, the default nginx.conf loads all .conf files from applications/ directory.

Unless there is anything in the code that wipes out all conf files instead of only individual ones, adding a custom on there for a custom use case won't cause problems for other apps and won't be overwritten on upgrades.

If you want to feel safer, keep the custom .conf elsewhere and use a symlink from the applications/ directory.

[adhodgson]

I have been doing this for around 2 years as I run a Mailman instance alongside Cloudron and it works very well, however on occasions (upgrades) I find the /etc/nginx/applications directory is oblitterated and I have to copy my custom .conf file again.

Is there any chance we could get an include setup for a directory like sites-enabled where Cloudron doesn't touch files in that directory? I'm also interested if we can use the reverse proxy configuration tool in Cloudron itself to provide this capability but suspect it won't allow me to set up the custom features in Nginx I want.

I realise this is only supported on a best-guess effort but it would be really good if we could have a "you're on your own" directory where we know it won't wipe out the contents where we can add our own custom Nginx configuration.

Andrew.

[girish]

@adhodgson so, mailmain runs in a separate container and you have a custom nginx config as well? Who updates the certificates of mailmain? This might be outside the scope of what we want to write code for and support.

I'm also interested if we can use the reverse proxy configuration tool in Cloudron itself to provide this capability but suspect it won't allow me to set up the custom features in Nginx I want.

We can support this though . Can you tell us what nginx feature is missing for the reverse proxy ? Note that the proxy is just blindly forwarding. Also, you can set up another nginx (on another server with mailmain) and configure the nginx there however you want.

[adhodgson]

I'm not running Mailman in another container as I want Cloudron to manage the Docker instance. Its running on the OS through a Python venv. Cert renewal is done via Certbot which just touches the Nginx configuration for Mailman and nothing else. Regarding the reverse proxy in Cloudron, my Nginx config doesn't just do reverse proxy it serves up static images so I don't think this will work, also the destination for the proxy is on localhost so this may be an issue as well. I did think about running something like Surfer for serving up the images, however with the exception of Cloudron moving the conf file out of the way on occasional (not all) upgrades, this setup has been working solidly for 2 years.

[nebulon]

Given that our perspective is to be able to change anything on the system with a Cloudron update as we expect this environment to be fully under our control to minimize side-effects, which are very hard to debug, I would argue that making a mailman app package is the main way forward for this. This removes a lot of things out of the equation. Was there a specific reason why you didn't go that route initially?