then the easier method is to install Caddy as docker and use the containername:containerport method?... did I understand correctly?
Yes, if the only exposed port to the host or outside, is 443 from caddy container, then the only way to access any of those services is HTTPS through caddy.
I've installed caddy directly on my unbuntu server, but I admin my Jellyfin (and eventually Nextcloud) with Docker via CasaOS interface... is this a problem? Do I need to run Caddy in docker too?
The difference between having caddy or any other reverse proxy in docker alongside other apps/services, is that instead of having to expose ports for every container to the host, and then linking every service/app as, localhost:<host-port> to caddy, you can have them on the same docker network and use <container-name>:<container-port> and only expose 80 443 to the host, meaning that the only way to access app/services is through caddy, that way if you disable port 80 after configuring SSL certificates, you can only access services with HTTPS.
A friendly reminder that it is best to wait a bit before updating, in case there are any bugs still there, happened a few days ago with Forgejo, that a mayor bug was detected after initial release of v13.0
The TL, DR version of sharing with No License, is that technically speaking you are not explicitly permitting others to use your code in any way, just allowing them to look, a license is a formal way to give permissions to others to copy, modify, or use your code.
You don't need an extra file for the license, you can embed it on a section at the top of your file, as you did with the description, just add a # License section at the very top, if you want the most permissive one you can just use MIT, just need to replace the year of publication of the code, and you can use a pseudonym/username like 'hereforawhile@lemmy.ml' if you don't want to use something like email, username on another site or real name, that can be used to identify you, if that's a concern
Just wondering, as this is the second post I see you do like this, why not use git and a forge (codeberg, gitlab, github), to publish these projects, with proper file separation, a nice README with descriptions and instructions and a proper OSS license?
You don't need to backup all your 24TB of data, you can have a copy of a subset of your important data on another device, if possible the best would be a 3-2-1 approach.
"RAID is not a backup", is something that is mentioned a lot, as you can still lose data on a RAID setup.
Secondary/Failover DNS or any other service that would be nice to have running when the main server is down for any reason.
On your first part, clarifying your intent, I think that you are overcomplicating yourself by expecting traffic to come to the server via domain name (pass through proxy) from Router A network and by IP:Port from Router B network, you can access all, from anywhere through domains and subdomains, and avoid using numbers.
If you can't set up a DNS directly on Router A, you can set it per device you would want to access the server through port forwarding of Router B, meaning setting the laptop to use itself as primary DNS and as secondary use external, and any other device you would want in that LAN do the same (laptop as primary), It is a bit tedious to do per device instead but still possible.
Wouldn't this link to the 192.168.0.y address of router B pass through router A, and loop back to router B, routing through the slower cable? Or is the router smart enough to realize he's just talking to itself and just cut out `router A from the traffic?
No, the request would stop on Router B, and maintain all traffic, on the 10.0.0.* network it would not change subnets, or anything.
In other words any device on 10.0.0.* will do a DNS request, ask the Router where the DNS server is, then the DNS query itself is sent directly to the server on port 53, then when the response of the DNS is received, via domain, query the server again, but on port 80|443, and then receiving the HTTP/HTTPS response.
Remember that all my advice so far is so you don't use any IP or Port anywhere, and your experience is seamless on any device using domains, and subdomains, the only place where you would need to put IP or ports, is on the reverse proxy itself, to tell anything reaching it, where the specific app/service is, as those would need to be running on different ports but be reached through the reverse proxy on defaults 80 or 443, so that you don't have to put numbers anywhere.
If you decide on doing the secondary local DNS on the server on Router B network, there is no need to loop back, as that DNS will maintain domain lookup and the requests on 10.0.0.x all internal to Router B network.
On Router B then you would have as primary DNS the Server IP, and as secondary an external one like Cloudflare or Google.
You can still decide to put rules on the reverse proxy if the origin IP is from 192.168.0.* or 10.0.0.* if you see the need to differentiate traffic, but I think that is not necessary.
Do yourself a favor and use the default ports for HTTP(80), HTTPS(443) or DNS(53), you are not port forwarding to the internet, so there should be no issues.
That way, you can do URLs like https://app1.home.internal/ and https://app2.home.internal/ without having to add ports on anything outside the reverse proxy.
From what you have described your hardware is connected something like this:
Internet -> Router A (192.168.0.1) -> { Laptop (192.168.0.x), Router B (192.168.0.y|10.0.0.1) -> [ Desktop Server (10.0.0.114) ] }
You could run only one DNS on the laptop (or another device) connected to Router A and point the domain to Router B, redirect for example the domain home.internal (recommend <something>.internal as it is the intended one to use by convention), to the 192.168.0.y IP, and it will redirect all devices to the server by port forwarding.
If Router B has Port Forwarding of Ports 80 and 443 to the Server 10.0.0.114 all the request are going to reach, no matter the LAN they are from. The devices connected to Router A will reach the server thanks to port forwarding, and the devices on Router B can reach anything connected to Router A Network 192.168.0.*, they will make an extra hop but still reach.
Both routers would have to point the primary DNS to the Laptop IP 192.168.0.x (should be a static IP), and secondary to either Cloudflare 1.1.1.1 or Google 8.8.8.8.
That setup would be dependent on having the laptop (or another device) always turned ON and connected to Router A network to have that DNS working.
You could run a second DNS on the server for only the 10.0.0.* LAN, but that would not be reachable from Router A or the Laptop, or any device on that outer LAN, only for devices directly connected to Router B, and the only change would be to change the primary DNS on Router B to the Server IP 10.0.0.114 to use that secondary local DNS as primary.
Lots of information, be sure to read slowly and separate steps to handle them one by one, but this should be the final setup, considering the information you have given.
You should be able to setup the certificates and the reverse proxy using subdomains without much trouble, only using IP:PORT on the reverse proxy.
Most routers, or devices, let you set up at least a primary and secondary DNS resolver (some let you add more), so you could have your local one as primary and an external one like google or Cloudflare as secondary. That way, if your local DNS resolver is down, it will directly go and query the external one, and still resolve them.
Still. Thanks for the tips. I'll update the post with the solution once I figure it out.
You are welcome.
Maybe this one -> https://github.com/stan-smith/FossFLOW