@girish Excellent, as always. Works!

@danielreyes61 If you want to use nginx directly, you should make it do https proxying and not http. nginxproxymanager seems to have generated something like this: # ------------------------------------------------------------ # paste.cloudron.space # ------------------------------------------------------------ server { set $forward_scheme https; set $server "45.63.93.50"; set $port 443; listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2; server_name paste.cloudron.space; # Let's Encrypt SSL include conf.d/include/letsencrypt-acme-challenge.conf; include conf.d/include/ssl-ciphers.conf; ssl_certificate /etc/letsencrypt/live/npm-2/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/npm-2/privkey.pem; access_log /data/logs/proxy-host-2_access.log proxy; error_log /data/logs/proxy-host-2_error.log warn; location / { # Proxy! include conf.d/include/proxy.conf; } # Custom include /data/nginx/custom/server_proxy[.]conf; } And proxy.conf is like this: set $upstream $forward_scheme://$server:$port$request_uri; add_header X-Served-By $host; proxy_set_header Host $host; proxy_set_header X-Forwarded-Scheme $scheme; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_pass $upstream; Just pasting them to give you some ideas.

@silvermaw no worries, happens to the best

@nebulon thanks, i did get this figured out with zulip's docs on reverse proxying and using certbot on the cloudron host again but I know I'm playing with fire. I get why this isn't a common use case, I can't imagine a lot of people host at home

@khadanja Is your idea to forward all queries ? The example config you pasted will only forward DNS queries for cloudron.lan (sic). You need the config in https://forum.cloudron.io/topic/5756/custom-dns-server-in-local-network/2 to forward all queries to your router.

@savity I can't reproduce this. Do you see any error on the minio side?

@nebulon I updated the server to v7.0.1 and then rebooted, now when I'm login through the incognito tab in chrome browser, user management is working fine, maybe this is due to cacheing...

@ascua If the new instance is in your house then you need to port-forward (or if your router/modem support - DMZ (AKA 1:1 NAT) ) the server.

@fortytwo said in How to delete unused docker images ?: Scaleway S3 Object Storage with 75GB free Is this for your backup? Cloudron does not backup images (and code), just your data. From your screenshot, it's only going to take 1.13G (nextcloud) + 6.5M (bitwarden) + 520K (box) + 212K (email). So, it's way less than 2GB per backup. If you store like 30 full backups, it's still under your object storage. We use what is called immutable infrastructure for this if you want to learn more.

@nebulon Thanks. I have solved this issue. The initial python version is 3.8, after switching to Python 2.7 the issue was solved. Reference this link: https://linuxconfig.org/ubuntu-20-04-python-version-switch-manager

@scooke yes, you can mix between Cloudron's automation and manual DNS changes. In fact, that's the normal and only mode of operation. The automation is only adding and removing things that you would have to do normally outside Cloudron. For example, when you install an app, you have to setup A records. When you uninstall an app, you remove the A records. This is all the automation does. If you try to install an app in a location and there is already a DNS entry in your DNS provider, Cloudron will inform you of the same and let you 'overwrite' it or cancel the app installation. Same goes for email stuff. It sets up things like DKIM/SPF records automatically. These are updated carefully to not collide with existing entries. The MX record is only touch if you enable incoming Cloudron Email. Even in that case, there is a checkbox to not update DNS.

@eddowding If you like you can patch the file in /home/yellowtent/box/src/mail.js and systemctl restart box.

@fbartels Thanks, it working and solved my issue. @girish The issue was that I have not set the provider to No-op, while without this step it was unable to change the location of any apps. Thank you both for the support.

@ntnsndr You talking about Github Pages official, or the Cloudron app?

@molinaire did you get this sorted out? If not, I think maybe it's best sorted out by writing to us at support@cloudron.io

@marcusquinn Actually, SIM Swapping is pretty common. I would not suggest having a phone number as a single-point-of-failure for anything remotely critical.

@aziz So, certificate for *.devz.cloud is already there, so if you install apps on subdomain it will work. Cert for devz.cloud (it is not a subdomain, so we have to get a separate cert from the wildcard cert) is getting rate limited. You can just wait for 2-3 days to install an app on the bare domain and that should work. You should be able to install apps in subdomains in the meantime.

@girish thank you very much, I will do that

@nebulon said in Unable to install 2nd app: @khadanja from your forum account, I was able to trace it down and for some reason our state showed 2 installed apps. This sometimes happens, since we don't closely track our users. I have reset the state now, so can you try again? That worked. Thanks @nebulon