Building Cloudflare Tunnel access to our homelab staging so the team stops saying "works on my machine"

Our k3s staging cluster runs on a mini PC in my home office. For six months, the team accessed it through a WireGuard VPN that I managed manually. The VPN dropped connections every 20 minutes on certain ISPs, required configuration files that had to be regenerated whenever someone got a new laptop, and did not work at all from coffee shops with aggressive NAT. The result was that nobody used staging unless absolutely necessary, which defeated the entire purpose of having a staging environment.

Generate a realistic homelab editorial photo: compact rack, mini PCs, blinking LEDs, labeled cables, dark room, teal and tungsten lighting, 16:9, no people, no pristine showroom look.

The kind of infrastructure that teaches you by breaking.

This is where the homelab stopped being a hobby and started acting like a leadership tool. It also builds on what I learned earlier in “TypeScript strict mode migration: the six-month project I wish I had done in month one.” The infrastructure and ctrlpane work gave me a cheap place to pressure-test release habits, GitOps discipline, and failure modes before I asked the team to trust those defaults at work.

Editorial supporting image for the section "Why Cloudflare Tunnels" in the article "Building Cloudflare Tunnel access to our homelab staging so the team stops saying "works on my machine"". Show mini PC rack, patch cables, terminal windows, Grafana-style dashboard glow, labeled hardware with signs of real use for "Building Cloudflare Tunnel access to our homelab staging so the team stops saying "works on my machine"". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: teal, zinc, dim server LEDs, warm tungsten accents. Mood: tense but controlled, operational, carrying team and system weight at the same time. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No spotless enterprise data-center stock photos, no blue LED overkill, no clip-art servers, no text overlays.

The infrastructure mess that made the lesson stick.

Why Cloudflare Tunnels

Cloudflare Tunnels solve the problem of exposing services running behind NAT without opening ports or managing VPN infrastructure. A lightweight daemon called cloudflared runs on your network, establishes an outbound connection to Cloudflare edge, and routes traffic to your internal services. No inbound ports. No static IP required. No VPN client installation.

The key advantage for a homelab staging environment is that the team accesses staging the same way they access production: through HTTPS on a real domain. There is no VPN to connect, no special client to install, and no configuration that varies by ISP or network. If you can access the internet, you can access staging.

The security model is also cleaner than VPN. With a VPN, anyone who has the configuration file has network-level access to everything on my home network. With Cloudflare Tunnels, access is scoped to specific hostnames routing to specific services. The tunnel only exposes what I explicitly configure. My home network stays private.

The Setup

The entire setup took about two hours including DNS configuration, tunnel creation, and access policy setup.

# Install cloudflared on the k3s node
curl -L --output cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

# Authenticate with Cloudflare
cloudflared tunnel login

# Create the tunnel
cloudflared tunnel create staging-homelab

# Configure the tunnel routes
# config.yml:
tunnel: <tunnel-id>
credentials-file: /root/.cloudflared/<tunnel-id>.json
ingress:
  - hostname: staging.financeops.internal
    service: http://localhost:80
  - hostname: staging-api.financeops.internal
    service: http://localhost:3000
  - hostname: argocd.financeops.internal
    service: https://localhost:8443
    originRequest:
      noTLSVerify: true
  - service: http_status:404

Each service running on the k3s cluster gets its own hostname. The nginx ingress controller on the cluster routes traffic based on the hostname, so the tunnel only needs to forward to the ingress on port 80. ArgoCD runs its own TLS, so it gets a direct route with TLS verification disabled for the internal hop.

staging.financeops.internal routes to the main application
staging-api.financeops.internal routes to the API service
argocd.financeops.internal routes to the ArgoCD dashboard
All three are accessible via HTTPS with Cloudflare-managed certificates

Access Control

Exposing staging services on the internet requires access control. We use Cloudflare Access to require authentication before any request reaches the tunnel. The policy requires either a company email domain or a one-time PIN sent to an approved email address.

Access Policy: staging-homelab
  Action: Allow
  Include:
    - Email domain: financeops.com
  Require:
    - Email OTP verification
  Session duration: 24 hours

When an engineer navigates to staging.financeops.internal, Cloudflare Access intercepts the request and presents a login page. The engineer enters their email, receives a one-time code, and after verification gets a 24-hour session cookie. No VPN client. No configuration file. No port forwarding. Just a browser and a company email address.

The session duration of 24 hours was a deliberate choice. Engineers check staging once or twice during a work day. A 24-hour session means they authenticate once in the morning and do not need to re-authenticate for the rest of the day. The VPN had a 20-minute timeout that required re-authentication, which was the single most complained-about aspect of the old setup.

Running as a Kubernetes Deployment

For reliability, cloudflared runs as a Kubernetes deployment on the k3s cluster rather than as a system service. This means it benefits from Kubernetes health checks, automatic restarts, and rolling updates.

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: cloudflared
5
  namespace: cloudflare
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: cloudflared
11
  template:
12
    spec:
13
      containers:
14
        - name: cloudflared
15
          image: cloudflare/cloudflared:latest
16
          args:
17
            - tunnel
18
            - --config
19
            - /etc/cloudflared/config.yml
20
            - run
21
          volumeMounts:
22
            - name: config
23
              mountPath: /etc/cloudflared
24
              readOnly: true

The Impact

Within a week of deploying the tunnel, staging usage went from sporadic to daily. Engineers started deploying feature branches to staging before opening PRs. QA testing moved from local machines to staging. Cross-browser testing happened on the actual deployment instead of on localhost with different configurations.

Create a realistic infrastructure editorial image with a homelab rack and nearby monitoring screen, subtle Grafana-like charts, dark graphite and green palette, 4:3, no branded UI, no stock-photo polish.

Homelab, but treated like a real environment.

By this stage the job had changed. I was no longer just picking a tool or fixing a bug. I was carrying the blast radius across product, compliance, sales, and hiring. That is exactly why I kept pressure-testing the same lesson inside infrastructure and ctrlpane.

The best infrastructure is infrastructure nobody has to think about. The VPN required thinking about credentials, connections, and troubleshooting. The Cloudflare Tunnel requires typing a URL. When accessing staging is as easy as accessing any website, engineers will actually use staging. That is the point.

Total cost: zero. Cloudflare Tunnels are free. Cloudflare Access is free for up to 50 users. The two-hour setup replaced a VPN infrastructure that consumed several hours per month in maintenance and support. If you are running a homelab staging environment and your team is not using it because access is painful, Cloudflare Tunnels is the fix.