The primary reason was to match the Docker Hub example as closely as possible.
8080:80 means that port 80 in the container is being forwarded to port 8080 on the host machine. If no other application is using port 80, then it’s okay to use 80:80. So why remap?
Let’s say you have two containers that use port 80 internally. Both can’t be forwarded to port 80 on the host machine. In this case, you need to remap at least one of those ports on to a different port on the host machine e.g. 8080:80 for one of the containers. Best practice is to avoid using low-order, well known ports on the host machine, which the host machine might want to utilise. Personally, I would remap both container ports to higher-order ports on the host e.g. 8080:80 and 8081:80.
I think what’s causing the confusion is not realising that there are actually two Caddy instances running, each with their own Caddyfile (at least that’s how I run it) - Caddy as a webserver to serve php files from the Nextcloud FPM instance, and Caddy running separately as a reverse proxy. The schematic in Case study: Variations in Caddyfile design for different Nextcloud builds will help you visualise what’s going on.
What is the impact of port remapping for Caddyfile on the reverse proxy?
If you were not remapping to a different host port in the compose file, your reverse proxy entry might be:
cloud.mydomain.com {
reverse_proxy http://192.168.1.205 # Port 80 implied
}
If you had remapped port 80 in the container to port 8080 on the host, your reverse proxy entry would instead look like:
cloud.mydomain.com {
reverse_proxy http://192.168.1.205:8080
}
If you’re going to run the apache version of the Nextcloud container, just be aware of additional redir rules for the reverse proxy entry. See section d of the case study for more info and well as this thread Dockerised Nextcloud+Apache web server behind a Caddy reverse proxy - #2 by jok