That particular image is designed to be used behind a co-hosted reverse proxy that terminates TLS. It can, however, be adjusted to support HTTPS termination as well with some extra work.
It’s a Debian based Apache installation so standard stuff basically applies. You’d have to customize the Dockerfile to enable the ssl module/config. Sort of like this.
To my understanding, my image is the offical default image from Nextcloud which is on the version latest. Why in the name of the living hell doesn’t it support TLS encryption. This is one of the basic things since over ten years. And the sentence “Its designed to run behind a reverse proxy” isn’t an excuse for the missing encryption.
Since as you can see in my case. It’s not encrypted, and it has a huge attack vector if you look at the lateral movement.
I know you are a user and not the Nextcloud team, so please don’t take it in the wrong way. I don’t want to attack you or hold your responsible for this.
That image is the community maintained micro-services image. It’s typically deployed in environments where HTTPS is explicitly not desired at that point in the infrastructure. HTTPS is handled by the front-end infrastructure, not the app server/containers. It’s also not intended to be a turnkey install method, but one used as a base for those building the various elements of their own custom Nextcloud stack.
(The FPM variant is also often used, in which case HTTPS isn’t even in the picture as far as the app containers are concerned, but that’s a tangent…)
The “Official” in that image’s description refers to Docker’s Official Images program. It’s not Nextcloud’s GmbH’s official installation mechanism, which is the AIO image. That deployment stack (which is also container based), does include HTTPS.
From the README at the top:
This image is maintained by community volunteers and designed for expert use. For quick and easy deployment that supports the full set of Nextcloud Hub features, use the Nextcloud All-in-One docker container maintained by Nextcloud GmbH.
