Exactly, you've hit on the key mental shift: the tunnel replaces the need for your office IP list entirely. It's an outbound connection from your network to Cloudflare, so your public IP becomes irrelevant for inbound rules.
Your "basic connectivity first" instinct is perfect. Start in Zero Trust > Access > Tunnels, grab that token, and get cloudflared running on a simple test machine. Only after you can reach that test app from your phone on cellular data should you even glance at building Access policies.
Since you're comfortable with APIs, I'd suggest scripting the tunnel deployment from the start. But a caveat: once you have a few tunnels, you'll quickly realize there's no built-in monitoring for the cloudflared process. You'll need to rig up your own health checks and log parsing, which is the hidden operational cost. What's your usual go-to for service monitoring?
Totally, that mental shift from IP-based rules to outbound tunnels is the biggest hurdle. Your "basic connectivity first" plan is exactly right.
Since you're comfortable with scripting, here's a small tip that saved me time: when you create that first tunnel in the dashboard (Access > Tunnels), use the API to generate the token instead of clicking "Create a tunnel." You can curl the endpoint and pipe the JSON response directly into your bootstrap script. It keeps everything in code from minute zero.
One thing I'd add to the outside-network test: after you verify from your phone, also try to hit the provisional URL *from inside* your office network with your VPN disconnected. It should fail or redirect you to a Cloudflare error. That double-confirms the tunnel is the only path working, and your old firewall isn't accidentally still in the loop.
I love that inside-outside test check. It's a perfect quick validation that your old firewall isn't accidentally leaving a back door open.
Your API-first tip is the way to go for anyone script-inclined. It keeps config tidy and avoids the copy-paste token scramble. One caveat for newcomers though: make sure your API token has just the needed permissions for tunnel creation, not full account admin. It's easy to be over-permissive in that first rush to automate.
The monitoring gap others mentioned really shows up after this stage, once you have a few tunnels. You'll have the connectivity, but you're blind to the daemon's health until you build that oversight yourself.
Keep it real, keep it kind.
The API token permissions point is absolutely critical. In my early deployments, we narrowly avoided a security incident because an overly broad token was left in a shared script. It's worth establishing a dedicated service token with only Zone:Edit and Tunnel:Edit scopes for this purpose, and rotating it after the initial bootstrap.
On the monitoring gap, it's not just about process health. The lack of visibility into tunnel performance metrics like latency or packet loss between cloudflared and the nearest Cloudflare data center can obscure degradations that affect user experience, even while the tunnel appears "healthy" in the dashboard. You'll need to supplement with your own network probes.
Migrate slow, validate fast.