This post is the other order. The service keeps running on the machine it was built on, and a Cloudflare Tunnel gives it a public HTTPS hostname. Nothing on the laptop listens to the internet: no port forwarding, no router settings, no exposed IP address. The machine dials out to Cloudflare, and Cloudflare sends requests back down that connection. The tunnel is free, and the TLS certificate, DDoS protection and caching come with the Cloudflare zone you probably already have.

The example is real. One of my products runs on Fly.io, and its mobile app gets over-the-air JavaScript updates from the backend (self-hosted Expo Updates). I wanted a second copy of that update server running on my Mac for development builds, with production left exactly as it was. The outputs below are from that afternoon, including the part where it didn’t work.

What a Cloudflare Tunnel actually is

#

A normal server waits for connections. To reach a laptop from the internet, you’d have to open a port on your router, forward it to the laptop, and hope your ISP gives you a public IPv4 address (in a lot of places, mine included, it doesn’t). Then everything listening on that port is reachable by every scanner on the internet, all day.

A tunnel turns that around. cloudflared runs next to your app and opens outbound connections to Cloudflare’s edge, four of them to two nearby data centres. A DNS record in your zone points a hostname at the tunnel. When a request arrives for that hostname, Cloudflare terminates TLS and forwards the request down one of those connections. cloudflared then hands it to whichever local service your config names.

For security, the important part is that your router has no inbound rule and your IP address never appears in DNS. Someone scanning your home connection finds nothing, because nothing on it is listening.

Setting up cloudflared, start to finish

#

You need a domain on Cloudflare (the free plan is enough) and cloudflared installed (brew install cloudflared on a Mac).

1. Log in once. This opens a browser, you pick the zone, and it saves a certificate that lets this machine create tunnels and DNS records in that zone:

cloudflared tunnel login

2. Create the tunnel. I keep everything for this project in its own folder, because the credentials file is the tunnel’s identity: anyone who has it can serve traffic for your hostnames.

mkdir -p ~/.cloudflared/myapp && cd ~/.cloudflared/myapp
cloudflared tunnel create --credentials-file ./creds.json myapp-local
chmod 600 creds.json

Tunnel credentials written to ./creds.json. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel myapp-local with id 1ade030c-…

3. Point hostnames at it. One command per hostname creates a proxied CNAME to <tunnel-id>.cfargotunnel.com:

cloudflared tunnel route dns myapp-local ota.example.com
cloudflared tunnel route dns myapp-local checkin-local.example.com

4. Write the ingress rules. This is the part that matters for security, so it gets its own section below.

5. Run it. My app already runs under Docker Compose, so cloudflared is one more container on the same network. It reaches the app by service name, and the app doesn’t need a port published on the host at all:

# compose.tunnel.yml, used alongside the project's docker-compose.yml
services:
  cloudflared:
    image: cloudflare/cloudflared:2026.10.7
    command: tunnel --config /etc/cloudflared/config.yml run
    volumes:
      - ${HOME}/.cloudflared/myapp:/etc/cloudflared:ro
    restart: unless-stopped
    depends_on: [api, edge]

docker compose -f docker-compose.yml -f ~/.cloudflared/myapp/compose.tunnel.yml up -d cloudflared

INF Registered tunnel connection connIndex=0 … location=icn06 protocol=quic
INF Registered tunnel connection connIndex=1 … location=icn07 protocol=quic
INF Registered tunnel connection connIndex=2 … location=icn07 protocol=quic
INF Registered tunnel connection connIndex=3 … location=icn06 protocol=quic

Four connections to Seoul, and the laptop is on the internet, from the outside in. restart: unless-stopped brings it back after a reboot as soon as Docker starts.

Expose paths, not servers

#

This is the mistake I nearly made, and I’d guess it’s the most common one. The easy config is a single line: hostname → http://localhost:8000. That publishes the whole development server.

Development servers aren’t built for that. Mine runs with DEBUG=True, which shows full tracebacks and settings on any error. It also runs with authentication switched off (AUTH_MODE=disabled), so that any bearer token logs you in as a test user. That’s exactly right on localhost and a disaster on a public hostname. Yours probably has something similar: an admin with a default password, a seeding endpoint, a debug toolbar, or an API that trusts its caller because only you ever call it.

So the tunnel config is an allowlist. cloudflared checks each request against the ingress rules in order, by hostname and by a regular expression on the path. The first match wins, and the last rule catches everything else:

