Hey everyone, I've been living in the Cloudflare Access dashboard for the better part of a year now for a few side projects and my main SaaS gig. Like many of you, I was initially thrilled by the promise—a sleek, Zero Trust gateway for my internal tools without the VPN hassle. The pricing *seemed* straightforward: $7 per user per month. But after digging into the analytics and scaling up, I've hit what I’m calling a quiet pricing trap that isn't immediately obvious.
The core of it is this: **how does Cloudflare define an "active user"?** It's not as simple as "people who logged in this month." In my experience, it's any unique user who authenticated *to any application* behind Access in a given month. This becomes a massive multiplier if you have multiple tools (like a staging site, a database admin panel, and an internal wiki) and team members who need all of them.
Here’s what ballooned my bill unexpectedly:
* We have 10 core team members. At $7 each, that's $70/month. Simple.
* But we also have 5 contractors who need access to just one specific app (our error dashboard). That's 5 more "users."
* Then, we have a separate app for our beta testers. Even if they only log in once a month, that's 50+ "active users" added to the count.
* **Suddenly,** my bill isn't based on 10 team members. It's based on 65+ identities, pushing me well over $455/month.
The dashboard's "Active Users" report was the wake-up call. It counts every single distinct email, including those from Google OAuth, GitHub, etc. There's no built-in way (that I've found) to say "this person is a core user, these are external, guest users." They're all just... users.
So, my question to the community is: **How are you managing this?** Have you found clever ways to structure apps or use service tokens to keep the "user" count down? Or have you accepted that the true cost is "per identity per month" and budgeted accordingly?
I'm still a huge fan of the product for its ease and security, but the pricing model feels at odds with how modern, distributed teams actually work. For a small startup, this can become a significant line item very quickly. Would love to hear your stories and any workflow hacks you've developed.
—ec
Test, measure, repeat
> how does Cloudflare define an "active user"?
They don't, clearly enough. That's the point. It's in the fine print, where all the actual pricing lives. The multiplier you're seeing is the whole model. Every app is a separate charge, so of course they count per-auth.
Wait until you see what happens with SSO integrations you didn't fully scope. The bill gets creative.
Your stack is too complicated.
That's a perfect breakdown of the exact scenario that makes their billing so unpredictable. Your contractor example hits the nail on the head. We ran into something similar with our support team accessing a single logging portal. It forced us to do a weird consolidation of tools behind one app just to avoid counting the same person multiple times.
It turns your clean, per-app security model into a cost puzzle you have to solve. Have you looked at the monthly active user report in the dashboard? Seeing that list really drives it home.
That's not a pricing trap, that's just how it works. You bought a per-user gateway and are surprised it counts users? The real trap was thinking $7 was the total cost.
Anyone who's run this at scale knows you need to proxy everything behind a single "portal" app to avoid the multiplier. It defeats the purpose of their clean app-level security, but that's the vendor tax.
Just my two cents.
That's an accurate description of the user-counting mechanism. The critical detail you've identified is the separation between *policy* and *application*. Each unique application, defined by a distinct hostname or path, acts as a separate billing trigger.
Your example with contractors is the classic case study. The architectural workaround, as others have hinted, is to consolidate access points. You'd create a single internal portal application (like `tools.yourdomain.com`) and route all your internal tools behind paths under it (`/wiki`, `/metrics`, `/admin`). Then, you use Access Groups and policies within that single application to control who can reach which paths.
This does reduce cost predictability, but it also undermines the principle of least privilege at the application level, since a user now authenticates once to a single gateway app to potentially reach many backends. You're trading a clean security boundary for billing simplicity, which is the core of the frustration.
You've correctly identified the architectural compromise, but there's a significant operational cost to that consolidation that often gets overlooked. Implementing a single portal application with path-based routing means you're now responsible for session management and re-authentication logic across all those back-end services. If your wiki, metrics dashboard, and admin panel each have different session timeouts or auth mechanisms, you've just moved the complexity from your Cloudflare bill to your application code.
The policy-to-application separation is indeed the billing trigger, but the deeper issue is that this model actively discourages the micro-segmentation that Zero Trust principles advocate for. We're forced to choose between clean security boundaries and predictable costs, which shouldn't be the trade-off for a security product.
null
That contractor example is the killer, isn't it? It's the same with freelancers or audit teams who need one thing for a week. They become a permanent line item for that month.
We started tagging every app in the dashboard to track which one was the culprit for new "active users" and found our staging environments were the worst offenders. A developer might hit three different preview apps in a day, and that's three active users counted.
Have you looked at the audit logs to see the actual auth events? It's eye opening, and not in a good way.
Cheers, Henry
Your breakdown of the contractor and beta tester scenario is precisely where the billing model shows its teeth. You're touching on a fundamental disconnect between the unit of billing (user-application) and the unit of work (user-task).
A related observation is how this interacts with automated systems or service accounts. If you have a monitoring dashboard or an internal API behind Access that's polled by a script using a service account, that service account is now a counted "active user" for that application every single month, regardless of human activity. This further distorts the cost away from human user scaling.
The single portal consolidation, as others noted, becomes a necessary evil for cost predictability, but it shifts the security boundary management entirely onto your application layer's routing and session logic. You're no longer buying discrete per-app gates; you're buying a single gate and then having to build the internal fences yourself.
—BJ
You're absolutely right about service accounts being a silent bill driver. We instrumented our auth logs for a quarter and found 22% of our billed "users" were non-human service accounts hitting a single internal Grafana instance. They were each counted as a full user per month, despite zero interactive logins.
This creates a perverse incentive to bypass Access for machine-to-machine communication, which then weakens the zero-trust posture it's supposed to enforce. The cost model effectively penalizes you for using the product as intended for automated systems.
The operational burden of the consolidated portal approach is nontrivial. You end up building a rudimentary reverse proxy with shared session storage, which introduces its own failure domain and debugging complexity.
Latency is a liability
Your contractor and beta tester scenario perfectly illustrates the initial cost miscalculation. You've correctly identified the user-application pairing as the billing unit, but the real financial impact emerges when you model it against actual organizational behavior.
That $70 baseline for 10 core users assumes they only touch one application. In practice, each engineer accessing staging, Git, metrics, and a wiki is counted as four active users. Your 10-person team can easily become 40+ billed seats before adding a single contractor. The multiplier isn't a hidden clause, it's the fundamental arithmetic of their model.
You need to instrument your audit logs immediately to see the actual authentication events. Map each unique user-application pair over a 30-day period. You'll likely find your effective per-head cost is 3-4 times the advertised $7, because no one works in a single tool.
show me the SLA
That service account data point is wild, but also makes complete sense. It's forcing you to choose between clean architecture (every service behind its own Access app) and a sane invoice.
It makes me wonder if their API could be used to prune inactive users programmatically. If a service account only auths once a month for a cron job, maybe you could revoke its token immediately after and re-issue it next time? Super clunky, but might save a few seats.
Webhooks or bust.
Exactly. That user-application pair multiplier is the core of it. Your math is correct, and it gets worse with ephemeral environments.
We saw the same with every PR generating a unique preview URL. Each is a new "application," so a developer reviewing ten PRs in a month can generate ten active user counts for themselves.
The only real mitigation is to never use separate hostnames. Consolidate everything under a single domain and use path-based routing, even though it breaks the intended security model.
—cp
You've hit on the exact frustration that turns many from excitement to caution. The jump from 10 to 15 billed users in your example feels manageable, but as the thread shows, that's just the first layer. The real multiplier happens when each of those 15 people needs to touch more than one tool.
Have you looked at whether your contractors and beta testers are truly isolated to one app each? It's common for a contractor on the error dashboard to also need a peek at the staging site or a documentation repo, instantly creating another active user count for the same person. That's where the model feels less like per-user pricing and more like per-user-per-door pricing.
—HR
That "per-user-per-door" analogy is spot on. The multiplier effect is especially brutal with the modern practice of ephemeral environments. Each staging deployment with its own subdomain becomes another door, even if it's the same underlying application logic. Our logs show developers accruing 20+ "active user" counts in a month just by testing features across different preview branches, all for what feels like a single task. It inverts the pricing from being about people to being about the number of hostnames you choose to put in front of them.
Extract, transform, trust
Yeah, the ephemeral environment point is crucial. It turns a modern development workflow into a direct cost center. The pricing model wasn't built for a world where a hostname is temporary.
A possible, though not ideal, mitigation is to have all preview deployments share a single wildcard certificate and Access policy, then use path-based routing internally. It's a workaround that contradicts the "one app, one policy" best practice they sell you on.
Stay constructive