I got into self-hosting a couple months ago after I started learning how to use Docker. I went from hating Docker (because I had only ever used it during hours-long attempts to build some annoying piece of software) to loving Docker because it makes configuring network-connected services so much easier.

For a while I was just hosting on my LAN from my desktop computer, but then I was out-of-state for two weeks and I found myself really wishing I had access to my self-hosted services while I was away.

Of course, I didn't just want to port-forward my computer through my router because that's a security nightmare, so I tinkered with a bunch of different solutions and landed on this one, which is working extremely well for me.

local Caddy server

First, my actual web services are hosted on my Windows desktop computer, which I leave on all the time because I'm a bad citizen. They're all docker services cobbled together with a bunch of compose.yml files.

The important one here is the Caddy server, which is set up as a reverse proxy, meaning that it takes neat and tidy network requests (foo.example.com, bar.example.com/xyzzy) and internally translates them into the actual requests that need to be made to the docker service in question (foo-container:8096, bar-container:1337/xyzzy).

To let these containers talk to each other even though they're not running from the same compose.yml, I just manually added them to a docker network. This is one part of the process that I wish was more automated, but honestly it's not that big a deal. When I add a new service, I just run docker network connect blah blah to hook it up, and then caddy can direct requests to it via its hostname.

# An example Caddyfile that does what I'm talking about.

foo.example.com {
    reverse_proxy foo-container:8096
}

bar.example.com {
    reverse_proxy bar-container:1337
}

tailscale

This is the actual solution for extending the network outside of my LAN. It's also the only part that isn't technically self-hosted, although apparently headscale is a decent self-hosted alternative.

When I was reading about self-hosting, everyone mentioned Tailscale but it took me a while to find a good explanation of what it actually is. It's really simple though:

You create an account with Tailscale, and then install their app onto each device that needs to access your LAN network. After you sign-in on the app, it reaches out to the Tailscale servers to figure out how to connect to all the other devices, and then it establishes a secure VPN tunnel to each of them. So, while establishing the connections does happen on their servers, the actual data being passed is over an encrypted peer-to-peer tunnel, so pretty much as safe as it gets.

note:
I'm pretty sure this is why their service is free, too -- they don't actually route much traffic over their servers, just the cheap initial handshakes that establish the secure tunnels.

All the peers on your Tailscale network are assigned an internal IPv4 address, which is only valid if you're connected to the network (in the exact same way that a 192.168.X.X address is only meaningful if you're on the right LAN).

This means that, even if you connect your phone or laptop outside of the LAN where your services are hosted, as long as Tailscale is active, you can access those services through the IPv4 address of your server.

Importantly, this isn't a normal VPN which would direct all of your internet traffic. Any traffic that isn't directed at the other devices on the Tailscale network is routed normally. That is one reason why I chose to use Tailscale instead of just setting up a Wireguard VPN or something like that, because it doesn't introduce the latency of an extra hop to your home network for all your traffic.

DNS

Using bare IP addresses is gross and annoying. Tailscale does assign domains to your devices through "MagicDNS", which works fairly well. However, what I really wanted was for them all to be united underneath my own domain (not the ugly Tailscale-provided machine.random-name.ts.net domain).

For a while I tried to use a .internal domain name, but that makes dealing with HTTPS really annoying because you end up having to manually install TLS certificates for that domain on every one of your devices. So, instead I used my existing brooke2k.com domain, and created a private subdomain category *.priv.brooke2k.com.

I created a DNS A-record on my registrar's website that redirects any *.priv.brooke2k.com requests to the Tailscale IPv4 address for my server. This is safe because, like mentioned earlier, that IP address is only meaningful if you're connected to my private Tailscale network. Anybody else will just time out (or if they happen to have mapped that specific internal IP address, it'll interact with that I suppose).

Because the domain is public (unlike the .internal domains), Caddy can now automatically provision public TLS certificates for them, making HTTPS easy. The only catch here is that, because the domains don't point to a public resource, the default ACME challenge will fail. (This is the process by which LetsEncrypt ensures it's issuing a certificate for a valid domain by pinging it with HTTP requests).

To get around this, I just had to tell Caddy to use the DNS challenge instead, as described in the docs here. This required hooking it up to my domain registrar's API, but that was pretty straightforward.

VPS gateway

This setup as I've described it is all you need if you want your self-hosted services to be accessible only from within the Tailscale network, but what if you also want to expose some of the services publicly? (For example, this blog?)

You could just port-forward your router to your PC -- this technically should be fine for a blog because it's a static site, so there's not really much attack surface for somebody with bad intentions to take advantage of.

However, you're then relying on your router's public IP address to be stable (it won't be), you're exposing that public IP address to everybody who interacts with your website (so they'll know roughly where you live), and also port-forwarding my router just feels gross and unsafe.

But Tailscale saves us again -- by buying a cheap VPS (I bought the cheapest option Vultr offers, which was $4.20/month), we can connect that VPS to our Tailscale network, and then set up another Caddy reverse proxy to forward HTTP requests sent to that VPS onto the actual server hosted at home.

The VPS in this scenario is doing almost nothing, just dumbly proxying requests, so it uses almost no resources (which is why I was able to buy the cheapest option), and I can still host all the important stuff on my own PC.

# Caddyfile on the VPS

blog.my-domain.com {
    # here's is the internal Tailscale IP address of the home server
    #
    # note that we proxy over HTTP, not HTTPS. the proxied request can't be HTTPS,
    # because that requires a TLS certificate on the domain (which doesn't exist).
    reverse_proxy http://13.37.13.37
}

conclusion

Self-hosting has been so much fun and so insanely useful that I can't believe I didn't get into it years ago. I can stream media from my own servers with Jellyfin, host my own RSS aggregator with Miniflux, use Seafile for cloud storage, and so on.

note:
The stereotype of hobbies like these is that they end up sucking up all your money, but in the long run I really think this saves me money. Instead of paying a dozen different companies a monthly fee to use their cloud services, I pay $12/year for a domain name and $4/month for a cheap gateway VPS, and that's pretty much it.

Anyways, hopefully somebody out there finds this post helpful some day for setting up their own self-hosted environment, I highly recommend it!