Your Cloudflare Stack, Explained

A small program that runs on Cloudflare's global network instead of on any single server. Think of it as a tiny always-on receptionist with a public phone number: https://ruprecht-gateway.cbj1977.workers.dev. It answers requests instantly from whichever Cloudflare location is closest to whoever's asking. Right now it has 4 jobs: (1) /health — say 'I'm alive', (2) POST /events — accept an incoming webhook/notification from anywhere on the internet and save it, (3) /tasks — create, list, and update to-do items, (4) enforce a secret password (X-Auth-Token) on everything except the health check and incoming webhooks. This is the 'front door' — the one thing on this whole list that's actually reachable from the public internet right now.

A real SQL database (SQLite-flavored) that Cloudflare hosts and replicates for you — no server to maintain, no backups to think about. It currently has two tables: 'events' (a running log of things that happened — right now just my test pings) and 'tasks' (a to-do list with status tracking: pending/done/etc). This is the memory the Worker Gateway writes to. If nothing else existed, this alone would let any script anywhere log 'X happened' and have it durably saved.

A simple, extremely fast key-value store — like a giant always-available dictionary (name → value) that any Worker can read from in under a millisecond. Currently empty and unused. Good future use: caching, feature flags, rate-limit counters, or small bits of state that don't need full SQL. It's already wired into the gateway, just nothing's using it yet.

A private, outbound-only encrypted connection from your Unraid home server (terramaster) out to Cloudflare's network. No open ports on your router, no port forwarding, no exposing your home network directly to the internet — the tunnel calls out to Cloudflare, not the other way around. Right now it's connected and healthy (confirmed via QUIC handshake) but has zero routing rules configured — it's a bridge with nothing walking across it yet. Once we add routing rules, this becomes the way to safely expose an internal Unraid service (like Sonarr, a dashboard, or a private API) to the outside world without opening your firewall.

Cloudflare's free authentication layer — the ability to put a login wall (Google/GitHub/email OTP) in front of any URL before Cloudflare even lets the request through to the actual service. You enabled this today. Currently has zero apps configured, meaning it's not protecting anything yet. Useful next step: wrap an internal dashboard or admin page with 'you must log in with your email' before it's reachable, without writing any auth code yourself.

Cloudflare's version of 'a big bucket to dump files in' — similar to Amazon S3, but with zero data-transfer-out fees, which is the whole reason it's worth using over alternatives. You enabled this today after finding the hidden 'Add R2 subscription' button. Created one empty bucket called 'ruprecht-artifacts'. Good future use: storing generated images, PDFs, large exported files, or backups that don't belong in a database or a git repo.

Right now everything lives on Cloudflare's free shared subdomains: *.workers.dev for the Worker, *.pages.dev for published pages. That's completely fine and free forever. The only reason to add a real domain (like yourdomain.com) is cosmetics (nicer URLs) or if we want the Tunnel to expose a service at a specific hostname. Zero urgency — flagged for later, not blocking anything today.

Right now only I've sent it test pings. The real payoff comes from wiring something real into it - e.g. an Unraid *arr-stack event, an n8n workflow, or a cron heartbeat that reports 'still alive' every hour.

The Unraid bridge is connected but idle. We could expose one internal service (like a dashboard) through it safely, with Zero Trust login in front of it.

Unless you specifically want prettier URLs, there's no reason to add one - it requires changing your domain's nameservers, which is a bigger commitment than anything above.