tunnel: myapp-local
credentials-file: /etc/cloudflared/creds.json

ingress:
  # OTA: the two read-only endpoints the phone calls, and the files they link.
  - hostname: ota.example.com
    path: ^/api/expo-updates/(manifest|status)/$
    service: http://api:8000
  - hostname: ota.example.com
    path: ^/media/
    service: http://api:8000
  # Device check-ins, authenticated by each device's own key.
  - hostname: checkin-local.example.com
    path: ^/c/$
    service: http://edge:8081
  # Everything else, including /admin/ and the publish endpoint: 404 at the edge.
  - service: http_status:404

The publishing endpoint lives on the same server under the same prefix (/api/expo-updates/import-update/), and it isn’t in the list. Neither is the admin, or the rest of the API. Those requests never leave Cloudflare.

You don’t have to trust your regexes; cloudflared will tell you which rule a URL matches:

cloudflared tunnel --config config.yml ingress rule https://ota.example.com/admin/

https://ota.example.com/api/expo-updates/manifest/        service: http://api:8000
https://ota.example.com/api/expo-updates/import-update/   service: http_status:404
https://ota.example.com/admin/                            service: http_status:404
https://ota.example.com/media/expo-updates/x.js           service: http://api:8000
https://checkin-local.example.com/c/                      service: http://edge:8081
https://checkin-local.example.com/health                  service: http_status:404

I’d put that check in a script and run it every time the config changes. It takes seconds, and a regex that matches more than you meant is the kind of mistake you only find out about from someone else.

Two more rules of thumb:

• What you expose should authenticate itself. The OTA endpoints serve public, read-only data. Device check-ins are signed with per-device keys. Neither one depends on the network to keep it safe. If you want to show someone a page that has no login, put Cloudflare Access in front of that hostname (free for up to 50 users) instead of building a login.
• Don’t run the tunnel as a background part of your dev workflow. Run it on purpose, for the hostname you mean, and stop it when you’re done. docker compose stop cloudflared takes everything off the internet in one command.

The redirect that ate my hostnames

#

With the tunnel connected and the rules verified, I tried it from outside:

https://ota.example.com/api/expo-updates/status/?…   301
https://ota.example.com/api/expo-updates/manifest/   301
https://ota.example.com/admin/                       301
https://checkin-local.example.com/c/                 301

Every path returned the same 301, including ones the tunnel should have answered with 404. That means the request never reached cloudflared. The Location header said https://www.example.com/, and the server: cloudflare header settled it: Cloudflare was answering on its own.

I’d done this to myself. Months ago I added a zone-level redirect rule, “any other subdomain → www”, as a sinkhole for scanners that walk invented subdomains. Redirect rules run in Cloudflare’s request pipeline before the request is sent to the origin, and a tunnel is just an origin. The same rule caught my preview environments before Workers could see them. The fix is the same as last time: one more exception in the rule’s expression.

… and not http.host in {"ota.example.com" "checkin-local.example.com"}

If your tunnel hostname answers with a redirect or an error page from Cloudflare instead of your app, check Rules → Redirect Rules, Page Rules and any WAF custom rules for the zone before you debug the tunnel. cloudflared logs every request it forwards, so an empty log means the request never got that far.

What it can’t do

#

• UDP from the public internet. Public tunnel hostnames carry HTTP(S) (plus WebSockets and gRPC). My product’s devices normally check in over CoAP on UDP, and that can’t go through a tunnel; the devices on the local copy fall back to HTTPS check-ins, which cost them a few seconds on each one. If your idea is a game server or VoIP, a tunnel isn’t the tool.
• Uptime. It’s your laptop. Close the lid and the site is down; Cloudflare shows a 530 error page. That’s fine for a demo, a beta with ten people, or a staging copy. It isn’t fine for anything someone depends on.
• Things baked into a build. A mobile app’s update URL is native config, so only builds made with the tunnel’s URL use it. My store builds keep talking to production, and that’s why this setup was safe to try.

The cost: is Cloudflare Tunnel free?

#

A Cloudflare zone on the free plan, the tunnel, its certificate, and the DNS records: $0. The machine was already running. The only real cost is that you’re now the uptime team.

What it saves you is the phase between “it works on my machine” and “it’s worth paying to host”. You can send a link to a tester, a designer or a first customer the same afternoon. If nobody cares, you’ve lost nothing. If they do, moving to a real host is one change: point the CNAME somewhere else.

