Cloudflare Tunnel Publishing
A secure external publishing design for self-hosted services using Cloudflare Tunnel, proxied DNS, HTTPS routing, security rules, rate limiting, and no inbound firewall port forwarding.
Project Goal
The goal of this project was to safely publish selected home lab services to the internet while keeping the home gateway closed to inbound web traffic. Instead of exposing public ports directly, services are routed through Cloudflare and delivered to internal containers through an outbound tunnel connector.
This design allows public access to approved services while avoiding direct exposure of the Proxmox host, router, NAS devices, management interfaces, SSH, or other internal lab resources.
Published Services
TLC Tech Lab Portfolio
Public resume and infrastructure portfolio site routed through Cloudflare Tunnel to a dedicated Debian/Nginx container.
Nextcloud Cloud Storage
Self-hosted cloud storage service for Greensburg Ghost Society, routed through Cloudflare for secure external member access.
Architecture
Technologies Used
What I Built
- Configured Cloudflare DNS for public domain routing while keeping records proxied through Cloudflare.
- Used Cloudflare Tunnel to route traffic from public hostnames to private internal lab services.
- Published the TLC Tech Lab portfolio site through a dedicated route to a Debian/Nginx container.
- Published a Nextcloud service for Greensburg Ghost Society through secure external routing.
- Enabled HTTP-to-HTTPS redirection so public access uses encrypted HTTPS sessions.
- Configured security rules to block common scanner paths and unwanted web probes.
- Configured rate limiting to reduce basic bot or automated scanner traffic.
- Validated that the home gateway does not require inbound port forwarding for these published services.
Security and Privacy Considerations
- No inbound port forwarding is required on the home gateway for the published services.
- Public DNS records are proxied through Cloudflare instead of exposing the origin directly.
- Internal IP addresses, tunnel identifiers, hostnames, and routing details are not published publicly.
- Only selected services are routed through the tunnel; management interfaces are not intentionally published.
- Scanner paths such as WordPress admin, login, Git, environment file, and phpMyAdmin probes are blocked.
- Rate limiting is applied to reduce noisy or abusive request patterns.
- The public portfolio is a static site, reducing application attack surface.
Operational Value
This project demonstrates how to publish useful services without treating a home lab like a traditional exposed web server. It combines DNS planning, reverse routing, HTTPS handling, edge security controls, firewall awareness, service isolation, and documentation.
It also gives me a real environment to practice troubleshooting public-to-private service paths, validating DNS behavior, documenting routing decisions, and balancing accessibility with security.
What This Demonstrates
The project shows practical experience with secure service publishing, DNS, HTTPS, Cloudflare Tunnel, edge filtering, rate limiting, and protected access to self-hosted infrastructure. It also supports the broader goal of moving beyond reactive support work into infrastructure operations and systems engineering.
Project Status
Active and operational. Current published services include the TLC Tech Lab portfolio and the Greensburg Ghost Society Nextcloud environment. Future improvements may include additional monitoring, access logging review, and more formal change documentation.