LifeBytes Journal

Publishing self-hosted apps on the internet without opening ports is now simple and safe with Cloudflare Tunnel and Nginx Proxy Manager (NPM). This guide shows you how to route traffic from your domain through Cloudflare’s global network to your internal services, using Docker on Linux. You will get HTTPS by default, Zero Trust access, and simple management for multiple apps.

Why use Cloudflare Tunnel + Nginx Proxy Manager?

Cloudflare Tunnel (cloudflared) creates an outbound-only connection from your server to Cloudflare, so you do not need port forwarding or a public IP. Nginx Proxy Manager provides a friendly UI to reverse-proxy multiple services, manage SSL, and handle redirects and headers. Together, they offer a secure and flexible edge-to-origin pipeline for home labs and small businesses.

Prerequisites

- A domain managed by Cloudflare (nameservers must point to Cloudflare)
- A Linux server (Ubuntu 22.04+ recommended) with Docker and Docker Compose installed
- Basic familiarity with terminal and Docker

Architecture overview

Cloudflare edge terminates TLS and forwards requests over an encrypted tunnel to the cloudflared container on your server. The cloudflared service forwards hostnames to Nginx Proxy Manager, which then routes requests to internal applications (e.g., Home Assistant, Portainer, Jellyfin) based on hostnames. This design centralizes access, certificates, logging, and security rules.

Step 1 — Install Docker and Compose (Ubuntu)

Run the following commands to set up Docker:

sudo apt update
sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
newgrp docker

Step 2 — Create a Cloudflare Tunnel

1) In the Cloudflare dashboard, open Zero Trust (or Tunnels) and create a new Tunnel named “homelab”.
2) Choose “Docker” as the environment and copy the token-based command or credentials JSON for cloudflared. We will use the token method for simplicity.
3) Do not add routes yet—we will define them in the docker-compose file.

Step 3 — Create docker-compose.yml

Create a working directory (e.g., /opt/homelab) and add this compose file. Replace example.com with your domain and paste your Cloudflare tunnel token.

version: "3.8"
services:
  cloudflared:
    image: cloudflare/cloudflared:2024.8.3
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=<PASTE_YOUR_TUNNEL_TOKEN>
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "cloudflared", "version"]
      interval: 30s
      timeout: 10s
      retries: 3

  npm:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped
    ports:
      - "81:81"        # NPM admin UI
      - "80:80"        # HTTP
      - "443:443"      # HTTPS
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - cloudflared

networks:
  default:
    name: homelab

Start the stack:

docker compose up -d
docker compose logs -f cloudflared

Step 4 — Map hostnames to Nginx Proxy Manager

Back in the Cloudflare dashboard, open your Tunnel and add public hostnames to route traffic to NPM. For each app, create a route like this:

Example routes:
- app1.example.com → http://npm:80
- media.example.com → http://npm:80
- portainer.example.com → http://npm:80

This means Cloudflare forwards incoming requests for those hostnames down the tunnel to the NPM container.

Step 5 — Configure Nginx Proxy Manager

1) Open http://YOUR_SERVER_IP:81 and log in (default admin credentials are shown on first boot; change them immediately).
2) For each internal service, create a “Proxy Host”:
- Domain Names: app1.example.com
- Scheme: http
- Forward Hostname/IP: the internal container name or IP (e.g., homeassistant or 127.0.0.1)
- Forward Port: the app port (e.g., 8123)
- Block Common Exploits: enabled
- Websockets Support: enabled (for apps like Home Assistant, Portainer, or anything real-time)

3) Under the SSL tab, select “Request a new SSL Certificate” and choose Let’s Encrypt. Enable “Force SSL” and “HTTP/2 Support”. NPM will fetch and auto-renew certificates for the hostname.

Step 6 — Enforce Zero Trust access (optional but recommended)

