This note came from a cluster environment where I needed a Cloudflare tunnel in place quickly and did not want to expose services directly while everything else was still being assembled.

The Basic Setup

Install the Debian package:

1
2

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

Then install the tunnel service with the provided token:

1

sudo cloudflared service install <cloudflare-tunnel-token>

Why This Note Also Included Certificates

The original note also bundled a certbot DNS-01 command for related cluster hostnames.

That is a useful reminder that tunnel setup and certificate operations often travel together operationally, even when they are not the same task.

In a cleaned-up form, that certificate pattern looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

docker run --rm \
  --mount type=bind,source=/root/.cloudflare.ini,target=/opt/certbot/.cloudflare.ini,readonly \
  -v /etc/letsencrypt:/etc/letsencrypt \
  certbot/dns-cloudflare certonly \
  --email [email protected] \
  --agree-tos --no-eff-email \
  --dns-cloudflare \
  --dns-cloudflare-credentials /opt/certbot/.cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d cluster-dev.example.com \
  -d cluster-staging.example.com \
  -d cluster-preprod.example.com

What I Would Add Later

This draft still needs a second pass with more of the networking context restored:

  • what service or services the tunnel exposed
  • whether the tunnel terminated on a VM or in Kubernetes
  • what the operational benefit was compared to direct ingress

For now, this is enough to keep the setup pattern in the review queue.