I have a few selfhosted services, but I’m slowly adding more. Currently, they’re all in subdomains like linkding.sekoia.example etc. However, that adds DNS records to fetch and means more setup. Is there some reason I shouldn’t put all my services under a single subdomain with paths (using a reverse proxy), like selfhosted.sekoia.example/linkding?
The only problem with using paths is the service might not support it (ie it might generate absolute URLs without the path in, rather than using relative URLs).
Subdomains is probably the cleanest way to go.
Agreed, I’ve run into lots of problems trying to get reverse proxies set up on paths, which disappear if you use a subdomain. For that reason I stick with subdomains and a wildcard DNS entry.
I started with paths because I didn’t want to pay for a expensive SSL certificate for each service I’m running (now with letsencrypt no problem anymore). But that turned out to be a terrible idea. Once I wanted to host a service on a different server the problems started. With subdomain you just point your DNS to the correct IP address and that’s it. With paths you have to proxy everything through your one vhost and it get’s really messy. And to be honest most services expect you to run them on the root directory and not a path.
Subdomain; overall cheaper after a certain point to get a wildcard cert, and if you split your services up without a reverse proxy it’s easier to direct names to different servers.
Who still pays for certs?? (I say this as non-snarkily as possible.) I just imagined everyone self-hosting uses Let’s Encrypt.
Let’s encrypt is fine for encryption but not identification. I have some stuff which I prefer that on, specifically around demonstrating services that I host at home in the workplace. Having full verification just reduces the questions I have to deal with. It’s like $90/year for a wildcard.
Subdomain; overall cheaper after a certain point to get a wildcard cert, and if you split your services up without a reverse proxy it’s easier to direct names to different servers.
You can certainly do it with paths, but it’s generally cleaner and easier to do subdomains. Some apps don’t like paths without additional setup and/or reverse proxy configuration because they hard-code redirects to specific paths.
In some cases (if you are hosting services both internal and externally), you’ll want to configure a split brain DNS (a local DNS server that resolves internal host to internal IPs and external DNS resolves to public IPs).
Yes there’s some setup with that, but once you really get into it – you’ll start automating that :) I have a script that reads all of my Traefik http routers via the rest API and updates my unbound DNS server automagically.
Try not to use paths, you’ll have some weird cross-interactions when two pieces of software set the same cookie (session cookies for example), which will make you reauthenticate for every path.
Subdomains are the way to go, especially with wildcard DNS entries and DNS-01 letsencrypt challenges.
If you don’t have any restrictions (limited subdomains, service only works on the server root etc.) then it’s really just a personal preference. I usually try paths first, and switch to subdomains if that doesn’t work.
I’ve kinda been trimming the amount of services I’ve exposed through subdomains, it grew so wild because it was pretty easy. I’d just set a wildcard subdomains to my ip and the caddy reverse proxy created the subdomains.
Just have a wildcard A record that points *. to your ip address.
Even works with nested domains like “home.” and then “*.home”
With paths you can use httpS://192etc/example, but if you use subdomains, how do you connect internally with https? Https://example.192etc won’t work as you can’t mix an ip address with domain resolution.
You can do this. The reality is it depends on the app.
But ultimately I used both and pass them through a nginx proxy. The proxy listens for the SNI and passes traffic based on that.
For example homeassistant doesn’t do well with paths. So it goes to ha.contoso.com.
Miniflux does handle paths. So it uses contoso.com/rss.
Plex needs a shitload of headers and paths so I use the default of contoso.com to pass to it along with /web.
My photo albums use both. And something’s even a separate gTLD.
But they all run through the same nginx box at the border.
If you don’t have any restrictions (limited subdomains, service only works on the server root etc.) then it’s really just a personal preference. I usually try paths first, and switch to subdomains if that doesn’t work.
