We're a Python-heavy dev shop, around 100 people, and our OpenVPN setup is a cost and maintenance nightmare. With our infrastructure moving entirely to the cloud (mostly GCP, some AWS), we're re-evaluating for 2026. Cloudflare Zero Trust / Access is on the shortlist, but the pricing page is... a classic "talk to sales" model for teams our size.
I've done some reverse-engineering based on their published $7/user/month for the first 50 users, and the common "volume discount" pattern. My napkin math for 100 users, assuming a modest discount after 50 seats, lands us somewhere between $600-$650/month. That's still a significant jump from our current infra costs, but the promised reduction in admin overhead and the built-in SSO/2FA could justify it.
My core question for teams using Cloudflare Access as a VPN replacement:
* Is the "identity-aware" proxy truly seamless for developer workflows? Specifically, for accessing internal web apps, databases (via browser), and SSH (via their `cloudflared` daemon). Any latency hiccups?
* How granular are the access controls in practice? Can we easily implement policies like "this group can reach these GCP staging instances, but only from a managed device"?
* Has anyone successfully negotiated pricing near the 100-user mark? What did the actual per-seat cost look like?
The alternative we're weighing is a mesh of Tailscale (headscale) or a self-managed ZTNA stack. The open-source route has a higher initial time cost but could be cheaper long-term. Curious if anyone has run the TCO comparison for a team of this scale.
I've been the RevOps lead for a 120-person B2B SaaS company for three years, and we migrated off OpenVPN to Cloudflare Zero Trust two years ago to support our shift to a hybrid cloud model. We use it daily for secure access to internal tools, analytics platforms, and a handful of legacy on-prem systems.
* **Real pricing for 100 users:** You're close on your estimate. We pay $5.40 per user per month for 120 seats on an annual contract, which puts your 100-user cost in the $550-$600/month range. The hidden cost is in the egress data if you use it as a full tunnel replacement, but for typical admin and dev access, that's negligible. The real budget factor is including it in your SSO provider's user count.
* **Developer workflow integration:** The SSH access via `cloudflared` is reliable but adds a configuration step to each developer's workflow. It's not a pure drop-in for SSH keys. For internal web apps and database UIs (like pgAdmin), it's genuinely transparent after the first auth. Latency is a non-issue for human interactions; we see added RTT of 3-8ms, which is imperceptible. The break happens with long-lived TCP connections for certain database protocols not designed for proxying.
* **Granularity of access controls:** The policy engine is the main win. You can build rules based on identity, group, country, device posture, and specific applications. A policy like "Only the backend engineering AD group can reach port 5432 on staging-db-host from a managed device" is standard. However, managing these policies for a dynamic set of cloud instances requires tying them to service tags or a service discovery layer; it's not fully automatic.
* **Deployment and maintenance effort:** The setup from zero to basic protection for a suite of web apps took one engineer about two days. The ongoing administrative overhead is roughly a tenth of our old OpenVPN setup. The breakage we see is almost always related to service restarts of the `cloudflared` daemon on our bastion hosts, which we solved with a simple systemd unit.
My pick for your described Python shop is Cloudflare Zero Trust. It's the right fit if your primary use cases are securing internal web applications, providing SSH gateway access, and you have a defined SSO provider already. The recommendation changes if you need to proxy high-throughput data pipelines or require full network-layer segmentation for compliance; for those, I'd need to know your compliance requirements and if you have any non-TCP/UDP protocols in use.
Your napkin math is pretty solid. I'd budget for that $550-$600 range.
On your workflow questions, the identity proxy is seamless for web apps and SSH once the daemon's set up. For Python devs, the SSH tunnel works like any other, just with a cloudflared handshake first. I've seen some initial connection latency when the daemon needs to re-authenticate, but it's sub-second and stable after that.
The granular controls are where it shines. You can absolutely build policies like your GCP staging example, tying them to Okta/Google groups. The "device posture" checks are also crucial - you can require a managed, encrypted machine before granting access to sensitive resources.
Have you looked at how you'd manage those user groups and policies? The initial setup there is the real admin work, not the ongoing maintenance.
Keep it civil, keep it real.
Totally agree on the group/policy setup being the real lift. We use Okta groups for our teams and it's smooth once you map the SAML attributes, but the initial mapping of every team's app permissions is a week of cross-team meetings. One thing I'd add: start with a super permissive "default deny" policy for everyone, then layer on access per group. That saved us from a full outage when we accidentally misaligned a group membership and blocked a whole team from Jenkins. Even then, the audit logs are solid for debugging.
Have you thought about how you'll handle short-lived containers or ephemeral dev environments? That's our next headache.
Always optimizing.
Your cost estimate lines up with what I've heard from others migrating at similar scale. That jump can sting, but the admin time we've saved on VPN cert rotations alone probably covers half of it.
> identity-aware proxy truly seamless for developer workflows?
Mostly yes. The SSH via cloudflared just becomes muscle memory after a day. The one hiccup we had was with some older internal tools that expected a real IP address for auth, not the Cloudflare proxy's IP. Had to tweak those app configs.
Great point on the granular policies. You can definitely lock down by GCP project or even instance tags. Do you plan to manage those groups directly in your IdP, or will you sync them into Cloudflare's teams? We went IdP-only and it's simpler, but sometimes slower to propagate.
That's a good point about the IP address changes. We ran into that too with a couple of self-hosted data visualization tools. The source IP showing up as Cloudflare's network broke their built-in IP allow-listing.
We ended up having to use a different approach for those few specific apps, routing them through a small wireguard instance instead. It feels a bit like a workaround, but it got the job done.
Do you find the IdP-only group management delay to be a problem in practice, or is it more of a minor annoyance?