My working setup is three machines that are rarely in the same place. There’s a MacBook Air, which goes wherever I go. There’s a workstation in the office called devbox, with a real GPU, which runs Ollama, my fine-tuning tools, a small Kubernetes cluster with its own container registry, and whatever agent I’ve left grinding through a long job. And there’s my phone, which is where the apps I build actually get used, and which spends most of its day on mobile data rather than wifi.

For a long time those three didn’t really talk to each other. The laptop could reach devbox when it was on the office LAN and not otherwise. The phone could reach my laptop’s dev server when both were on the same wifi, and then only if I remembered to bind to 0.0.0.0 and typed in whatever DHCP had given the Mac that morning. Everything interesting on the workstation, the Ollama API, the cluster dashboards, the traces, the registry, was bound to localhost or to the cluster network, deliberately, because none of it belongs on the internet.

This post is how I joined them up with Cloudflare WARP and a pair of Cloudflare Tunnels, what it changed about how I build AI features and mobile apps, and the handful of things that broke without telling me.

What I actually wanted

#

Stated as requirements, it’s short:

1. The laptop should be a thin client. Anything that needs a GPU, a lot of RAM or hours of runtime should run on devbox, and the laptop should reach it the same way from the office, from home and from a café.
2. The phone should reach my dev servers and my shells from anywhere, on mobile data, without a VPN I have to remember to switch on and off.
3. The things I use to see how a system is behaving, dashboards, traces, docker info, model lists, should be reachable by me and nobody else, and should never get a public URL.
4. No inbound ports. Not on the office router, not on my home router, not anywhere.

The fourth one rules out the old answer, which is a port forward and a dynamic DNS name. It also rules out a lot of cleverness: both devbox and my laptop sit behind NAT I don’t control, and the laptop is behind a different NAT every few hours.

Before: a repo of SSH tunnels

#

The first version of this was a small repo of my own, and it’s still the base layer. It solves the “clean names for things I reach over SSH” problem on the laptop and nothing more. dnsmasq answers *.test with 127.0.0.1, Caddy routes by hostname to a local port with tls internal so the browser is happy, and a set of autossh launch agents hold the SSH forwards open and reconnect when they drop. The hostnames say where a thing lives:

So https://devbox-ollama.ssh.test/api/tags lists the models on the workstation, and https://api.local.test is the API of the app I’m working on, running on my own machine.

Subdomains of .test, not new top-level names like .ssh or .cloud, and not .local. RFC 6761 reserves .test for exactly this, and .local belongs to mDNS; take it over and Bonjour discovery stops working on your Mac. dnsmasq already wildcards the whole of *.test, so the extra label costs nothing: one /etc/resolver/test file pointing at 127.0.0.1 and no further DNS changes, ever.

HTTPS on names that don’t exist

#

Every one of those names is served over HTTPS with a certificate the browser trusts, which sounds impossible for a hostname that exists only on my laptop. Caddy does it with its own internal certificate authority. tls internal on a site tells Caddy to issue that site’s certificate from a local CA instead of asking Let’s Encrypt, and caddy trust, run once by the installer, puts the CA’s root into the macOS System keychain (Chrome and Safari read it) and into Firefox’s own store. From then on https://anything.test opens with no certificate warning, plain http:// redirects to it, and nothing leaves the machine.

It isn’t just cosmetic. A lot of the web platform now refuses to work on plain HTTP: secure cookies, service workers, the clipboard API, anything with SameSite=None. Testing a web build on plain http://localhost hides the bugs that show up on the real HTTPS domain. Testing on https://app.local.test surfaces them on my laptop instead.

A site block, which is the same for every service apart from the port:

devbox-ollama.ssh.test, devbox-ollama.test {
	tls internal
	import cors
	reverse_proxy 127.0.0.1:11435 {
		import proxyhdr
		transport http {
			keepalive off
			dial_timeout 5s
		}
	}
}

The two snippets carry the fiddly parts. cors reflects the caller’s Origin back rather than sending *, because * isn’t allowed once credentials are involved, and it answers OPTIONS preflights itself with a 204 so the upstream never has to. proxyhdr rewrites the Host header to the dial address. Fussy backends, router admin pages and Chrome’s remote-debugging endpoint among them, validate Host, and would otherwise reject devbox-ollama.ssh.test as a name they’ve never heard of. Ollama’s own origin check accepts loopback on any port, so rewriting Host to 127.0.0.1:11435 gets it through.

