I was trying to install caddy in a docker under Linux Mint, a custom version for support for DynU DNS . For that I’ve downloaded the already compiled version from here , and put it in a dir along with caddy file and a compose.yml. Please consider that I’m a totally newbie of Linux/docker world.
2. Error messages and/or full log output:
~/Downloads/Caddy_Install$ sudo docker compose up
[+] Building 0.0s (0/0) docker:default
unable to prepare context: path "/home/USER/Downloads/Caddy_Install/Dockerfile" not found
USER@MACHINE:~/Downloads/Caddy_Install$ sudo docker compose up
[+] Building 3.0s (1/1) FINISHED docker:default
=> [caddy internal] load build definition from Dockerfile 0.3s
=> => transferring dockerfile: 42.15MB 0.3s
failed to receive status: rpc error: code = Unavailable desc = error reading from server: connection error: COMPRESSION_ERROR
3. Caddy version:
2.9.1
4. How I installed and ran Caddy:
sudo docker compose up -d
I precise that in the same dir I put the compose.yml and the caddyfile. I’ve renamed the custom image to “Dockerfile” (Otherwise the docker compose command won’t start).
Rename the custom Caddy to caddy and move it where you keep all your Caddy stuff (I presume it’s in /srv/caddy) and then mount it to usr/bin/caddy. You also should specify the Caddy image. Your compose.yaml file would look like this:
Unfortunately no joy! … I’ll tell you what I’ve done:
I’ve re-downloaded the custom image (for Dynu support from here) and got a file named “caddy_linux_amd64_custom”, around 42MB, and I’ve copied it to my srv/caddy dir.
Renamed it to “caddy”
inside /srv/caddy I’ve created data and site dirs and then I’ve added Caddyfile, a very basic one.
I’ve created a compose.yml file as per your instruction:
and then I’ve got the caddy image, Caddyfile and compose file together in the same /srv/caddy dir. Then I’ve typed: sudo docker images
does NOT give me caddy among images on my local repo, which is my first concern…
the second one is that I’ven’t understood correctly what you meant by:
and then mount it to usr/bin/caddy. You also should specify the Caddy image.
because the renamed caddy file doesn’t mount with the command: sudo mount ./caddy /usr/bin/caddy
I’ve tried to create a caddy dir inside usr/bin but, anyway, it’s useless because this what returned:
$ sudo mount caddy /usr/bin/caddy
mount: /usr/bin/caddy: /usr/bin/caddy is not a block device.
dmesg(1) may have more information after failed mount system call.
Anyway I’ve tried to go on and inside the /srv/caddy dir i’ve done: sudo docker compose up -d
but I’ve been returned with:
[+] Running 0/1
? caddy Pulling 0.0s
invalid reference format
and then I’ve stuck another time … any idea?
Have a good day!
The files from the download website are executable binaries, not container images.
You need to run the binary you downloaded inside a container.
You can use the official Caddy container (it’s properly set up for usage) and simply mount the Caddy binary you downloaded on top of the stock binary already shipped in the container - this is what TheRettom is getting at.
The image should probably be caddy rather than ./caddy.
So, let’s see just if I’m understanding the process correctly: in Docker’s parlance an image is a complete piece of software needed to run a service or a function. A container is an instance of that image.
What I’ve downloaded is a binary that doesn’t work per se but it needs all the standard Caddy’s image to work with. That’s why, after copying the custom binaries, I had to:
sudo docker pull caddy
In this way I’ve created the entire custom image that can be instantiated correctly.
Am I vaguely right?
That’s said, I’ve corrected the compose file as you said and finally I got:
sudo docker compose up -d
[+] Running 1/1
? Container caddy Started
Thanks to all!
I hopefully start the correct image and I will try the TLS challenge soon to verify it.
So, let’s see just if I’m understanding the process correctly: in Docker’s parlance an image is a complete piece of software needed to run a service or a function. A container is an instance of that image.
That is correct.
What I’ve downloaded is a binary that doesn’t work per se but it needs all the standard Caddy’s image to work with. That’s why, after copying the custom binaries, I had to: sudo docker pull caddy
Essentially. Manually pulling the image was an easy way to figure out where the problem was lying, in this case, an unintended Dockerfile.
If you need help with getting your Caddyfile working properly, we’d be happy to help! Glad you got this working, but I apologize it took so long.
Thanks so much! and don’t apologise, your help has been fundamental because I’m totally a newbie!
and yes, I need to build a proper Caddyfile. My idea is to public some services from this little (N100 machine) Linux machine:
A NextCloud webserser in docker (I’d like to use the one with CGI functionalities and use Caddy as Web server, if possible). This would act mainly as personal cloud.
And FTP server, always inside a docker.
Expose in a secure way Home Assistant and some related services so that I can control some aspects of my domestics when I’m out.
As there will be many services and I’m using DYNU as DDNS service aI guess I should use this:
{
acme_dns dynu mydynu_token
}
This way I’d get a global DNS Challenge (and answer) for all the subdomains I will use. Am I correct?
Now, for starting in the simplest possible way and verify that Caddy is woking as intended I guess I should create this basic Caddyfile:
all my nice considerations failed abruptly … this is the caddy log file when I’ve tried to access from the outside with the CADDYFILE written before:
sudo docker logs -n 20 caddy
{"level":"info","ts":1740497855.6535437,"logger":"admin","msg":"stopped previous server","address":"localhost:2019"}
{"level":"info","ts":1740497855.6535535,"msg":"shutdown complete","signal":"SIGTERM","exit_code":0}
{"level":"info","ts":1740501455.310405,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1740501455.3172395,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"warn","ts":1740501455.3172724,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1740501455.3197756,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//[::1]:2019","//127.0.0.1:2019","//localhost:2019"]}
{"level":"info","ts":1740501455.3208141,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1740501455.320849,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1740501455.3216336,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0001fa500"}
{"level":"info","ts":1740501455.3224683,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1740501455.322979,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
{"level":"info","ts":1740501455.3238833,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"warn","ts":1740501455.324899,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"warn","ts":1740501455.324926,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"info","ts":1740501455.3249326,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1740501455.32494,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["house.mydomain.org"]}
{"level":"info","ts":1740501455.3302774,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1740501455.330305,"msg":"serving initial configuration"}
{"level":"info","ts":1740501455.3321514,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"94eff049-1a60-404e-b3ff-e4a5dff347c5","try_again":1740587855.3321476,"try_again_in":86399.999999396}
{"level":"info","ts":1740501455.3322496,"logger":"tls","msg":"finished cleaning storage units"}
Is your firewall open to ports 80 and 443? Assuming myhouse.dynu.org is actually your domain, I’m getting the IP 216.245.197.41. Make sure your public IP is set as the A record IP for the domain.
You can use WireGuard for this. It allows you to connect to your home network while outside your home network. Since all the other services are also in Docker containers, that means you’ll either need WireGuard on the host machine, or in the container, use the host network mode. If you want to still get the containerized security benefits with networking, then you need to set up a VLAN.
I have two routers in cascade. The primary one is working with a 4G SIM (probably on a NAT-ted network), because I’m in a temporary house, waiting for my new apartment to be ready. On this I’ve created a port -forwarding rule for HTTP and HTTPS ports.
Then I have a second router - a Fritz!Box7590AX - which has its WAN port connected to the LAN port of the primary router (on address: 192.168.1.x).Here I have put my Dynu’s credentials in its DynDNS section and I’ve created another forwarding rule for HTTP and HTTPS ports that points to my Linux’s NUC, where Caddy is.
so from the Dynu’s DDNS services, everything seems right to me.
I’ve restarted the Caddy docker and now from the logs I have:
sudo docker logs -n 20 caddy
{"level":"info","ts":1740522260.8760927,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1740522260.8811111,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"warn","ts":1740522260.881148,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1740522260.8833144,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
{"level":"info","ts":1740522260.8840659,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1740522260.884085,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1740522260.8844056,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00015e380"}
{"level":"info","ts":1740522260.8862386,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1740522260.8899324,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"warn","ts":1740522260.8902037,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"warn","ts":1740522260.890304,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"info","ts":1740522260.8903913,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1740522260.89043,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["tilde.mywire.org"]}
{"level":"info","ts":1740522260.8909538,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"94eff049-1a60-404e-b3ff-e4a5dff347c5","try_again":1740608660.890951,"try_again_in":86399.99999934}
{"level":"info","ts":1740522260.8913982,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1740522260.895895,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1740522260.8959239,"msg":"serving initial configuration"}
{"level":"info","ts":1740522261.6694295,"msg":"got renewal info","names":["tilde.mywire.org"],"window_start":1745592881,"window_end":1745765681,"selected_time":1745733394,"recheck_after":1740543861.6694102,"explanation_url":""}
{"level":"info","ts":1740522261.671178,"logger":"tls","msg":"updated ACME renewal information","identifiers":["tilde.mywire.org"],"cert_hash":"65b79389f920631282f551acd6aaa5a24a70149a51586cde26e6f5ac2b8d0a10","ari_unique_id":"nytfzzwhT50Et-0rLMTGcIvS1w0.BP_0J1wTMt2wc3cvJuWS4zOt","cert_expiry":1748270111,"selected_time":1745603433,"next_update":1740543861.6694102,"explanation_url":""}
which I really not able to understand…
But I have fear that Dynu services cannot reach correctly the second router to be able to initialise the DynDNS functions on my 2nd router… just a thought.
I will give it a look, thanks. But the idea of having many subdomains directly reachable over https is really more intriguing to me. That’s why I’m trying to have Caddy get to work properly.
One question: which is the relation between LetEncrypt’s certificates and Dynu’s DDNS services?
I’ve noticed this:
cd /srv/caddy/data/caddy/certificates
root$: /srv/caddy/data/caddy/certificates#
ls
acme-v02.api.letsencrypt.org-directory
And I don’t get why there are certificates from letsencrypt’s in that dir, I’ve supposed that Dynu uses its own certificates…
Where is this forwarding to? It’s forwarding to the Fritz!Box, correct? You should forward ports 80 and 443 from Router 1 to Router 2, then configure the port forwarding on Router 2 to the NUC. Ensure you have static IPs set for Router 2 and the NUC so that the DHCP doesn’t change them on you and screw it all up.
{"level":"warn","ts":1740522260.881148,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
This is just saying that it’s not exactly the way Caddy expects the Caddyfile to be. Generally it’s not an issue from my experience, but it should be corrected anyway. Assuming your Caddyfile is still not set as read-only in the compose.yaml file, you just need to execute this in Docker:
docker exec -it caddy caddy fmt --overwrite
{"level":"warn","ts":1740522260.8902037,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"warn","ts":1740522260.890304,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
This is indicating that Caddy is not listening on port 80. If you want HTTP → HTTPS, then this needs to be enabled. It should be, because it is listed as an exposed port in your compose.yaml. Ensure the port forwarding is done correctly, the firewall on the NUC isn’t blocking 80, and you do indeed have Caddy listening on 80. Looking at all your containers with the command below, you should see something like 0.0.0.0:80/tcp->80/tcp.
docker ps
Caddy will automatically enable HTTPS, presuming your Caddyfile is correctly configured. The thing is, you can have all services point internally except WireGuard, so that only WireGuard is exposed publicly. It’s what I do, with the exception of my TeamSpeak server. It’s an option, but you could just have the A records for your service subdomains as your public IP.
I don’t know if Dynu does SSL certificates without additional configuration, or if you have to pay for the option. Either way, you can set Caddy to generate certificates or use the certificates made by Dynu.
Yes, correct. But tomorrow I will receive from Amazon an USB stick that works as 4G LTE modem and I will insert it in Fritz!Box and, If everything works as expected, I will put the router 1 off, so that I will have the Fritz!Box directly connected to the mobile network. I’m convinced this has been the main culprit so far: router 1 and router 2 don’t work along well at the moment.
I’ve tried but this is what I get:
/srv/caddy$ sudo docker exec -it caddy caddy fmt --overwrite
Error: reading input file: open Caddyfile: no such file or directory
exit status 1
but the Caddyfile file is there indeed and this is its properties:
/srv/caddy$ ls -l Caddyfile
-rw-r--r-- 1 root root 174 Feb 25 16:26 Caddyfile
so, if I’m right, it’s read&write for root and read only for all the others. Should I modify its properties and re-trying the automatic formatting and corrections?
ok, this is what I get:
/srv/caddy$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3eb8b8906ef0 caddy "caddy run --config ?" 5 days ago Up 9 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:443->443/udp, [::]:443->443/udp, 2019/tcp caddy
5d444312c827 eclipse-mosquitto "/docker-entrypoint.?" 13 days ago Up 3 hours 0.0.0.0:1883->1883/tcp, [::]:1883->1883/tcp mosquitto
de2eb67ae330 ghcr.io/home-assistant/home-assistant:stable "/init" 2 weeks ago Up 3 hours (healthy) home-assistant
b9bf416ee7ca portainer/portainer-ce:2.21.5 "/portainer" 3 weeks ago Up 3 hours 0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp, 0.0.0.0:9443->9443/tcp, [::]:9443->9443/tcp, 9000/tcp portainer
so it seems to me that Caddy is working correctly. Am I correct?
This is intriguing to me and in fact I’m beginning to read something about WireGuard. The main point here is that - for sake of simplicity - I’d like to reach this little server NUC from outside directly with a secured URL.
I.e.: https://cloud.mydomain.org should be my NextCloud server where I can upload stuff from my devices when I travel. Ditto for FTP. Indeed I’d love to have a VPN tunnelling as well, but just to secure way to connect to my house.
For example I have an account with ZeroTier at the moment but it’s more elaborated to use it and less practical.
At the moment I’m still evaluating and I have a free Dynu account. I will have to choose between Dynu and Cloudflare but, in the end, I’d love to buy a domain and get an SSL certificate for that domain.
Yeah, I haven’t quite figured out if that’s an expected response for a Caddy container environment or not. You’ll need to append with --config /etc/caddy/Caddyfile.
Yeah, Docker’s daemon runs as root unless you explicitly configure rootless Docker. So your files will be owned and controlled by root. I just switched to Podman, which is essentially the same to configure, since it runs daemonless and rootless. Much more secure that way.
Yes. So the "HTTP/2 skipped because it requires TLS" error is odd.
WireGuard is probably the safest and simple enough way to do it. Is it necessary for your likely threat profile? Probably not, but who doesn’t love learning new things?
Not related, but I recently switched away from Nextcloud because its performance is generally bad, the service has gotten bloated over the years, and, in my experience and opinion, it’s quite buggy. Nextcloud is awesome for what it’s supposed to do, and it is awesome when it does it right. For lots of people, it works fine, but I’m quite disappointed with it after using it for at least 6 months. I’ve switched to other services for that reason.
If you’re not picky about a TLD (top-level domain, e.g. .com, .net, .home), you can get some insanely cheap ones. I got my domain for ~$5 annually. Just be careful, since some TLDs don’t have features you want. As for why, I don’t remember, I just remember reading it from Namecheap’s wiki, which is who my provider is.
The problem is still there. My WAN address doesn’t match my router external port’s address. And Dynu’s control panel is saying that the FQDN is registered to 192.168.0.X … which is wrong.
So the LTE 4G stick is not working as expected. Unfortunately!
And this is also confirmed from Fritz!Box as you can see here
At this point I don’t know what to do…
I correct the Caddyfile anyway. But the log hasn’t changed much:
{"level":"info","ts":1740610115.915212,"msg":"shutdown complete","signal":"SIGTERM","exit_code":0}
{"level":"info","ts":1740769772.052813,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1740769772.0569193,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"warn","ts":1740769772.0569367,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1740769772.0592964,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//127.0.0.1:2019","//localhost:2019","//[::1]:2019"]}
{"level":"info","ts":1740769772.0606031,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1740769772.0606208,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1740769772.061601,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000506d80"}
{"level":"info","ts":1740769772.0618672,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1740769772.0632348,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"warn","ts":1740769772.0632975,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"warn","ts":1740769772.0633543,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"info","ts":1740769772.063362,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1740769772.0633662,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["tilde.mywire.org"]}
{"level":"info","ts":1740769772.0666773,"logger":"tls","msg":"cleaning storage unit","storage":"FileStorage:/data/caddy"}
{"level":"info","ts":1740769772.0688758,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1740769772.0689025,"msg":"serving initial configuration"}
{"level":"info","ts":1740769772.0705967,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1740769773.085277,"msg":"got renewal info","names":["tilde.mywire.org"],"window_start":1745592881,"window_end":1745765681,"selected_time":1745747807,"recheck_after":1740791373.085257,"explanation_url":""}
{"level":"info","ts":1740769773.0873144,"logger":"tls","msg":"updated ACME renewal information","identifiers":["tilde.mywire.org"],"cert_hash":"65b79389f920631282f551acd6aaa5a24a70149a51586cde26e6f5ac2b8d0a10","ari_unique_id":"nytfzzwhT50Et-0rLMTGcIvS1w0.BP_0J1wTMt2wc3cvJuWS4zOt","cert_expiry":1748270111,"selected_time":1745603433,"next_update":1740791373.085257,"explanation_url":""}
Beside that, I thought there might be another question on the table: the SSL certificate. I have the free Dynu account at the moment and this doesn’t not involve the generation of a SSL certificate for that domain (tilde.mywire.org)… so probably I have to understand how to get a free SSL CA for that domain, otherwise there will be none who can establish a correct HTTPS connection.
Interesting! The only reason why I’m thinking to Nextcloud is because I wanna have a personal cloud (file) server. Not interested in calendar, office tasks and anything like that. If you have something simpler to suggest, please do it!
[quote="TheRettom, post:18, topic:30037"]
If you’re not picky about a TLD (top-level domain, e.g. `.com`, `.net`, `.home`), you can get some insanely cheap ones. I got my domain for ~$5 annually. Just be careful, since some TLDs don’t have features you want. As for why, I don’t remember, I just remember reading it from Namecheap’s wiki, which is who my provider is.
[/quote]
Incidentally Namecheap is my provider too! But not for DDNS domain at the moment. I was thinking to buy a new TLD for my home server from them but then do I have to migrate the domain registration to the DDNS provider?
I’m trying to recall everything, and re-reading previous posts isn’t helping. So I’m trying to get this straight. Is 109.54.22.237 the IP address to the LTE 4G?
So the command didn’t fix it? It should. Usually the problem lies with the spacing in the Caddyfile, as Tab should be used for long spaces instead of Spacebar x however many times you used.
This is one of many reasons why Caddy is awesome. The Dynu plugin, and your configuration, should automatically handle SSL certificates for your domains in the site blocks.
{
acme_dns dynu mydynu_token
}
Caddy can also handle DynamicDNS if you get the plugin. You’d add to your global config so it would look like this:
If you spend a lot of time, and know what you’re doing in great detail, Nextcloud does decent enough. The thing that you said makes me want to point you to another service: you only want a file server. There are better, lightweight options that handle that, in my opinion, better than Nextcloud. I encourage you to try both and see what you like more, but I think you’ll find Nextcloud a bit disappointing.
Syncthing is what I plan on switching to when I need files, as I haven’t yet needed it. If you don’t care if something is made by the Chinese, Seafile will be good. I don’t want to go on a long tangent, but I find China, and especially Chinese IT hardware and software, to be extremely dangerous. It’s mostly open source. By that, I mean features are proprietary, but I believe it’s only for professional/licensed versions. Regardless, it being open-source for the base image usually indicates it’s safe, but I don’t understand coding languages enough to confirm. It’s written with C and Python.
Unfortunately, these are the only two viable options in my research to replace Nextcloud for your usecase.
to all! 
… this is the caddy log file when I’ve tried to access from the outside with the CADDYFILE written before:
