Beyond Tunnel and Access, which Cloudflare Zero Trust pieces I still have left to turn on
An honest inventory of the Cloudflare Zero Trust and Cloudflare One services I still haven't used in the VPS migration series, what they look like on the Free plan, what problems they solve, and which ones I'd turn on first. Gateway DNS, Service Tokens, Turnstile, mTLS in Access, WARP Connector for non-HTTP services, Page Shield, and Cloudflare's own Notifications.

The VPS migration series behind Cloudflare wrapped up with Tunnel and Access, which got the admin panels off the public Internet. But the Cloudflare Zero Trust and Cloudflare One suite goes quite a bit further than that, and there are pieces in the Free plan (or very cheap) that deserve a spot in any small setup that wants to take security at least somewhat seriously.
This post isn't a tutorial, it's a curated inventory. For each service, I'll go over what it does, what problem it solves, what you actually get on Free, and whether I'd turn it on today on my VPS, leave it for later, or skip it. One person, one VPS, a handful of apps, that's the context I'm talking about. For a company with 200 developers, the priorities change.
Gateway DNS, filtering at the resolver
The easiest one, and probably the most underrated. Cloudflare Gateway lets you set DNS policies, block whole categories (malware, phishing, adult content, cryptominers, dynamic DNS) or specific domains, and apply them to any device or server using its resolvers.
The usual use case is protecting employee endpoints with WARP, but there's another really interesting one for a VPS, point the server's own /etc/resolv.conf at Gateway resolvers. Any DNS lookup the VPS makes (pulling a Docker image, installing a package, an outbound call from an app to a compromised domain) goes through those policies. If an NPM dependency gets compromised and tries to fetch from a known credential-harvesting domain, Gateway cuts it off before the request happens.
Free allows up to 50 users and enough DNS policies for a homelab. The UX catch is that on the Free plan you get one Gateway location, so you can't split policies by VPS if you have several, they all share the same one. In my case that doesn't matter because all my servers are basically the same profile in practice.
Would I turn it on? Yes, first on the list. It's trivial, free, and it measurably reduces supply chain attack surface.
Service Tokens, the little gap filler for automation
Cloudflare Access is perfect when I'm the one opening the panel. But what about a GitHub Action that needs to call an endpoint behind Access, a local script checking the status of something, or a remote cron job. Asking a CI job for an OTP makes no sense.
The piece for this is Service Tokens. They're pairs of CF-Access-Client-Id and CF-Access-Client-Secret generated in the Zero Trust dashboard and included as headers in the request. The Application policy has to explicitly allow that token with a Service Auth > Service Token selector.
The mental model is the same as a dedicated API key, but with two important differences. First, the token lives in CF, so you can revoke it instantly from the dashboard without touching the origin. Second, tokens are auditable, Access logs tell you which token got in, through which path, and when. That turns an opaque secret into an actor with an identity.
Free plan limitations, the tokens work, but the recommended rotation cadence (90 days) has to be managed by hand, there's no automatic rotation. In practice, for CI, the acceptable setup is to generate the token, put it in GitHub Secrets, and rotate it when something happens that calls for it.
Would I turn it on? Yes, as soon as a project has a GitHub Actions workflow that needs to talk to an endpoint protected by Access. Right now my deploys go through GitHub webhooks to the bypass endpoint I already documented in the previous post, so I still don't need it, but the next thing that has to call an admin panel from a job would go through a Service Token, not by opening more bypasses.
Turnstile, a decent CAPTCHA replacement
Any public form that handles user signups, newsletter subscriptions, contact, or submissions of any kind eventually gets bots. I've spent years avoiding reCAPTCHA for two reasons, the dependency on Google (with the privacy and reputation cost that comes with it) and because silent v3 punishes users who take privacy seriously (Tor, browsers with privacy hardening) without the site really knowing why it's losing legitimate signups.
Turnstile is Cloudflare's answer to that, a widget that in most cases doesn't show a challenge to the user, does passive browser analysis (the usual signals), and issues a token that the backend validates by calling the CF API. If the analysis is ambiguous, you get a non-invasive challenge instead of the classic image traffic light.
The Free plan allows 1 million validations per month. For a blog and normal-sized forms, that's basically unlimited.
Integration is trivial. On the frontend, the https://challenges.cloudflare.com/turnstile/v0/api.js script and a <div class="cf-turnstile" data-sitekey="...">. On the backend, before processing the form, a POST call to https://challenges.cloudflare.com/turnstile/v0/siteverify with the client token and the secret key. If the response is success: true, you continue. If not, you return 400.
Would I turn it on? Yes, on any new public form. In fact, I already use it on some projects like TimeCapsule, ScamDetector, and my CV. For the existing ones (blog newsletter signup, comment signup), I'd add it as soon as I start seeing spam spikes.
mTLS in Access, a real second factor for critical panels
Email OTP is enough for most personal panels, but for the ones that can do real damage (orchestrator, secrets manager), login should ideally require something you have as well as something you know. The option Access offers for that is mTLS, the Application requires a client certificate signed by a CA you control, and only devices with that certificate installed can even see the OTP form.
The flow is, you generate a CA yourself (or use an existing one), upload it to CF as Mutual TLS Authentication in the zone, generate client certificates for each device you'll use to log in from (laptop, phone), and import them into the system store. The Application policy adds require > valid certificate. Without the certificate, you don't even see the login.
The normal usage flow is transparent, the first time the browser asks you to pick a certificate and that's it. The annoying part is operations, importing the cert on macOS, on iOS, on Linux, on Android, each platform has its own quirks. And rotating the CA when it expires (CAs are usually 5-10 years) is something you have to plan for.
Available on the Free plan, no extra cost.
Would I turn it on? Yes, but only on Dokploy and possibly Infisical. For Umami or other low-impact panels, it doesn't justify the operational cost. For the orchestrator, yes. The idea is that not even an attacker with a compromised email OTP can see the login.
WARP Connector, private networks for non-HTTP services
Tunnel and Access work with HTTP/HTTPS. But what if I want access to the VPS over SSH, to a Postgres instance that's not exposed, or to the port of an internal service like Redis Insight or PgAdmin that's only listening on the Docker network? One option is exposing them over HTTPS behind some proxy, but there's a better one.
WARP is Cloudflare's VPN client. WARP Connector is the server-side component that connects an entire network (the VPS network, a LAN, a cluster) to the Cloudflare edge as a private network. Combined with WARP on the client, it creates an encrypted tunnel where your laptop can reach any IP on that private network as if you were inside it.
The ideal use case is SSH to the VPS, leave port 22 closed to the Internet, install WARP on the client, connect to the Zero Trust team, and SSH works against a private IP that's only visible inside the tunnel. The identity used to get into WARP is the same one as Access, so you don't have to maintain two auth systems.
Free includes WARP with unlimited usage for up to 50 users. The downside for a Dokploy-style setup is that creating the Connector inside the orchestrator needs some thought, the cloudflared pods for Tunnel and the ones for WARP Connector are different containers, and it's a good idea to isolate them.
Would I turn it on? Yes, medium priority. SSH to the VPS today goes over port 22 with a key (no password, with fail2ban / CrowdSec) and honestly it works fine. Closing it completely and putting it behind WARP would be cleaner and would remove the whole category of SSH scanners from the logs, but it isn't urgent. I'd do it as a weekend task.
Page Shield, keeping an eye on third-party browser scripts
If an external script on your site gets compromised (Magecart-style, CDN supply chain), your visitors get the present. Page Shield is Cloudflare's piece for monitoring which JavaScript scripts load on your pages, their integrity and behavior, and alerting you if a new one appears or a known one changes.
The free part gives you the basic monitor, an inventory of the scripts loading on your pages (what real visitors actually see) and a changelog. The advanced actions (active alerts, content security policy managed by CF, blocking) require Pro or Business.
On my blog I use very few external scripts (Tiptap is mine, Umami is self-hosted, I don't have Google Tag Manager or reCAPTCHA), so the inventory should be very short. If one day a script appears that I didn't add, that's the alert. It's one of those pieces that's more valuable for what it detects than for what it actively does.
Would I turn it on? Yes, the base monitor. It costs me nothing, and the first time I look at the inventory it confirms the site is clean. If I ever have to pay for Pro for some other reason, I'd seriously look at the active actions (alerts, CSP).
Cloudflare Notifications, the alerts a lot of people never turn on
This is the simplest one and the most forgotten. CF has a Notifications panel where you can set email or webhook alerts for CF-side events, DDoS attacks, high origin latency, certificate validation failures, upcoming expiration, problems with Universal SSL, unusual 5xx errors, big traffic swings.
It's free. The adoption curve is absurdly low, open the panel and pick what you want to receive. And it fixes a very common gap, finding out your certificate expired because a user told you is the kind of experience you prevent with two clicks.
Would I turn it on? Yes, right now. In fact, this is the first thing I'm going to do when I finish this post.
What I'm looking at but still not sold on
Browser Isolation
Interesting concept, run the browser in a remote sandbox and only send you the render. Useful for opening reported phishing links or suspicious email attachments without risk. But it's outside the Free plan (included in Cloudflare One Premium) and for my profile it doesn't pay off, I already filter at the DNS level and I open sketchy stuff from a VM.
Zaraz
Tag manager with server-side execution. Useful if you depend on lots of pixels and external scripts for analytics and marketing. I don't, so I wouldn't get much out of it.
Email Routing and Email Security
I already use Email Routing, free and very good. Email Security (the former Area1 suite, anti-phishing and advanced filtering) is paid, and for personal use on a domain where I barely get 10 emails a day, it doesn't make sense. For a small company, yes.
Logpush
Push CF logs to an external destination (S3, R2, BigQuery...). Useful for forensic analysis and SIEM. Enterprise only.
Adoption plan if I had to put all this in order
If I had to rank it by value versus effort, my list would be this.
Cloudflare Notifications, 5 minutes of setup, huge value.
Gateway DNS on the VPS, one hour, locks down outbound traffic from the server itself.
Page Shield monitor, two clicks, free inventory.
Turnstile on any new public form, an afternoon if you're adding it to something existing.
mTLS in Access for Dokploy, a weekend of operational work (CA, certs, imports, testing on every device).
Service Tokens, when the first CI-to-protected-endpoint use case shows up.
WARP Connector for SSH and non-HTTP services, a weekend.
The pattern here is the same as in the rest of the series. Every piece has a setup cost and a mental overhead cost, and you turn it on when the benefit is real, not when it just "looks nice". Cloudflare Zero Trust and Cloudflare One offer a lot more than what fits into a Free plan, but the Free plan covers a one-person homelab surprisingly well if you pick the pieces with some judgment.
What's next
In order, the next things I'm going to touch are Notifications and Gateway DNS, they're the two fastest and the ones that most reduce the category of surprise failures. When one of the others moves from "I'd look at it" to "I'm doing it", it'll probably get its own post with the real setup, same as the migration series did. But that's already outside the main arc of "put the VPS behind Cloudflare", which I officially closed with the previous post about Tunnel and Access.

Jose, author of the blog
QA Engineer. I write out loud about automation, AI and software architecture. If something here helped you, write to me and tell me about it.
Leave the first comment
What did you think? What would you add? Every comment sharpens the next post.
If you liked this

ScamDetector, un detector de estafas con inteligencia artificial
ScamDetector combina inteligencia artificial, búsqueda de reputación de teléfonos y escaneo de URLs para ayudarte a identificar estafas digitales. Sin registro, sin datos almacenados.

Guía práctica de hardening para tu VPS Linux: de CrowdSec al kernel
Repaso completo de las medidas de seguridad que puedes aplicar a un VPS Linux: desde CrowdSec y el firewall hasta el hardening del kernel, pasando por SSH, Docker y las actualizaciones automáticas.

Cómo verificamos que nadie manipula los posts de este blog
Nuestros posts viven en una base de datos SQLite. Si alguien accede a ella, puede cambiar cualquier artículo sin dejar rastro. Construimos un verificador externo con hashes SHA-256 y firma Ed25519 que vigila la integridad desde un segundo servidor.