keepalive off is the one I’d have got wrong. The upstreams are SSH forwards that autossh tears down and rebuilds whenever the network changes. With keep-alive on, Caddy holds a pooled connection to a tunnel that has since died, and it returns baffling 404s until it’s reloaded. Off, every request dials fresh, which on loopback costs nothing measurable.

Each service also answers on its old flat name (devbox-ollama.test), so bookmarks from before the suffix scheme still work.

The menu bar

#

With a dozen forwards held open by launchd, the question I kept asking was “is it up?”, and the answer lived in three places: launchctl list, lsof and a curl. So a small menu-bar plugin puts it in one place, with a dot next to every hostname:

• 🟢 the service answered a request through the tunnel
• 🟡 the tunnel is open but the service behind it is silent
• 🔴 nothing is listening on the local port, so the tunnel itself is down

The yellow state is the useful one. A green/red check can’t tell “the SSH forward died” from “Ollama crashed on the far end”, and those have entirely different fixes. The plugin keeps no list of its own; it reads the same proxy and SSH config as everything else, so adding a service there adds it to the menu too.

The first version was greedy. It refreshed every ten seconds and spawned a few processes per service, about seventy a run, and macOS promptly listed it under “apps using significant energy”. Taking one snapshot per run and refreshing every few minutes brought it down to about 0.1% of a core. A status light that drains the battery is not helping, so it’s worth budgeting for from the start.

The whole setup had one hole, and it was the one that mattered. devbox has no public name. Its SSH forward dialled a 192.168.x address, so it only worked while the laptop was on the office LAN. Away from the office the menu bar went red and stayed red, and everything I’d moved onto the workstation to save the laptop was out of reach at exactly the times I wasn’t sitting next to it.

Two tunnels, pointing the right way

#

The fix has three parts, and the first two are Cloudflare Tunnels.

A Cloudflare Tunnel is cloudflared holding an outbound connection to Cloudflare’s edge. Cloudflare hands requests back down that connection, so a machine behind any amount of NAT gets reachable without anything listening on a router. It follows a laptop onto hotel wifi and it survives CGNAT.

I run two of them, one per machine, and the reason is worth a sentence. The obvious shortcut was a single tunnel on the laptop with one more ingress rule pointing at devbox’s SSH port on the office LAN. That needs nothing installed on devbox at all. It also routes through the laptop, and the laptop is the machine that leaves the office. It would have broken in exactly the case it existed to fix. devbox stays put, so devbox holds its own connection to the edge.

# config.yml on devbox (runs as a systemd service)
protocol: auto        # prefer QUIC, fall back to HTTP/2 over TCP 443
ha-connections: 4     # mains-powered, its job is to stay reachable

warp-routing:
  connectTimeout: 5s

ingress:
  - hostname: ssh-devbox.example.com
    service: tcp://127.0.0.1:22
  - service: http_status:404

tcp:// rather than ssh:// is an easy one to get wrong. ssh:// selects Cloudflare’s browser-rendered terminal, which wraps the stream for a web page; a normal ssh client fed through it gets the banner and then dies at key exchange. tcp:// is the plain byte pipe cloudflared access ssh expects, and as a bonus it carries scp, rsync, git over SSH and port forwards.

That last part is what closed the hole in the SSH layer. The SSH config now picks a route per connection:

Match originalhost devbox !exec "nc -z -G 1 <office-lan-ip> 22 >/dev/null 2>&1"
    ProxyCommand cloudflared access ssh --hostname ssh-devbox.example.com ...

On the office LAN the probe succeeds and SSH goes direct, one hop. Anywhere else it fails and SSH goes through Cloudflare, authenticated with an Access service token so there’s no browser login in the way. It’s Match originalhost, not Match host: host matches after HostName has been substituted, so by then the name is already an IP and the block never fires. The upshot is that devbox-ollama.ssh.test works in the office, at home and on a train, and the menu bar dot stays green.

The laptop’s tunnel goes the other direction. It gives dev servers on the Mac real public HTTPS hostnames: for each app I’m working on, its API, its WebSocket server and its web build. Every one of them sits behind Cloudflare Access, which I’ll come back to, because it’s the part that makes this safe rather than reckless.

