Reverse proxy letsencrypt docker and nextcloud-snap

Hey there,
I came across the letsencrypt reverse proxy docker and found it wonderfully easy to use. Now, on another server of line, I am running a nextcloud, installed as a snap, and would like to keep it that way. But, I wondered if anyone succeeded to use the reverse proxy docker to access the nextcloud under

I tried installing it, but cannot access my cloud. I changed the ports in the snap to 81 and 444, but cannot figure out how to change the settings in the nginx server to forward it to the snap. Any tips are gladly appreciated!

Have you had a chance to read our guide?

We have a section discussing nextcloud specifically. In your case, just ensure the build-in template has the ip for the $upstream_app rather than the name.

You may have issues since our templates are made to work with our nextcloud container, but our sample and that guide should get you started.

Thank you for your suggestions, they seem reasonable and almost work. I think I need to add a bit more information on my setup. I am running a Ubuntu 20.04 VPS Server with a dedicated ip address and my domain (let’s call it pointing to it.

What I want to do and why

It is always good to state the WHY first. So, I want to have 2 services (nextcloud and gitea) running on my server accessible through the internet without entering port numbers and with automatic letsencrypt renewable certificates. Currently, I already have nextcloud installed as a snap, docker installed as a snap, and gitea installed using docker-compose. My current setup is:

  • My nextcloud is accessible on https ://
  • My gitea instance is accessible on htps://
  • UFW blocks all ports except 22,80,81,443,444,3000

I really would like to keep my nextcloud running as a snap (for now at least), as for my usecase it works fine and I like the automatic updates.

I have separate letsencrypt certificates for my nextcloud and my gitea instances. The nextcloud snap already takes care of the renewal, but for gitea I have to do it manually (which is fine I know how to, but I want to change this). The idea now is that I don’t want to enter the port numbers and have the reverse proxy take care of the renewal of the letsencrypt certificates. So ideally:

  • My nextcloud is accessible on https :// (even though it is running on http port 81 and https port 444)
  • My gitea instance is accessible on https :// (even though it is running on port 3000)
  • the reverse proxy letsencrypt docker is taking care of the letsencrypt certificates and autorenewal

Steps I have taken so far

Let’s focus only on the reverse proxy and nextcloud, as gitea is a docker container and should work fine.
I have done the following so far:

  • Step 1: I disable UFW for debugging
  • Step 2: I installed the letsencrypt reverse proxy docker via docker-compose to get letsencrypt certificates for mydomainDOTcom, nextcloudDOTmydomainDOTcom, and gitDOTmydomainDOTcom.
  • Step 3: Now, I use the following nextcloud.subdomain.conf file:
    set $upstream_app;
    set $upstream_port 444;
    set $upstream_proto https;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

and also follow the suggestions to adapt my nextcloud config.php file.


With this setup, I am able to access my nextcloud on https :// without entering the port number (this is what I want). When I point my browser to https :// I get the landing page of the nginx reverse proxy (so it is working).


So far so good. BUT, If i now ENABLE UFW and block all ports except 80, 443, I am no longer able to access my nextcloud. The nginx reverse proxy is still accessibla on https :// So I think the problem I am facing is that I need to enter my internal ip address so the forwarding happens internally on my server. But I don’t know how to get this as localhost or does not work. The problem might be that I have both docker and nextcloud installed as snaps. Can they communicate with each other internally?

You need to set the upstream_app to the IP address of the system running the nextcloud snap. However, as I mentioned you will probably have much better luck by using our nextcloud container, but i am confident you can get this to work, it will just be more difficult. :slight_smile:
As for UFW, i was under the impression it caused issues with docker, I can’t find the source right now though. It sounds like perhaps ufw is breaking hairpin nat? you should not be using or localhost in any situation though, you should be using the lan ip.

I’m not sure what this guy is on about, but obviously he took an easy to use config and just smashed it all together which obviously doesnt follow our standard and just makes things more complex.

Why not? I was thinking that by default the nextcloud snap is listening on localhost or and if the Reverse proxy is listemimgto the external ip and can them forward to localhost that should work, or what am I mussing?

I will definitely do this on another server. I am curious though, what is the difference between your guys’ nextcloud container and the official one from ?

Because localhost refers to localhost inside the container where there is no nextcloud

No idea. They are not related to each other at all