Docker Community Forums

Share and learn in the Docker community.

Steps are missing from nginx-proxy with letsencrypt section of examples README

The documentation at Docker Hub lists some examples of setting up containers/projects. The last step in the examples are:

  • To start the container type: docker run -d -p 8080:80 nextcloud. Now you can access Nextcloud at localhost:8080 from your host system
  • Then run docker-compose up -d , now you can access Nextcloud at localhost:8080 from your host system.

However, in the “HTTPS - SSL encryption” section of docker hub link above, it references an example that is missing that last step arguably when further clarification is needed the most. It references docker/README.md at master · nextcloud/docker · GitHub . That example ends with step 4 "start next cloud with docker-compose up -d". The user is left not knowing:

  • If the web app can be accessed at that point or if the lets-encrypt exchange needs happen as a prerequisite
  • If the web app can be accessed at localhost or only via the newly configured, publicly accessible domain name

My specific case happens to be with nextcloud but I feel the underlaying issue is general.

After running docker-compose up -d, things appear to be in order however I get a 503 (Service Temporarily Unavailable) when I access the localhost URL. The site’s cert is still the self-signed letsencrypt-nginx-proxy-companion default/fallback cert. It remains even after opening the docker stack up to the www and successfully doing the cert signing exchange with the Let’s Encrypt online CA service. Accessing the site via the newly configured domain has browsers complaining of improper redirection. The container’s ports appear to be in order as far as I know:

NAMES                               PORTS
nextcloud_letsencrypt-companion_1
nextcloud_app_1                     80/tcp
nextcloud_cron_1                    80/tcp
nextcloud_db_1                      3306/tcp
nextcloud_redis_1                   6379/tcp
nextcloud_proxy_1                   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp

None of the container’s logs call out any obvious errors. I have a lot of research and troubleshooting ahead of me but feel overwhelmed not knowing the expected behavior at this point.