The menu bar learned about both tunnels too, and it couldn’t do it by probing. An inbound tunnel has no local port to check, one of the two connectors doesn’t even run on the laptop, and the obvious test, curling ssh-devbox.example.com, gets an answer from Cloudflare’s edge whether or not a connector is attached, so it would read green on a dead tunnel. launchd is no better: cloudflared sits there “loaded, exit 0” with every edge connection dropped. So for tunnels the menu asks the Cloudflare API whether each one has a healthy connector, since that’s what decides whether an ssh lands. If the API can’t be reached, the section is left out rather than drawn red. The menu is read at a glance, and a false alarm there costs more than a missing line.

The third part: WARP makes it a network

#

Tunnels with hostnames are great for anything that speaks HTTPS, and for SSH from a machine that can run cloudflared. A phone can’t. And a tunnel hostname isn’t a TCP endpoint: Cloudflare’s edge only terminates HTTPS and WebSocket on it, so port 22 at ssh.example.com is closed and no amount of fiddling with Access will open it.

That’s the job for WARP. The Cloudflare One Agent (the enterprise WARP client, not the consumer “1.1.1.1” app, which can’t join an organisation) is enrolled on the laptop and the phone in my Zero Trust organisation. Each tunnel advertises private routes, and a device running WARP can then open a plain socket to those addresses and land on the right machine. It stops being “reach this service by name” and becomes “these machines are on a network with me”:

Those addresses are loopback aliases on each machine, created at boot, so they owe nothing to DHCP or whatever router I’m behind. 198.18.42.2 is devbox in the office, from home, and from a phone on 5G. The Mac’s real LAN address changes every time I move; this one never does.

The split tunnel is in include mode with only those routes in it (plus the Cloudflare ranges WARP needs for itself). That’s what makes the client liveable. The default is exclude mode, where WARP carries everything except a list of private ranges, so every byte the phone sends detours through Cloudflare. That has a real battery and latency cost, enough that I’d have ended up turning it on only when I needed it, which defeats the point. In include mode, traffic to my three machines goes through WARP and everything else goes out the normal path untouched. So the client just stays on. warp-cli status on the laptop says Connected all day and I don’t think about it.

For transport I have it on MASQUE, which is HTTP/3 on UDP 443 with an HTTP/2 fallback, rather than WireGuard on UDP 2408. Some carriers and guest networks block 2408; almost nobody blocks 443. My organisation’s policy also has post-quantum key agreement switched on for MASQUE, which I didn’t go looking for but won’t turn down.

Why 198.18, and why there’s an IPv6 address

#

The addresses look odd, and the first ones I picked were wrong in an instructive way.

My first attempt was 10.10.0.1, because that’s what you reach for. It fails in both split-tunnel modes. In exclude mode, WARP’s default list excludes every RFC 1918 range plus 100.64.0.0/10, so the client would have dropped traffic to it before it ever left the device. In include mode it would collide with any real 10.x network I happen to join; cafés, co-working spaces and plenty of offices use exactly that range. 198.18.0.0/15 is the RFC 2544 benchmarking range. It’s reserved, it’s never routed on the public internet, it isn’t in WARP’s exclude list, and no ordinary network uses it. The IPv6 addresses are ULA (fd00::/8) for the same reason.

Why there’s IPv6 at all is the more interesting story. Once the v4 address worked I tested it from the phone on wifi, it was fine, and I called it done. On 5G it didn’t work. The Agent said connected, the tunnel was healthy, Access was fine; the wifi test proved all of that. The problem was that mobile networks are mostly IPv6-only now. The phone had no native IPv4 at all and was reaching the v4 literal through the carrier’s 464XLAT translator, which sits outside the tunnel when the include list holds only a v4 prefix. The traffic went out to the public internet, where 198.18.0.0/15 doesn’t route, and was dropped without a sound. No error on the phone, nothing in the connector’s log.

The fix is to give every machine a second address the phone can reach natively over IPv6, and add it to the routes and to the include list. Now the fd12:3456:789a:: addresses are what my SSH client on the phone actually uses on mobile data.

Offloading: the laptop as a terminal

#

This is the part the whole setup exists for.

Models and fine-tuning. Ollama runs on devbox and binds to 127.0.0.1:11434. It’s invisible to the rest of the office LAN, let alone the internet. On the laptop it appears at https://devbox-ollama.ssh.test, or as a bare port for tools that want one:

OLLAMA_HOST=127.0.0.1:11435 ollama list

