We rolled out Cloudflare Access for internal apps about two years ago, and it was great... until we hit around 200 developers and needed to scale our security model. The "just works" magic started to fray at the edges, especially around granular, dynamic access policies.
Our main pain points:
* **Policy management:** Defining "who can access what" in the Teams dashboard became unmanageable. We needed to replicate complex logic from our internal directories (like LDAP groups nested in other groups) and couldn't version-control policies effectively.
* **Cost surprise:** The per-user pricing got steep as we grew, especially for contractors and CI/CD service accounts that needed "user" seats. The bill was becoming a line-item we had to justify every quarter.
* **Lack of GitOps:** We're an infrastructure-as-code shop (heavy Terraform users). Not being able to fully manage Access policies via code was a major workflow breaker. Manual dashboard clicks for security-critical config is a non-starter.
The final straw was trying to implement just-in-time access for our staging environment. We wanted to tie approvals to specific Jira tickets. With Cloudflare Access, we'd have needed to build an external orchestration layer, which defeated the purpose.
We evaluated moving to **Pomerium**, and after a 3-month migration, here's the outcome:
**The Good:**
* **Everything as Code:** Pomerium policies are defined in a YAML config file. This lives in our Git repo, goes through PR reviews, and is deployed via our CI/CD pipeline. This was the biggest win.
```yaml
policy:
- from: https://internal-tool.mycompany.com
to: http://backend-service:8080
allowed_users:
- group:engineering@mycompany.com
allow_any_authenticated_user: false
```
* **Fine-Grained Control:** We could use the full power of our identity provider's claims (nested groups, custom attributes) directly in policy logic without pre-configuring everything in Cloudflare.
* **Cost:** It's self-hosted (runs in our EKS cluster), so our cost is now just the compute for the proxy pods. For our scale, it's about 1/5th of what we were paying.
**The Rough Edges:**
* **No built-in UI:** There's no admin dashboard to view active sessions or easily test policies. You `kubectl logs` and rely on metrics (we pipe logs to Datadog).
* **Operational overhead:** We now own its availability and scaling. It's another service in our incident rotation, whereas Cloudflare was someone else's problem.
The switch was a significant engineering project, but for teams that need programmable, Git-centric zero-trust access and have the Kubernetes operational maturity to run it, Pomerium has been a game-changer. It's not for everyone, but it fit our "infrastructure as code" ethos perfectly.
Has anyone else made a similar move from a SaaS access gateway to a self-hosted alternative? I'm particularly curious about how you handled the transition for non-engineering users.
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.
Oh, the "per-user pricing got steep" surprise. That one's a classic. Did your procurement team not model the TCO with headcount growth? The jump from 50 to 200 users plus contractors and service accounts should have been obvious in any decent three-year forecast.
I'm more interested in the "lack of GitOps" complaint, though. You're a heavy Terraform shop, and you went with a solution whose core policy engine lives behind a proprietary dashboard? That seems like a foundational vendor evaluation misstep. The workflow breaker was already there, you just didn't feel it until you scaled.
So, you needed JIT access tied to Jira. What were they quoting you for that, another middleware layer?
Show me the TCO.
> you're a heavy Terraform shop, and you went with a solution whose core policy engine lives behind a proprietary dashboard?
That's the trap, isn't it? The demo is always "look how easy it is to click!" They never show you the 300-rule YAML file you'll need to recreate two years later when the person who clicked leaves. The workflow breaker is silent until you need an audit trail or a rollback.
On JIT, yeah, they were pushing us toward their "Access Approvals" add-on. Another license tier, another API to wrangle. The quote had more middleware than our actual app stack. Felt like paying to build the feature they advertised as "zero trust."
Your pain points resonate. That scaling threshold around 200 active users is where the "black box" abstraction of a managed service starts working against you. You're no longer just configuring access, you're trying to integrate it with your actual business logic, and the platform's rigidity shows.
We hit a similar wall trying to encode custom claim rules for a multi-tenant SaaS deployment. The moment you need to pull in data from outside their directory schema, you're stuck building a proxy or waiting for a feature flag.
On the GitOps front, lacking a proper programmatic interface for the policy engine is a total blocker for any team that treats infrastructure as a product. It's the reason we now evaluate "day two" operability before anything else in our vendor proofs of concept.
Integrate or die