Use Cloudflare Access to protect sensitive apps with identity-aware policies. In Zero Trust → Access → Applications, add an app for app1.example.com, choose “Self-hosted”, and require login with your IdP (Google, GitHub, Microsoft, etc.). You can restrict by email domain, group, or country. Access will challenge users at the edge before requests hit your tunnel.

Step 7 — Security hardening tips

- In Cloudflare DNS, keep your A/AAAA records orange-cloud (proxied).
- Enable WAF and Bot Fight Mode where appropriate.
- For APIs or admin panels, add Access policies and IP allowlists in Cloudflare, and enable “Block Common Exploits” in NPM.
- If you need end-to-end encryption to NPM, set up a trusted origin certificate from Cloudflare and configure NPM to use HTTPS upstreams.

Troubleshooting

502 Bad Gateway: Check the NPM “Forward Hostname/IP” and port. Ensure the target app is reachable from the NPM container network.

403 from Cloudflare Access: Confirm your email is allowed by the Access policy and that your device clock is correct.

WebSockets not working: Enable “Websockets Support” in NPM and verify the app uses the correct path. Most real-time dashboards require this.

Large uploads fail: In NPM, add a Custom Nginx config snippet such as client_max_body_size 100m; for the specific host.

SSL mismatch or loops: Use HTTP between Cloudflare and NPM if Cloudflare terminates TLS at the edge. If you enable origin TLS, make sure certificates and trust are configured properly.

Scaling and operations

- Add more hostnames in the Tunnel as you publish new services; just point them to http://npm:80 and configure the upstream in NPM.
- Use multiple cloudflared instances (on different servers) in the same Tunnel for high availability; Cloudflare will load-balance them.
- Monitor with docker compose logs -f and Cloudflare analytics. Schedule updates with watchtower or perform manual rolling updates.

Wrap-up

You have exposed internal services securely on your own domain without opening any inbound ports. Cloudflare Tunnel handles the edge and connectivity, while Nginx Proxy Manager gives you a clean UI for reverse proxy rules, SSL, and performance tweaks. With Access policies, WAF, and good Nginx hygiene, you can safely run public-facing apps from a single Docker host.

Overview

This step-by-step guide shows you how to publish a private web service to the internet securely using Cloudflare Tunnel (cloudflared) and Cloudflare Zero Trust—without opening inbound ports on your router. You will run the tunnel in Docker on Ubuntu, route your domain through Cloudflare, protect the app with Single Sign-On (SSO), and optionally verify JSON Web Tokens (JWT) at the application layer. This approach adds strong security, free TLS, DDoS protection, and granular access control to your self-hosted apps.

Prerequisites

You need an Ubuntu 22.04 or 24.04 server (bare metal or VM), Docker and Docker Compose installed, a domain you control, and a Cloudflare account. If your domain is not already on Cloudflare, change your registrar’s nameservers to Cloudflare’s to manage DNS and Zero Trust features.

Step 1 — Prepare your domain on Cloudflare

1. Log in to Cloudflare and add your domain if you have not already. Follow the prompts to update nameservers at your registrar. Propagation may take a few minutes.

2. In the Cloudflare dashboard, verify that DNS is active and the orange cloud is enabled for your root or subdomains.

Step 2 — Enable Zero Trust

1. Open the Zero Trust dashboard (also labeled “Zero Trust” or “Access” in Cloudflare). Create your Zero Trust account if prompted.

2. Under Settings > Authentication, connect an identity provider (e.g., Google, Microsoft Entra ID, GitHub) or enable the One-Time Pin option for quick protection.

Step 3 — Install Docker and Compose (if needed)

If Docker is not installed, use the official convenience script. Then enable and test it. Example:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
newgrp docker
docker --version

Install Docker Compose v2 if it is not present (many modern Docker packages include it as docker compose):

docker compose version

Step 4 — Create a Tunnel in the Cloudflare Dashboard

1. In Zero Trust > Networks > Tunnels, click “Create a tunnel,” choose “Cloudflared,” name it (e.g., homelab-tunnel), and create it.