11435, not 11434, on purpose: 11434 is Ollama’s own default, and if the laptop ever runs a local Ollama too, the two would race for the port and I’d silently get devbox’s answers from the “local” one depending on which started first.

The practical effect is that when I’m building an AI feature, the model it calls is a workstation GPU rather than the laptop’s, from wherever I am. Evaluation runs, embedding a pile of documents, a fine-tune: they run on devbox, and the laptop’s fan stays off. When I’m prototyping an agent, it can point at a local model on the workstation and burn through tool-calling iterations without an API bill, and switch to a hosted model once the loop is right.

Long-running agents. An agent session that runs for an hour shouldn’t depend on my laptop lid staying open. Run it on devbox instead and the laptop is just a window onto it: close the lid, and later ssh devbox from wherever I am, or from the phone, and it’s still there. Before the tunnel this only worked in the office, which is exactly where I didn’t need it.

Builds and the cluster. The cluster on devbox has its own registry, so images can be built and pushed on the workstation, next to where they run, rather than uploaded over hotel wifi from a laptop. The cluster dashboard, the ingress dashboard and the registry UI are all *.ssh.test hostnames on the laptop.

The mobile loop. The phone is on the same private network as the laptop, and the laptop’s dev servers also have public hostnames behind Access. So I can take a native build of the app out of the building, on 5G, and it talks to the API running on my desk. Or it talks to the one on devbox, if that’s where I left it. The feedback loop on a real device over a real mobile network used to mean deploying to a shared staging server. Now it means saving a file.

There’s one trap here worth knowing before you debug it as an app bug. Access protects the WebSocket hostname too, and a native WebSocket client isn’t a browser. It carries no CF_Authorization cookie, so the native build’s connection to the WebSocket server is rejected at the edge with a 403 that looks nothing like an error from your own server. Browser tabs are fine because they already hold the cookie from logging in. For anything that isn’t a browser (the native app, a script, an agent calling a dev API) the answer is an Access service token, sent as two headers:

CF-Access-Client-Id:     <client_id>
CF-Access-Client-Secret: <client_secret>

The token grants nothing on its own. Access only honours it on apps whose policy names it, so its reach is exactly the list of dev hostnames and nothing wider. I file its policy under the non_identity decision rather than allow, which keeps it visible in the audit log as a bearer secret and not a person who logged in.

The stats the internet never sees

#

The other half of what I wanted was visibility. Most of what tells you how a system is behaving is, correctly, not public. On devbox that’s:

• the ingress proxy’s dashboard, and the tracing UI that holds its traces
• a dashboard for the Kubernetes cluster
• the container registry’s UI (read-only)
• Ollama’s model list and what’s loaded right now
• docker info and container stats

None of those have a public hostname, and none ever will. They’re bound to loopback or to cluster service IPs, reached over an SSH forward that itself rides the tunnel. A monitoring app on my phone reads docker info --format '{{json .}}' over SSH across WARP, so I can see from anywhere whether my containers are up or something has eaten all the memory.

That app is how I found a small bug worth mentioning. The tunnel sshd on the Mac was at LogLevel DEBUG2 from when I was debugging it. With -e, sshd logs to stderr, and for a session that stderr is the SSH channel’s stderr. Every command’s output came back with debug2: do_setup_env: set TMPDIR appended, and the phone app, which merges the two streams, got valid JSON followed by a log line, failed to parse it, and showed the whole thing as an error. LogLevel INFO fixed it. Put log levels back after debugging.

Just as deliberate is what I don’t put on this network. The old autossh tunnels also reach a few routers on other people’s networks that I help look after. Those get no public hostname and no WARP route. A router admin page on the internet is a liability even behind a login, and it isn’t my network to widen.

Access is not optional

#

A Cloudflare Tunnel hostname is on the public internet the moment its DNS record exists. There’s no firewall in front of it; that’s the whole point of not opening a port. The protection has to come from Cloudflare’s edge, and that’s what Access does. It refuses to forward a request at all until the visitor has proved who they are, so an unauthenticated scanner never reaches the laptop. That matters, because these are dev servers: a debug-mode traceback with settings in it, an open JavaScript bundler. Nothing behind these hostnames was built to face the internet.

The policy allows my own email addresses and nothing else, with a one-time PIN by email and single sign-on as the two ways to prove it. Sessions last eight hours, because the realistic threat is a laptop left open in a café with a day-long cookie, not someone brute-forcing a PIN.

