Most self-hosting setups fail in a boring way:
They treat every service like it belongs behind the same front door.
A dashboard, a public app, a metrics panel, a database admin UI, SSH, and an API all get routed, proxied, labeled, and “secured” as if they are the same class of thing.
They are not.
The first question should be brutally simple:
Does the public need to reach this?
<img src="https://media.daily.dev/image/upload/s--SotskOEh--/f_auto/v1782772347/ugc/content_26e5e032-5769-40d1-b616-cb28108ddfbf?_a=BAMAMicg0" alt="Public vs private network architecture.png">
If yes, it belongs on the public ingress plane.
If no, it belongs on the private admin plane.
That split matters more than the specific stack. Cloudflare Tunnel, Traefik, Tailscale, Caddy, nginx, WireGuard — pick your tools. The operating rule is the same:
Do not expose what does not need to be exposed.
The common mistake is trusting the proxy config as the boundary.
A route label says what you intended.
A health check says something responded.
A dashboard returning 200 says it is alive.
None of that proves the service is only reachable where you think it is.
The actual boundary is lower level:
<pre><code>Where is the service bound?
127.0.0.1?
mesh interface?
0.0.0.0?
public interface?
</code></pre>
That one detail decides whether you have a private admin surface or an accidentally public one.
A clean self-hosted setup should make this boring:
<pre><code>Public apps:
Internet → controlled ingress → reverse proxy → app

Admin tools:
operator device → private mesh → loopback/mesh-bound service
</code></pre>
The two planes should meet only through routes you explicitly declare.
No admin service gets public reachability “temporarily.”
No database binds to <code>0.0.0.0</code> because “the firewall handles it.”
No dashboard relies on a proxy allowlist that may not even see the IP you think it sees.
The useful audit is not:
“Is the app healthy?”
It is:
“Can anything reach this service from a path that should not exist?”
That means checking bind addresses, live listeners, tunnel routes, proxy routers, DNS, and orphaned routes against the actual running system.
Config is intent.
Runtime is truth.
For small self-hosted estates, this is the difference between “one box running a few apps” and “one box with an attack surface you can still reason about.”
<code>#selfhosting</code> <code>#devops</code> <code>#security</code> <code>#homelab</code> <code>#infra</code>
<h3></h3>

DevOps Daily

Self-hosted setups often make a critical mistake: treating all services as the same class of thing and relying on reverse proxy configuration as the security boundary. The real boundary is determined by where a service is bound — 127.0.0.1, a mesh interface, or 0.0.0.0. The correct mental model splits services into two planes: a public ingress plane for internet-facing apps, and a private admin plane for dashboards, database UIs, and internal tools. These planes should only connect through explicitly declared routes. Config expresses intent, but runtime bind addresses are the truth. The practical audit question is not whether a service is healthy, but whether it can be reached from a path that should not exist.

Your Reverse Proxy Is Not the Security Boundary