Submitted 2 days ago by JackDavies@lemmy.world to selfhosted@lemmy.world
https://jackdavies.github.io/howto/2026/01/03/how-to-selfhost-subsomains.html
I created a short tutorial on using sub domains to access services hosted within my home network, thought I would share it here in case anyone finds it useful
This is the first time I’ve made a technical tutorial so apologise if there are mistakes/its confusing, feedback will be appreciated
Thanks for sharing!
I can recommend nginx-proxy-manager for people who do not want to fiddle with proxy config files.
It works well, but if you want to do ‘custom stuff’ (like hosting a matrix instance) you’ll be out of luck
I did similar with caddy. I own a domain and my server runs pihole and it is configured as DNS server. So what I did was setup caddy to create local subdomains that are only reachable through my network. For example: subdomain.mydomain.com , that works only from home. It works with ssl as well
I use caddy as well, but with headscale too so I can access it from wherever I am.
I personally use caddy as a reverse proxy
Yeah it was honestly changing the router settings that was the hardest part for me, exposing port 22 and 80. Caddy was really easy to use
You seem to have descibed your port forwards backwards It is the router forwarding the ports to the gateway pi (and potentially other devices), not gateway pi and other devices forwarding to the router. The forwards to servers are incoming from the internet.
(Theoretically you could have your pi physically between the router and the internet (modem) acting as a sort of pre-router, but this would be unusual. Perhaps you could describe your physical setup more clearly. What is physically/wirelessly connected to what, to the internet.)
He does refer to the pi as a gateway, so you would be right about it coming before the router. In that case, the pi would be the device handling NAT and forwarding ports.
So I think he’s describing it accurately… it’s just not a common setup to see these days.
Very cool, great work!
Worth noting about this approach is that the globel list of subdomains is publicly searchable. So, you’ll see vulnerability and AI scans on those endpoints.
If that’s a concern for you, using path-based routing (e.g. Apache VirtualHost) allows you to use difficult to guess paths to your cloud.
Worth noting about this approach is that the global list of subdomains is publicly searchable.
Can you expand on this? What is it that you call the “global list of subdomains”?
Certificate transparency, unless you use wildcard certs
It trivial to get a list of all registered domains and subdomains and the IP addresses they map to. There are any number of paid services to make it easy (e.g. subdomainfinder.c99.nl) but I’m pretty sure there’s also a way to do it yourself.
Oh excellent, thanks foe sharing.
Not positive, but I think you left in a reference to real info (twilightparadox.com) instead of “example-fying” it (mydomain.com), in the paragraph just before section 4:
For example say I have home-assistant running on a Pi with the local address 192.168.0.11, I could create a subdomain named ha that has the value mysub.twilightparadox.com then create the following nginx config
server{ listen 80; server_name ha.mydomain.com; resolver 192.168.0.1; location / { proxy_pass http://192.168.0.11/; } }When nginx sees a request for ha.mydomain.com it passes it to the address 192.168.0.11 port 80.
I’m not sure which reference you are referring to, twilightparadox.com is a domain on the dynamic DNS service, mysub is also an example
Section 1 says you’re using freedns.afraid.org though.
Oh I thought it was sub domains for localhost. I actually wonder now if that’s possible.
It is, although they all go… to localhost
frongt@lemmy.zip 2 days ago
I am once again recommending that you not expose any services to the internet except a VPN
VeganCheesecake@lemmy.blahaj.zone 1 day ago
Good as a general recommendation.
I also feel like the risk levels are very different. If it’s something that performs a function but doesn’t save/serve any custom data (e.g. bentopdf), that’s a lot easier to decide to do than something complicate like Jellyfin.
I do have public addresses for Matrix, overleaf, AppFlowy, immich because they would be much less useful otherwise. Haven’t had any problems yet, but wouldn’t necessarily recommend it to others.
I’d never host any stuff with “Linux ISOs” on a public adress, that seems like it’d be looking for trouble.
frongt@lemmy.zip 1 day ago
Doesn’t matter. Any exposure risks compromise. From there, an attacker could pivot to read your data, mine cryptocurrency on your device(s), serve objectionable material, or other unsavory activities.
Even if you have authentication enabled, not all APIs require authentication. Jellyfin in particular is not designed to be internet-facing. And even if it does require authentication, authentication bypass attacks are a thing.
essell@lemmy.world 2 days ago
I’m not sure that’s gonna work with my Jellyfin 🤔🫤
LordKitsuna@lemmy.world 2 days ago
I mean it WOULD work you would just need a von on every device you wanted to use.
The REAL answer is never host them DIRECTLY, always use a reverse proxy like nginx. Many projects (i believe jellyfin is one of them) explicitly recommend this for better security