You’re correct — in my earlier post (Testing large file synchronization with Nextcloud AIO and NGINX Proxy), the setup runs Nextcloud AIO behind NGINX Proxy Manager on the root path (/). It does not demonstrate how to run AIO under a subpath like /nextcloud.
From my own tests and confirmation in the official documentation, Nextcloud AIO cannot be deployed in a subdirectory. Even if you try setting OVERWRITEWEBROOT=/nextcloud, the AIO setup container performs domain validation on the root path (/) only. This causes the setup to fail when served under a subpath.
This is explicitly mentioned in the official documentation:
GitHub README – “Can I run Nextcloud in a subdirectory on my domain?”
→ https://github.com/nextcloud/all-in-one?tab=readme-ov-file#can-i-run-nextcloud-in-a-subdirectory-on-my-domain
Answer from the official docs:
“This is not possible as the AIO interface needs to be reachable through the domain without any subpath. Using a subdomain likenextcloud.example.comworks fine though.”
Additionally, here are two community discussions confirming this limitation:
GitHub Discussion #839 – Domain validation fails behind reverse proxy with subpath- Nextcloud Forum – Nextcloud AIO in domain subfolder
So, to clarify:
My shared setup was focused on performance and large file sync behind a reverse proxy.
It was not meant to demonstrate AIO running under a path like /nextcloud — which is not supported by AIO.
If you must run Nextcloud under a subpath, you should use the standard Nextcloud installation instead of AIO.
For simplicity and full compatibility, the recommended approach is to use a dedicated subdomain, like nextcloud.example.com.
Note: This post was written with the help of an AI assistant as a writing aid only. The opinions, solutions, and technical recommendations are fully based on my personal experience.
More about how and why I use AI to write forum posts:
Is there limitations to installing Nextcloud via CT template on Proxmox - #4 by vawaver