2. Copy the provided token. You will use this token in Docker to authenticate the tunnel without interactive login.

Step 5 — Run cloudflared in Docker

Create a working directory, then a docker-compose.yml file. Replace the placeholder token with yours.

mkdir -p ~/cloudflared && cd ~/cloudflared
nano docker-compose.yml

version: "3.8"
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    restart: unless-stopped
    environment:
      - TUNNEL_TOKEN=<PASTE_YOUR_TUNNEL_TOKEN>
    volumes:
      - ./config:/etc/cloudflared

Bring it up:

docker compose up -d

The container will authenticate with Cloudflare automatically using the token. You should see the tunnel listed as “Healthy” in the Zero Trust dashboard within a minute.

Step 6 — Configure ingress rules to publish your service

Create a config file to route a public hostname to your internal service. For example, map app.yourdomain.com to a local web app on port 8080 and ha.yourdomain.com to Home Assistant on port 8123.

mkdir -p config
nano config/config.yml

tunnel: <YOUR_TUNNEL_ID>
credentials-file: /etc/cloudflared/<YOUR_TUNNEL_ID>.json
ingress:
  - hostname: app.yourdomain.com
     service: http://host.docker.internal:8080
  - hostname: ha.yourdomain.com
     service: http://host.docker.internal:8123
  - service: http_status:404

