The CLI has indeed no way to edit domains. What you did is the correct approach - make the dashboard available via the browser and then edit from the Domains view. (As for the CLI warnings, looks like we have to replace request module with superagent. Sigh, we actually used to use superagent before...)

@nebulon Oh sorry, yes that was a command I found online which I thought was neat, haha. It just combines processes with the same name which I think is useful at times, so it's basically a summary of all MySQL services, all Node servers, etc. Thanks for the assistance by the way - I know I'm deviating a bit from the original concern so that's okay - we can probably mark this resolved now since limiting the backup task memory was sufficient for now. It just has me wondering about memory usage overall on my system now. haha. I'll maybe file a new post if I need a bit more insight later to memory stuff. Thanks again for the help! For reference, here is the current status of those commands: ubuntu@my:~$ free -h total used free shared buff/cache available Mem: 14Gi 5.3Gi 797Mi 925Mi 8.2Gi 7.8Gi Swap: 4.0Gi 3.0Mi 4.0Gi (there was 2.2 GB free when I woke up this morning but little left now because it just completed a backup, so hoping that memory gets put back - but wondering if maybe this is why it's going to low in "free" memory (even though plenty left in "available" memory). ubuntu@my:~$ ps axo rss,comm,pid | awk '{ proc_list[$2] += $1; } END \ > { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 20 | sort -rn | awk '{$1/=1024;printf "%.0fMB\t",$1}{print $2}' 5793MB /usr/sbin/apach 1958MB node 1070MB ruby2.7 903MB mysqld 716MB supervisord 476MB containerd-shim 327MB spamd 236MB redis-server 179MB postmaster 170MB nginx 139MB mongod 133MB dockerd 121MB uwsgi 81MB imap 65MB systemd-udevd 61MB containerd 59MB imap-login 44MB radicale 39MB carbon-cache 36MB snapd Definitely a lot more Apache-related memory usage (which I guess is just all the containers running Apache like all the WordPress sites for example and makes sense as most of the apps running are WordPress apps in Cloudron). MySQL memory also almost doubled, but since so many are WordPress sites and if they're getting busier I suspect that means more MySQL usage which means MySQL will use more memory, so I think that all checks out still. One thing I'm not sure I fully understand yet (but maybe this is a bit outside the scope of Cloudron) is the memory part... so last night I had 4.0 GB used and 4.8 GB in the free column, now it's 5.3 GB used but the free memory dropped by about 4 GB to 797 MB from 4.8 GB last night. That's where I get a bit confused and unsure why that goes so low when the memory usage only went up a bit. I believe it basically becomes "reserved" and then used in the "buff/cache" and when no longer used it's still reserved so becomes "available", is that right do you think?

Sorry, this can be closed I guess. Turns out it was because of how I edited /etc/netplan/50-cloud-init.yaml on my server where I accidentally added both IPs when it should have only contained the failover IP. Now it's working again. Was my own mistake.

@alexsunny123 ok there are quite a few variables in the mix here it seems. For a start, can you connect to the Cloudron setup view using the public IP address from your ISP on port 80 and 443? To rule out some other maybe interfering parts, disable the Cloudflare proxying. Since you mentioned email, on a residential connection you will most likely require a mail relay to work properly, anyways port 25 will most likely be blocked by your ISP. Cloudron as mail relay support for various providers though. Lastly for Cloudron it doesn't really matter if bare-metal or VM, so there are no special docs about this. You should be fine as long as you have vanilla Ubuntu 20.04 server installed.

@girish I think that might be an improvement worth considering, no? Making the necessary changes would (I think)... Make it clear to monitoring tools and manual checks by users which processes being run are local to the host and which are from containers, particularly useful when multiple instances of a service are being run both on the host and container. Follow what appears to be "best practices" when running containers. Improve security in certain situations. Admittedly these may be minor and not worth the overhead, but now that I'm aware of the behaviour, I'm a bit irked by it as it currently prevents me from easily identifying which services are container-run and which are local to the host, as well as making it confusing to which user is actually running the process listed.

@eddowding ah, great you managed to figure this out. indeed, cloudflare can only proxy http(s) and not email.

To close this, turned out that "libpython3.8" was missing on my newly upgraded 20.04 Hetzner system...therefore I was getting the message "dependency problems prevent configuration of collectd"

@girish Thank you for those commands. I think I'll just use the cloudron push after I run cloudron install on my image server. Also, not sure if there is a specific way to go about this but I could strip this down a bit to have a base install for the app if it's of use to the Cloudron community. I'm sure it would have to be polished by the devs but it is an install for Timetrex CE which is a timeclock software that our company uses.

@vladimir-d This is already fixed in the coming release - https://git.cloudron.io/cloudron/box/-/commit/6d044bfbf384b8ae98f1beac0f9d1c50005e8d34 . For now, you can ignore the warning, it's harmless.

@marcusquinn I understand your time constraints, unfortunately I am not able to trigger the behavior you are describing, so this is hard to find a fix for it. Maybe if you have some time, can you describe how one of those apps was setup initially before you adjusted the access control from the groups panel?

@nebulon Yeah fair enough. I figured it was a decision based on app compatability. Thankfully I only had 40 apps to go through

My understanding is that mint is primarily targeting a Desktop environment.

Sorry, this was a duplicate post, because the first didn't go through for a while. Please ignore, and answer the question in the other forum.

@girish that worked. Thanks

Thank you @d19dotca @nebulon @robi for your replies. I use adguard on the same server which allows for DNS rewrites. I guess I was trying to achieve what Resilio sync does (e.g. connect to peers using LAN when in LAN). In this case, I wanted to try by pointing the DNS name of nextcloud installation to local server IP:port. I am not sure if this will be possible (probably not right? unless I change the server itself in my nextcloud client?). If it's not possible, it is OK I guess.

Success! Re-installed Ubuntu, added nothing, and everything worked as advertised!

@ianhyzy for nginx configs? No, they're on the Cloudron host.

@girish I don't know if it was installed before the upgrade, but it wasn't enabled, because unbound managed to run without problem I'm not sure how it got there. It was supposed to be a clean Ubuntu 16.04. The only things I installed manually besides cloudron are basically ZSH and screen. In any case, I marked this as solved, thanks !

I finally managed to get to the bottom of this. There was a bug in the postgresql addon backup logic where connections were not closed properly. This resulted in periodic backups keeping lots of connections open. This is fixed in 6.3.