DevOps

Securing Clawdbot with Cloudflare Tunnel and Zero Trust

Best practices for securing self-hosted Clawdbot deployments using Cloudflare Tunnel for external access and Zero Trust Access for authentication.

February 23, 2026
6 min read
By ClawList Team

Securing Your Self-Hosted Clawdbot with Cloudflare Tunnel and Zero Trust Access

Category: DevOps | Published: March 4, 2026


If you've deployed Clawdbot on a home server or a Mac Mini sitting on your desk, you've already taken a meaningful step toward owning your AI automation stack. But exposing that service to the outside world — or even leaving it accessible only on your local network — introduces real security risks that are easy to overlook when you're excited about getting things running.

The good news: Cloudflare offers two free tools that, used together, give your self-hosted Clawdbot deployment a production-grade security layer without requiring you to touch a single firewall rule or pay a dollar. This guide walks through using Cloudflare Tunnel for secure external access and Cloudflare Zero Trust Access for identity-based authentication.

Credit to @jason5ng32 for surfacing this practical tip.


The Problem: Self-Hosted Services Are Exposed by Default

When you run Clawdbot locally — whether on a Mac Mini in your home office or a VPS — it typically listens on a local port like http://localhost:3000. To reach it remotely, most developers resort to one of these approaches:

  • Opening a port on their router (port forwarding)
  • Running a reverse proxy with a public IP
  • Using a VPN to tunnel back home

Each of these options has significant downsides. Port forwarding exposes your home IP directly to the internet. A self-managed reverse proxy requires you to handle TLS certificates, keep software patched, and manage access control yourself. VPNs work, but they're friction-heavy and don't scale well if you want to share access with teammates or clients.

There's also a subtler risk: no authentication layer. If someone discovers your Clawdbot endpoint, there's nothing stopping them from interacting with it unless you've explicitly built auth into your setup.

Cloudflare Tunnel + Zero Trust Access solves all of this cleanly.


Step 1: Cloudflare Tunnel — Expose Your Service Without Opening Ports

Cloudflare Tunnel (formerly Argo Tunnel) creates an outbound-only encrypted connection from your machine to Cloudflare's edge network. Your server initiates the connection, so there's no need to open inbound ports, configure NAT, or expose your home IP address.

How It Works

The cloudflared daemon runs on your Mac Mini or server, maintaining a persistent tunnel to Cloudflare. When someone requests your configured subdomain (e.g., clawdbot.yourdomain.com), Cloudflare routes that traffic through the tunnel to your local service.

Setting It Up

1. Install cloudflared

# macOS (Homebrew)
brew install cloudflared

# Linux (Debian/Ubuntu)
curl -L https://pkg.cloudflare.com/cloudflared-stable-linux-amd64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb

2. Authenticate with your Cloudflare account

cloudflared tunnel login

This opens a browser window where you authorize cloudflared to manage your domain.

3. Create a named tunnel

cloudflared tunnel create clawdbot-tunnel

4. Configure the tunnel

Create a config file at ~/.cloudflared/config.yml:

tunnel: clawdbot-tunnel
credentials-file: /Users/yourname/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: clawdbot.yourdomain.com
    service: http://localhost:3000
  - service: http_status:404

5. Route DNS and start the tunnel

cloudflared tunnel route dns clawdbot-tunnel clawdbot.yourdomain.com
cloudflared tunnel run clawdbot-tunnel

To run it as a persistent background service on macOS:

sudo cloudflared service install

At this point, clawdbot.yourdomain.com is publicly reachable over HTTPS — but still open to anyone who knows the URL. That's where Zero Trust Access comes in.


Step 2: Cloudflare Zero Trust Access — Add an Identity Layer

Cloudflare Zero Trust Access sits in front of your tunnel and requires users to authenticate before they can reach your Clawdbot instance. You can gate access using Google, GitHub, email OTP, or a range of other identity providers — all without writing a single line of auth code.

This is the Zero Trust model in practice: never trust, always verify. Even if someone knows your subdomain, they hit an authentication wall before any traffic reaches your service.

Configuring Access in the Cloudflare Dashboard

  1. Go to one.dash.cloudflare.com and select your account.
  2. Navigate to Access → Applications → Add an Application.
  3. Choose Self-hosted.
  4. Set the Application domain to clawdbot.yourdomain.com.
  5. Under Policies, define who can access it:
Policy name: Team Access
Action: Allow
Include: Emails ending in @yourcompany.com

Or for personal use:

Policy name: Personal Access
Action: Allow
Include: Email — [email protected]
  1. Choose an Identity Provider (Google OAuth is the easiest to configure).
  2. Save and deploy.

Now, any request to clawdbot.yourdomain.com first hits Cloudflare's Access login page. Only users matching your policy rules get through. Everyone else sees a 403.

What This Looks Like for the End User

When you visit clawdbot.yourdomain.com for the first time, you're redirected to a Cloudflare-hosted login page. After authenticating with your configured identity provider, Cloudflare issues a short-lived JWT stored in a cookie. Subsequent requests are validated against that token — no repeated logins needed within the session window.

For API-based access (e.g., calling Clawdbot programmatically), you can use Cloudflare Access Service Tokens — client ID/secret pairs that bypass the browser login flow:

curl https://clawdbot.yourdomain.com/api/endpoint \
  -H "CF-Access-Client-Id: your-client-id" \
  -H "CF-Access-Client-Secret: your-client-secret"

Why This Combination Works So Well

Using Cloudflare Tunnel and Zero Trust Access together gives you a layered security posture that's genuinely difficult to replicate with self-managed tooling:

  • No exposed ports or public IP: Your home network or private server stays dark to port scanners.
  • TLS by default: All traffic is encrypted end-to-end through Cloudflare's edge without managing certificates yourself.
  • Identity-based access control: Authentication is handled at the network edge before traffic reaches your application.
  • Audit logs: Cloudflare logs every access attempt, giving you visibility into who is accessing your Clawdbot instance and when.
  • Zero infrastructure cost: The free tier of Cloudflare Tunnel and Zero Trust Access handles up to 50 users — more than sufficient for personal or small team deployments.

This setup is particularly valuable for Clawdbot deployments that interact with sensitive workflows, API keys, or internal data sources. The last thing you want is an unauthenticated endpoint that can trigger AI automation tasks on your behalf.


Conclusion

Self-hosting Clawdbot gives you control and flexibility that SaaS solutions can't match. But control comes with responsibility — and securing your deployment doesn't have to be complicated or expensive.

Cloudflare Tunnel removes the need to expose your network. Zero Trust Access adds a robust authentication layer in front of it. Together, they take a potentially vulnerable local service and wrap it in the kind of security posture that most teams would pay significant money to achieve.

Both tools are free. Both are well-documented. There's no good reason not to use them.

If you're running Clawdbot on a Mac Mini at home or a personal server in the cloud, this two-step setup should be on your deployment checklist before you do anything else.


Original tip via @jason5ng32 on X. For more guides on self-hosting AI automation tools, explore the ClawList.io developer hub.

Tags

#cloudflare#security#self-hosted#clawdbot#zero-trust

Related Articles