Skip to content
Notifications
Clear all

Anyone actually using Banyan in production for a Fortune 500?

5 Posts
5 Users
0 Reactions
3 Views
(@devops_shift_lead)
Estimable Member
Joined: 4 months ago
Posts: 136
Topic starter   [#8153]

We've been running Banyan for about 18 months now, replacing a legacy VPN and a patchwork of bastion hosts for a global financial services firm (top 100 by revenue). Team of ~15k developers and corporate users. The short answer is yes, it's in production, but it's not a magic bullet.

The primary win was zero-trust network access (ZTNA) for our SaaS and internal web apps. We tied it to our existing Okta for device trust and identity. The access tier model is solid. We defined policies like this:

```hcl
resource "banyan_policy_tunnel" "prod_k8s" {
name = "prod-k8s-tunnel"
description = "Tunnel access to production k8s API"
access {
roles = ["prod-engineer"]
trust_level = "High"
}
}
```

The pitfalls are real, though.
* **Performance under load:** The global edge can add 80-120ms latency for users far from a PoP, which broke some finicky internal tools that assumed LAN latency. We had to re-architect those.
* **Cost spiral:** The per-user, per-feature licensing gets expensive fast. We had to aggressively prune inactive users and fight to keep "Advanced Threat Protection" off most policies.
* **Operational overhead:** The Banyan connector (for private resources) is stable, but its logs are a black box. We had to build custom Prometheus exporters for the control plane metrics we actually care about.

It does what it says on the tin for replacing VPNs. Just go in with your eyes open on the bill and have a plan for latency-sensitive workflows. I'm interested to hear how others are handling the cost/performance trade-off, especially for large-scale developer access.

-shift


shift left or go home


   
Quote
(@carolp)
Estimable Member
Joined: 1 week ago
Posts: 89
 

That latency hit is rough. Had the same issue with our internal build tools. We ended up deploying regional connectors to keep traffic within a geography, which helped cut it down to 30-40ms.

Your point on cost is key. Their pricing model makes you constantly justify every user. We automated a monthly cleanup job via the API to deprovision anyone inactive for 90 days. Saved a chunk.

How are you handling the connector operational overhead? Ours required constant babysitting for the first six months.


—cp


   
ReplyQuote
(@devops_barbarian)
Estimable Member
Joined: 3 months ago
Posts: 125
 

Regional connectors just add more moving parts. It's another resource you have to secure, patch, and monitor. You traded latency for operational complexity.

If 30-40ms is an acceptable fix, your underlying network might be the real problem. That's a lot of extra hop.

Automated deprovisioning is smart, but it's a workaround for a pricing model that's adversarial by design. You're paying them to build the cleanup script.


Don't panic, have a rollback plan.


   
ReplyQuote
(@heatherm)
Trusted Member
Joined: 1 week ago
Posts: 55
 

Thanks for this. The `trust_level = "High"` requirement in your Terraform snippet is what sold our security team, too. It let us map our existing device compliance tiers directly into access policy.

I'm curious about your point on pruning inactive users to manage cost. Did you face any pushback from department heads when accounts got deprovisioned? We had to build a whole "reinstatement request" process because people would get caught out after long leave or sabbaticals.


Ask me about my RFP template


   
ReplyQuote
(@budget_buyer_99)
Reputable Member
Joined: 1 month ago
Posts: 148
 

You had to re-architect internal tools because of their latency? That's a massive hidden cost right there. I bet that engineering time wasn't in the initial ROI calc.

>fight to keep "Advanced Threat Protection" off most policies
This is what drives me nuts. You pay for the platform, then they nickel and dime you to turn on the parts that feel like they should be core. It's a feature tax.



   
ReplyQuote