Self-hosting behind your own reverse proxy — the step-by-step

Repo: https://github.com/empty-town/selfhosted

A few days ago I posted You do not need a tunnel to securely expose your self-hosted services.

But a fair chunk of the comments said the same thing: This is too long. No one will read this. it's a valid approach, but not something I can actually follow. Point taken. It explained the "why" but didn't provide an example of "how". This is an OPINION based guide/demo. The purpose of this repo is for users to experiment/learn with dummy data about the processes, technologies, and methods of securely hosting public services. Use it at your own risk, and I will not be maintaining it.

So here's the "how." A ready-to-run repo, and clear step-by-step instructions to stand it up on your own (linux) home server. Caddy with a CrowdSec bouncer compiled in, threat detection, per-service network isolation. It is based upon my own services that I have been running for many years. Clone it, follow the steps, and you've got the setup from the original post running.

I also encourage the same commenters on the previous post to continue sharing their concerns, improvements, doubt, warnings, or other musings.

Curious what this actually stands up on the public internet? This same repo runs a live demo:

• Jellyfin — jellyfin.starman.app
• Immich (photos) — photos.starman.app
• Nextcloud (files) — cloud.starman.app

I expect it will go down with too many users due to the fact it only has 1G memory. I will be taking it down in 30 days. The IP is 67.207.88.112. If someone wants to DDoS it, go for it, but I won't be putting it back up.

What this does NOT protect against

This architecture contains and deters; it does not make you unhackable. Know what's still on you:

• A fresh exploit in an exposed app. A new CVE in Jellyfin/Immich/Nextcloud is reachable until your next update. Patch speed is the defense.
• Stolen or phished passwords. A correct password looks like a login, not an attack. Unique passwords + 2FA (or SSO in front).
• A poisoned upstream image. Updates trust the app publishers. Digest pinning (see Image versions) is the opt-in defense.
• DNS or registrar account takeover. Whoever controls your DNS can impersonate your services with a valid certificate. Hardware-key 2FA on those accounts.
• Attackers already on your LAN. The firewall rule blocks containers→LAN, not LAN→server. VLANs fix this.
• Container escape via a kernel exploit. All containers share one kernel. Accepted residual risk; a DMZ/VLAN caps the damage.
• DDoS. A saturated home uplink can't be fixed from behind the router.
• Quiet intrusions. CrowdSec bans noisy attackers, silently. Nobody is alerted unless you add notifications.
• Data destruction through a valid account or popped app. Ransomware on a family laptop, or a compromised app deleting its own data. Only tested, offline backups fix this.
• Physical theft of the server. Data is unencrypted at rest unless you add disk encryption (LUKS).

! Important !

One thing this guide deliberately leaves out: your router. Security, networking, port-forwarding, VLANs, DMZ, look different on every make and model, and there's no way to write one set of steps that fits them all. Your router configuration is up to you to research and decide on.

Before you expose anything: are you ready?

I encourage learning by doing. But a few things need to be true before you point the internet at your public IP. Read them. Each one you fail tells you what you need to learn.

1. Does anyone but you actually need access? If it's only ever you, stop here and use a VPN — Tailscale or WireGuard, done. Public exposure buys you nothing and costs you attack surface. The rest of this guide is for when you have decided that other people need to reach your services without installing anything first.

2. Do you have a real public IP? Open your router's admin page and find its WAN IP. Now load whatismyip.com. Same number? You have a public IP. Different number? You're behind carrier-grade NAT — your ISP is sharing that address with other customers, and no amount of port-forwarding will reach you. Call your ISP and ask for a public IP, or use a cheap VPS in front of your services as your public endpoint. While you're in there: does that WAN IP stay the same or change? If it changes, you'll need dynamic DNS, this guide can help you set it up.

3. Can you describe the path a request takes? Roughly: DNS resolves the name to your IP, the request hits your router, the router forwards the port to one machine, something terminates TLS, the app answers. If that sentence is fog, spend a weekend on how web traffic works before you expose anything.

4. Do you own your network? Can you log into your router, add a port-forward, and turn UPnP off so apps can't quietly open ports behind your back? Could you confirm (from outside your network) exactly which ports answer on your public IP? If not, that's time spent with your router software.

5. Will you actually maintain it? Are you willing to update frequently, use a strong password on every login page, enable 2fa when applicable, and have some way to notice when something breaks — a log you read, an alert? A box you stand up perfectly and then forget is how most real compromises start. If the honest answer is "no," expose nothing until it's "yes."

6. Can you restore from a backup? Assume that one day a service gets popped, a disk dies, a docker compose down -v. Do you have backups of your data and your configs? Have you actually restored one to confirm it works? An untested backup is a guess. Bonus points, ZFS with snapshots, and sync to off-site backup.

7. Do you know what hardware Admin panels are? Do you trust them? Do you know not to expose an all-in-one appliance's admin panel? A consumer NAS web UI — the kind with a history of critical CVEs and slow patches — is exactly what gets mass-scanned and mass-exploited. Never expose any administrator interfaces for hardware you are running.

8. Do you own a consumer router? Use non-consumer hardware, especially when it comes to the router. Whether it's a router, NAS, switch, etc. Low-cost routers/NAS are buggy, poorly developed, poorly maintained, and targeted as we saw with QNAP/QLocker. OPNSense or PFSense, DD-WRT are the top preferred router operating systems, and can run on very meager hardware. If you don't have this, there's your first focus.

9. Do you know the basics of networking? You should be able to say in a sentence each what these are and why they matter to what you're about to do: an IP address and a subnet; a port, and TCP vs UDP; NAT and port-forwarding; DNS, and the difference between an A, CNAME, and wildcard record; what a reverse proxy is; HTTP vs HTTPS and what TLS actually protects; and a firewall. Worth recognizing or considering: VLANs and network segmentation.

If you're even close to unsure about any of these, you should read up on individual things until you're confident you know the risks, configuration, and abilities of individual technologies.

What this is

This is a reverse proxy service architecture. Here, Caddy is the only thing on your network the outside world can talk to. A request arrives, Caddy handles the HTTPS encryption, works out which service it's for, and passes it inward. Your actual apps — Jellyfin, Immich, Nextcloud, etc — never face the internet directly. They only ever hear from Caddy.

Why funnel everything through Caddy? Because every service you expose directly is another attack surface, and another thing you have to keep patched/know is exposed. Also this terminates TLS at one point.

Behind Caddy, each service runs in its own container network, and Docker walls those networks off from each other — break into one and you can't step through into the next. Reaching the other machines on your home network is blocked too — by a firewall rule this setup installs. Getting past all of that would mean breaking out of the container and into the host — which takes a separate, much harder exploit. The blast radius is one part of a secure setup, not everything.

Additionally, CrowdSec watches the proxy's (Caddy) logs, and the moment an IP starts attempting infiltration — scanning for admin pages, trying known exploits — it gets banned before it reaches any app. The internet will start probing you within minutes of going live; this is what helps you manage common attackers.

None of this needs a VPN or a tunnel. That's the whole point of the original post, and the opinion this guide is willing to stand behind: if other people need to reach your services without installing anything, you can expose them directly and safely — provided you understand achitecture well enough.

Continued in the repo README.md