Infrastructure / Networking & access
Access is a set of boundaries.
DNS gets a client to the right place. TLS protects the connection. Authentication and network policy decide what the client may do. Each deserves its own design.
Last reviewed
On this page
Public and private paths
Selected applications are reachable through a shared public Caddy edge. Other services use internal routing and private remote access through Tailscale. Keeping those paths explicit makes it easier to review what a deployment exposes.
Public reachability does not mean anonymous access: applications such as Workbench still require an account.
DNS and TLS
AdGuard Home provides household DNS and filtering, with a synchronized secondary instance. Internal name resolution can send local clients directly to the local reverse proxy. Dynamic DNS keeps public records aligned with the household’s changing internet address.
Caddy handles hostname routing and certificate automation. The public and internal proxy configurations are separate operational responsibilities, even where they share infrastructure.
Identity belongs to the application too
Account Desk provides a shared household credential workflow for integrated applications. Each application still needs to enforce its own authorization rules. Workbench, for example, has an internal provisioning endpoint that the public edge rejects.
This avoids confusing a convenient shared login workflow with permission to access every record or administrative action.
A hostname is not a firewall
An internal hostname is useful for routing and organization. It does not prove that a service has no direct listener on the network. Reviewing exposure means checking the reverse proxy, published container ports, host listeners, and network policy together.
Likewise, placing a service behind a private access route is only part of the access story. It is important to distinguish intended routing from verified isolation.
Operational lessons
- Validate the active proxy configuration, not just a file believed to be deployed.
- Keep internal provisioning APIs out of public routing.
- Verify environment changes after recreating the affected container; a restart retains its original environment.
- Check local and remote access separately. A successful request from inside the LAN does not prove an off-LAN user journey.
See Shipping safely for how these boundaries affect releases.