— Infrastructure —

The patterns we use. Not the specifics.

Every service runs on architecture we designed and maintain — Cloudflare-fronted, self-hosted, container-isolated. Here's how the pieces fit together, without disclosing the specifics that would put customer workloads at risk.

— Architecture principles —

Three rules that govern every deployment.

i.

Zero inbound exposure

All public traffic enters via Cloudflare — Tunnel for HTTPS services, edge proxy for everything else. No origin services bound to the public internet. Outbound-only connections from our network to Cloudflare's edge.

ii.

Container-isolated workloads

Each service runs in its own container, on its own internal network where appropriate. Inter-container communication uses Docker hostnames, never host networking. Compromise of one service doesn't compromise the others.

iii.

Default-deny everything

Host firewall denies all inbound by default with explicit allows only. VPN-routed namespaces for traffic that must egress through a remote network. No open management surfaces from the public internet.

— Network architecture —

How a request reaches a service.

InternetClient requestCloudflareCDN + WAFAccess + TunnelDNS + PagesDOOM_SERVERDocker + CasaOSAMPGame serversNextcloudFile storageImmichPhoto backupJellyfinMediaGluetun *VPN egress→ external VPN(media stack only)UFWOutbound tunnel onlyNo inbound ports* Gluetun routes the media-automation stack's outbound traffic through an external VPN.

All public traffic enters via Cloudflare — its edge handles TLS termination, caching, WAF, and DDoS mitigation before anything reaches our infrastructure. From there, Cloudflare Tunnel delivers the request to the appropriate container. No service publishes a routable interface to the public internet.

— Container stack —

What runs on the box.

ContainerRole
AMPGame server management
NextcloudFile sync and collaboration
ImmichPhoto and video backup
JellyfinMedia server
JellyseerrMedia request management
Uptime KumaService monitoring
UmamiAnalytics (self-hosted)
GluetunVPN gateway for media-automation stack
Sonarr / Radarr / ProwlarrMedia-automation stack

Network bindings, internal addressing, and access policies are not disclosed. What's on the box is not what protects the box.

— A pattern we like —

Hostnames over addresses.

The most common Arr-stack failure pattern is configuring Sonarr, Radarr, and the rest to communicate with each other using the host machine's address. It breaks when containers restart in a different order, when the host's address changes, or when a VPN gateway like Gluetun is introduced between the stack and the public internet.

The fix is mechanical: configure inter-container traffic by Docker container hostname instead. Docker's internal DNS resolves the hostname regardless of restart order, network namespace changes, or address reassignment.

Every container in our stack that needs to talk to another talks via hostname. It's a ten-second config change that eliminates an entire class of failures and removes a dimension of fragility from the deployment.

— Live status —

View full status page →

◆ Next step

Questions about the setup?

We run this for customers. If you want the same architecture in your environment, that's Homelab Consulting.