On Linux, host.docker.internal may not resolve by default. Use the host IP (e.g., http://192.168.1.50:8080) or attach the tunnel to the same Docker network as your app containers and reference them by service name (e.g., http://web:8080).

Restart the tunnel to apply changes:

docker compose restart

Step 7 — Route DNS to the tunnel

Back in Zero Trust > Networks > Tunnels, open your tunnel and add Public Hostnames. Enter app.yourdomain.com and select the corresponding service. Cloudflare will automatically create proxied DNS records and issue valid TLS certificates.

Step 8 — Protect the app with Cloudflare Access (SSO/MFA)

1. Go to Zero Trust > Access > Applications > Add an application > Self‑hosted.

2. Set the application domain to app.yourdomain.com, pick a name, and click Next.

3. Create a policy: allow emails from your domain (e.g., [email protected]) or a group from your IdP. Optionally require MFA with Cloudflare’s TOTP or your IdP’s enforced MFA.

4. Save. Now your app is behind an identity-aware proxy. Only authenticated users you choose can reach it.

Optional — Verify JWT in your application or reverse proxy

Cloudflare Access sends a signed JWT in the CF-Access-Jwt-Assertion header. Your app or Nginx can verify it for an extra layer of defense-in-depth. In Nginx, pass the header to upstream or validate with an auth_request service. If you use languages like Node.js, Python, or Go, verify using the public JWKs at https://<your-team>.cloudflareaccess.com/cdn-cgi/access/certs and check audience and issuer claims.

Monitoring and troubleshooting

Check health: In the Cloudflare dashboard, your tunnel should be Healthy. On the host, view logs with docker logs -f <container_name>.

403 after login: Ensure your Access policy allows your email or group, and that the application domain matches the hostname you visit.

Bad gateway: Verify the internal service address and port in config.yml. Confirm the service is reachable from the tunnel container’s network.

DNS mismatch: Confirm the Public Hostname in the tunnel matches the DNS entry and the Access application domain.

IPv6 or CGNAT: Cloudflare Tunnel works without inbound ports, even behind CGNAT. No router changes are needed.

Security best practices

Use strong identity controls with MFA and short Access session durations. Limit policies to specific users or groups, not anyone with the link. Avoid exposing administrative apps publicly unless protected by Access. Keep cloudflared updated by periodically pulling the latest Docker image, and restrict who can manage your Cloudflare account with role-based access.

Conclusion

With Cloudflare Tunnel and Zero Trust, you can publish internal apps safely without port forwarding or complicated firewall rules. You get automatic TLS, DDoS protection, identity-based access, and optional JWT validation. This modern pattern is ideal for homelabs, small businesses, and remote teams that need secure, simple access to self‑hosted services.

Overview

Exposing self-hosted services to the internet usually means opening ports, managing dynamic DNS, and hardening firewalls. Cloudflare Tunnel (cloudflared) flips that model. Your server dials out to Cloudflare, creates an encrypted tunnel, and serves traffic from a Cloudflare edge without any inbound ports. Add Cloudflare Zero Trust Access on top, and you get identity‑aware filtering, one‑time PIN, and granular policies. This guide shows how to publish a web app from a Linux server using Cloudflare Tunnel and secure it with Zero Trust.

Prerequisites

- A Cloudflare account with your domain added and nameservers pointing to Cloudflare.

- A Linux host (Ubuntu/Debian examples below) running the service you want to expose (e.g., a dashboard on port 8080).

- Shell access with sudo privileges.

Step 1 — Install cloudflared

On Ubuntu/Debian, install the official package. The commands below add the repository, verify signatures, and install cloudflared.

# Add Cloudflare GPG key and repository
sudo mkdir -p /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloudflare-main.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/cloudflared.list

# Install cloudflared
sudo apt update
sudo apt install -y cloudflared

# Verify
cloudflared --version

On other distributions, you can use a static binary or Docker. The rest of the steps are identical.

Step 2 — Authenticate and create a named tunnel

Run an interactive login to authorize cloudflared with your Cloudflare account. Your browser will open and ask you to pick the domain.

cloudflared tunnel login

Create a tunnel with a friendly name. This command outputs a UUID and writes a credentials JSON file into ~/.cloudflared.

cloudflared tunnel create homelab-tunnel

Keep the UUID; you will need it in the configuration file.

Step 3 — Map a public hostname to your local service

Choose a subdomain such as app.example.com and route it to the tunnel. Cloudflared will create the necessary DNS record in Cloudflare automatically.

cloudflared tunnel route dns homelab-tunnel app.example.com

Now define the ingress rules that connect the hostname to your local service (for example, a web UI on http://localhost:8080). Create a config at ~/.cloudflared/config.yml:

tunnel: <your-tunnel-uuid>
credentials-file: /home/<your-user>/.cloudflared/<your-tunnel-uuid>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404

The final catch‑all rule returns a 404 for unmatched hostnames, which is safer than accidentally proxying everything.

Step 4 — Run cloudflared as a service

Install cloudflared as a system service so it survives reboots and restarts automatically.

# From within the directory containing ~/.cloudflared/config.yml
sudo cloudflared service install

# Start and enable on boot
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

If you prefer foreground mode for testing, you can run: cloudflared tunnel run homelab-tunnel, then switch to the service after you confirm it works.

Step 5 — Secure the app with Cloudflare Zero Trust Access

With the tunnel working, the app is reachable at your hostname. Next, lock it behind identity-aware access.

1) In the Cloudflare dashboard, go to Zero Trust → Access → Authentication and add an identity provider (Google, Microsoft, GitHub, or email OTP). Keep One-time PIN enabled for easy onboarding.

2) Go to Zero Trust → Access → Applications → Add an application → Self-hosted. Enter:

- Application name: Homelab App

- Domain: app.example.com

- Session duration: e.g., 12 hours

3) Create a policy: Include only your email(s) or a Google Workspace group. Optionally add country restrictions, device posture checks, or require MFA. Save the app.

From now on, anyone visiting app.example.com must authenticate. Cloudflare enforces the policy before traffic touches your origin.

Optional hardening

- Run your local service on 127.0.0.1 so it is not exposed on the LAN. Update your app config to bind to localhost.

- Use mTLS origin authentication (Cloudflare Origin Cert) to ensure only your tunnel can reach the service.

- Split production and testing into separate tunnels with distinct hostnames and policies.