SSH is authenticated twice, by two systems that don’t know about each other. Access decides whether a TCP stream may reach sshd at all; sshd still demands my key. Losing either doesn’t open the machine. The Mac’s tunnel sshd also trusts Cloudflare’s SSH CA, so Access can log me in with a short-lived certificate minted from my SSO session, while authorized_keys still works alongside it, so a broken Access config can’t lock me out of my own laptop.

The piece I’m happiest with is small. Exposure happens when three things line up: a DNS record, a running connector and an active zone. They become true at different times, in an order I don’t control; the zone flips to active on its own, some time after the nameservers change, quite possibly while the Mac is asleep. So the launch agent doesn’t run cloudflared directly. It runs a preflight that reads the hostnames out of the tunnel’s own config, asks the Access API which ones are covered, and refuses to start if any aren’t:

HOSTNAMES=$(grep -E '^\s*-\s*hostname:' "$CONFIG" | sed -E 's/.*hostname:\s*//' | sort -u)
PROTECTED=$(curl -fsS -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/access/apps?per_page=100" \
    | python3 -c 'import sys,json; print("\n".join(a.get("domain","") for a in json.load(sys.stdin)["result"]))') \
    || { echo "could not reach the Access API. refusing (fail closed)."; exit 1; }

for h in $HOSTNAMES; do
    grep -qxF "$h" <<<"$PROTECTED" || { echo "NOT starting: $h has no Access app"; exit 1; }
done
exec cloudflared tunnel --config "$CONFIG" run

The launch agent has KeepAlive, so a refusal retries by itself every 30 seconds and the tunnel comes up on its own once the Access apps exist. Failing closed costs an outage. Failing open costs an exposure. I know which of those I’d rather explain.

Four things that bit me

#

Everything above works now. Getting there, three of the four had the same pattern: the thing that was broken produced no error anywhere, and the parts I could see all reported healthy.

The route and the include list are two different lists. A tunnel route makes Cloudflare willing to carry an address to the right connector. The WARP include list is what makes the client send it in the first place. devbox was unreachable from the phone because its routes existed but the include list still only had the Mac’s addresses. The phone dropped the packets locally, the connector never saw a flow, and every dashboard was green. Every new machine means adding its addresses to both.

IPv4 literals on IPv6-only mobile networks. Covered above: works on wifi, fails on 5G, no error. If a WARP route works on wifi and not on mobile data, and the Agent shows connected, it’s routing, not the tunnel.

macOS sshd behind cloudflared. macOS starts its sshd with launchd socket activation, one short-lived sshd -i per connection. Behind cloudflared, the banner reaches the client and then the stream is torn down before the client’s identification string gets back, so every login dies at kex_exchange_identification. I confirmed it from both ends and reproduced it with a plain TCP relay, which ruled out Cloudflare. The fix is a second, standalone sshd -D on 127.0.0.1:2222 and the WARP loopback addresses, running as my user, that exists only to be the tunnel’s origin. Remote Login in System Settings is untouched. devbox, being Linux with a normal long-lived sshd, never had the problem.

Config fields that stop existing. Older examples have warp-routing: enabled: true in the tunnel config. cloudflared 2026.8 rejects that field outright. WARP routing is on whenever the block exists and a route points at the tunnel. That one at least produced an error, which after the other three felt almost generous.

What it changed

#

The honest summary is that I stopped choosing where to work based on where the hardware is. The laptop is a good keyboard and a good screen with a long battery life, and it doesn’t need to be more than that. The workstation does the heavy lifting from wherever I am. The phone is a real test device on a real network rather than something tethered to office wifi. And the parts of the system I use to see what it’s doing are one click away for me and don’t exist for anyone else.

At this size it fits in Cloudflare’s free Zero Trust plan. What it cost me was time and a README I’m glad I wrote, because every one of the failures above would have been a fresh mystery the second time.

If you’re thinking about something similar, these are the questions I’d ask of your setup:

1. What runs on your laptop only because the laptop is the one machine you can always reach?
2. Can your phone reach your dev server on mobile data, not just on the office wifi? Test it on 5G, not wifi.
3. Which of your dashboards are public because that was the easy way to see them from outside? Each one is a candidate for a private route instead.
4. If a tunnel hostname came up without its Access app tomorrow, what would stop it? If the answer is “I’d remember”, write the preflight.
5. Are your private addresses in a range the networks you visit will never use?