- Enable HTTP/2 or WebSockets if your app needs them; cloudflared supports both.

Troubleshooting tips

- Check logs: journalctl -u cloudflared -f shows real-time output from the service.

journalctl -u cloudflared -n 200 --no-pager
cloudflared tunnel list
cloudflared tunnel info homelab-tunnel
cloudflared tunnel ingress validate

- DNS not resolving? Confirm the CNAME record for app.example.com exists and points to your tunnel. Clear local DNS cache or wait a few minutes for propagation.

- 502/504 errors? Ensure the local app is listening and reachable at the service URL in config.yml. Try curl http://localhost:8080 from the server.

- Multiple apps? Add more hostname blocks under ingress and create matching Access apps.

Maintenance and updates

Keep cloudflared current to receive security patches and new features.

sudo apt update
sudo apt install --only-upgrade cloudflared

Back up ~/.cloudflared/ (credentials and config) and your systemd unit files if customized. If you rotate the tunnel credentials, update the credentials-file path accordingly and restart the service.

Wrap-up

Cloudflare Tunnel gives you a secure, low-friction way to publish internal services without opening ports or managing a reverse proxy on the perimeter. Pairing it with Zero Trust Access means your apps live behind identity, not just IP addresses, and you can layer device posture, MFA, and short sessions. In a few commands, you can make your home lab or small business apps safer and easier to reach from anywhere.

Overview

Cloudflare Tunnel lets you expose private services to the internet without opening inbound firewall ports or managing a reverse proxy. It establishes an outbound-only, encrypted connection from your host to Cloudflare’s edge, and pairs perfectly with Cloudflare Zero Trust Access for SSO, device checks, and detailed auditing. In this tutorial, you will deploy Cloudflare Tunnel with Docker, route multiple apps under different subdomains, and protect them with Zero Trust policies. The steps are simple, reproducible, and friendly to environments behind NAT or CGNAT.

Prerequisites

- A Cloudflare account with a domain managed by Cloudflare DNS.

- Docker and Docker Compose v2 on a Linux host (Ubuntu/Debian/Alpine are fine).

- At least one internal web service running in Docker or on the host (e.g., Grafana on port 3000, Nextcloud on 80, Syncthing on 8384).

- Optional but recommended: an identity provider (Google, GitHub, Azure AD, Okta) to enforce SSO via Zero Trust Access.

Step 1 — Create a Tunnel in Cloudflare Zero Trust

1) Go to Cloudflare dashboard > Zero Trust > Access > Tunnels and click “Create a tunnel.” Name it (e.g., home-net).

2) Choose the Docker option. Cloudflare will generate a TUNNEL_TOKEN for you. Keep this token safe; it lets cloudflared authenticate the tunnel without storing local credentials.

3) You can add “Public Hostnames” later in the dashboard, or define routing via a local config file. This guide shows both approaches, starting with the fast token-only method.

Step 2 — Fast Deploy with Docker Compose (Token Method)

Create a directory (e.g., /opt/cloudflared) and a Docker Compose file. Replace TUNNEL_TOKEN_VALUE with the token you copied in Step 1.

version: "3.8"
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=TUNNEL_TOKEN_VALUE
    # Optional metrics for monitoring
    # ports:
    #   - "2000:2000"
    # command: tunnel --no-autoupdate run --metrics 0.0.0.0:2000

Bring it up:

docker compose up -d

Cloudflared will dial out to Cloudflare’s edge over QUIC/TLS. No inbound ports are needed. Next, from the Zero Trust dashboard, add “Public Hostnames” for each app:

- grafana.example.com → http://localhost:3000 (or your internal service URL)

- files.example.com → http://localhost:80

- sync.example.com → http://localhost:8384

Cloudflare automatically creates DNS records for these hostnames and routes traffic through the tunnel.

Step 3 — Config-Driven Ingress (Advanced, Reproducible)

If you prefer everything as code, create a named tunnel and a local config file. This offers better portability and version control. First, create the tunnel credentials once on any machine (can be the same host):

# Authenticate and create a named tunnel (locally)
docker run --rm -it \
  -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel login

docker run --rm -it \
  -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel create home-net

# Show tunnels (note the Tunnel UUID)
docker run --rm -it \
  -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel list

This creates a credentials file named after the tunnel UUID. Now write config.yml in the same directory:

# ~/.cloudflared/config.yml
tunnel: HOME_NET_TUNNEL_UUID
credentials-file: /home/nonroot/.cloudflared/HOME_NET_TUNNEL_UUID.json
ingress:
  - hostname: grafana.example.com
    service: http://grafana:3000
  - hostname: files.example.com
    service: http://nextcloud:80
  - hostname: sync.example.com
    service: http://syncthing:8384
  - service: http_status:404
protocol: quic
warp-routing:
  enabled: false

If your apps run in Docker, place cloudflared on the same user-defined network so it can reach them by container name. Example Compose:

version: "3.8"
networks:
  apps:
    driver: bridge

services:
  grafana:
    image: grafana/grafana:latest
    networks: [apps]
    expose:
      - "3000"
    environment:
      - GF_SERVER_ROOT_URL=http://grafana.example.com

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    networks: [apps]
    volumes:
      - ~/.cloudflared:/home/nonroot/.cloudflared:ro

Finally, register DNS routes (one-time):

docker run --rm -it \
  -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel route dns home-net grafana.example.com

docker run --rm -it \
  -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel route dns home-net files.example.com

docker run --rm -it \
  -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel route dns home-net sync.example.com

Step 4 — Protect with Zero Trust Access

Go to Zero Trust > Access > Applications > Add an application > Self-hosted. For each hostname you exposed, create an app and a policy:

- Choose your subdomain (e.g., grafana.example.com) and path (/*).

- Set a policy that requires SSO (Google/GitHub/Azure AD/Okta) or One-Time Pin.

- Optionally restrict to emails ending with @yourcompany.com or specific GitHub teams.

- Enable device posture checks if you use Cloudflare WARP (e.g., only allow managed devices).

With Access policies enforced, even if a URL leaks, visitors must authenticate before the origin sees any traffic.

Troubleshooting Tips

- 502/504 on a hostname: verify the upstream address in config points to a reachable service (container name + port or localhost + port). If using Docker networks, ensure both services share the same network.

- DNS not resolving: confirm the tunnel is “Healthy” and that the DNS record exists in your Cloudflare DNS zone. Propagation is usually instant because the record is proxied.

- Large uploads: consider enabling chunked uploads or tuning upstream app limits (e.g., client_max_body_size for Nginx-based apps). Cloudflare supports HTTP/2/3 on the edge; the tunnel runs over QUIC by default.

- Conflicting ports: cloudflared does not require inbound ports. If you exposed metrics on 2000, make sure it doesn’t collide with other services.

Security and Operations Best Practices

- Principle of least privilege: restrict Access policies to known users or groups; avoid wildcard “Allow all.”

- Separate hostnames for admin panels and public apps. Apply stricter policies (MFA, device checks) to admin endpoints.

- Use config as code where possible. Commit your cloudflared config.yml to a private repo and use environment-specific files for staging/production.

- Monitor tunnel health: expose metrics (–metrics 0.0.0.0:2000) and scrape with Prometheus. Alert on disconnects or high reconnect counts.

- Keep images updated: pin to a recent cloudflared tag and schedule updates. Test changes in staging first.

Wrap-Up

You deployed Cloudflare Tunnel with Docker, routed multiple internal services under friendly subdomains, and enforced Zero Trust Access in front of them—without opening a single inbound port. This pattern scales from homelabs to production, simplifies TLS and DNS, and raises your security baseline with SSO, device posture, logging, and revocation. If you outgrow manual steps, codify everything with config.yml, Compose files, and IaC for a repeatable, auditable setup.