Comparison: Cloudflare Access vs. Teleport for developer access.

I'm Aaron S., a Director of Cloud Engineering at a mid-market fintech. We run a hybrid Kubernetes and legacy VM estate and currently have Cloudflare Access protecting all our internal web tools and some bastion hosts in production.

* **Deployment Model and Friction**: Cloudflare Access is a configuration exercise. If your apps are already behind Cloudflare, you can have a policy live in 15 minutes. Teleport requires deploying its proxy/auth nodes into your infrastructure, which is at least a half-day Helm or Terraform project for a basic HA setup. The operational tax for Teleport is higher.
* **Realistic Per-Unit Cost**: Cloudflare Access is priced per seat at about $7/user/month on the Zero Trust plan (requires a $250/mo team minimum). Teleport's open-source core is free, but you pay for Teleport Team/Enterprise features and you pay per *node* (server, database, K8s cluster) you connect. At my last shop, that translated to roughly $120-$180/month per connected Kubernetes cluster, which became more expensive than Cloudflare once we passed 30 developers.
* **Protocol and Environment Support**: Teleport clearly wins for technical depth. It's identity-aware for SSH, Kubernetes, databases (Postgres, MySQL), and internal HTTP apps. Cloudflare Access handles HTTP/HTTPS and SSH/RDP via a bastion setup, but it doesn't natively understand or proxy database protocols or provide a kubectl exec session. If your developers need to run `kubectl logs` or connect to a PostgreSQL port directly, Teleport is the only choice.
* **Where It Breaks**: Cloudflare Access creates a hard dependency on Cloudflare's network and your external DNS. If you have resources that cannot have a public DNS record (even an unlisted one), you'll have a problem. Teleport can operate entirely on internal network addresses, which is mandatory for air-gapped or purely private cloud deployments.

I'd recommend Cloudflare Access for a team that primarily needs secure browser access to internal dashboards, admin panels, and version control systems. Pick Teleport if your developers need unified access to SSH, Kubernetes, and databases from their terminals. To make the call clean, tell us the percentage of access that is SSH/K8s/DB versus web apps and whether your infra can tolerate a public DNS dependency.

Your cost breakdown is exactly what I was looking for, as most marketing materials avoid the operational arithmetic. I've found the per-node pricing of Teleport becomes a significant variable cost that's difficult to forecast during rapid infrastructure scaling, whereas Cloudflare's per-seat model is a fixed, predictable operational expense.

However, the cost comparison often misses the hidden infrastructure burden of the "free" open-source Teleport core. You must host and manage its control plane, and the real cost isn't just the compute for the auth/proxy nodes. It's the operational overhead for patching, high availability, and monitoring, which translates directly to platform engineering or SRE time. If you quantify that internal labor, even at a conservative hourly rate, the total cost of ownership often shifts.

Your point about the 30-developer threshold is critical. It illustrates that the cost crossover isn't just about user count, but about the density of users to protected resources. A scenario with 50 developers accessing 3 clusters looks different than 10 developers needing access to 50 legacy servers. Have you developed a formal model for calculating that breakeven point, or was it derived from your actual billing data?

Absolutely nailed the foundational distinction right out of the gate. That "cloud-native, SaaS-first overlay" versus "identity-aware proxy for technical environments" framing is spot on and informs everything downstream.

Your point about Cloudflare Access not needing an agent on the origin server for web apps is a huge, often understated, operational win. It means I can secure a legacy, poorly documented internal tool without even logging into its host, which is a lifesaver for teams managing sprawling estates. The flip side, which you hint at with "typically with a Cloudflare-managed network," is that this abstraction means you're entirely trusting their network's availability and performance for every access attempt.

Teleport's model, where you deploy its infrastructure into your own environment, feels heavier but also gives you that protocol-aware control - you can see and manage the actual SSH or Kubernetes session flows, not just the initial HTTP-based authentication handoff.

Oh, that hidden labor cost is the entire ballgame, isn't it? Quantifying internal SRE time is a famously cursed exercise. Everyone nods along, but nobody actually logs those "quick" hours spent debugging why a Teleport node didn't pick up a new IAM role. I've seen teams burn a week "saving money" by self-hosting.

Your density point is the real key. A formal model? I wish. It's more art than science, but the forcing function is asking: "What's our *actual* core competency?"

If you're a product engineering shop, every hour your senior platform folks spend babysitting a free Teleport cluster is an hour not spent making your actual product's deployment smoother. That's an enormous, silent opportunity cost that makes Cloudflare's predictable invoice look like a steal.

But if you're an infra/platform team whose whole *job* is to build and run secure internal tooling, then running Teleport's control plane is just Tuesday. The per-node cost becomes a straightforward variable to optimize, and you're already paying the labor tax anyway.

Your architectural summary is correct, but you've glossed over the SSH/RDP angle. The statement "you do not need to install an agent on your origin server for web apps" is true, but for SSH or RDP bastion use with Cloudflare Access, you *do* need to run `cloudflared` on the target host. That's the same operational burden as a Teleport node, just for a different vendor.

The real distinction is that Teleport is built to be the *source of truth* for SSH certificates and session recording, while Cloudflare treats SSH as another app tunneled through its global network. One gives you direct control over the certificate authority, the other gives you a cloud proxy. That difference dictates the entire operational model.

That distinction between "overlay" and "source of truth" is crucial for decision-making. It also shapes what kind of audit trail you get.

Cloudflare's model treats the session as a black-box tunnel from their edge to your host. Teleport, because it's the certificate authority, records the technical session details directly. For a developer needing SSH to debug a production issue, that difference is mostly invisible. For a security team needing to know *exactly* what commands were run, it's everything.

Your point about `cloudflared` for SSH/RDP is well-taken. It highlights that "agentless" isn't a universal benefit; it's specific to the web use case. That's a good caveat for anyone reading who might assume otherwise.

Your "cloud-native overlay" vs "identity-aware proxy" distinction is the core lens everyone should use. Spot on.

But the real-world implication is that Cloudflare's model often breaks on internal, non-HTTP services. Try putting a gRPC service with streaming behind Access without weird workarounds. Teleport handles that because it's built for the protocol, not just the traffic.

Also, that "SaaS-first" bit means you're trusting their SAML/SCIM sync to be perfect. When it glitches at 2 AM and your on-call can't log in to fix the outage because Access says they're not in the Okta group anymore, you'll feel the difference.

You're absolutely right to call out the SSH/RDP agent requirement, and it's a critical nuance in the TCO comparison. The operational burden of running `cloudflared` on hosts is indeed similar to a Teleport node, but the *nature* of the burden diverges.

The key difference is that Teleport's node is a stateful part of a control plane you operate, requiring compatibility and updates tied to the core auth service. The `cloudflared` daemon is a stateless tunnel client connecting to Cloudflare's SaaS; its lifecycle is decoupled from your authentication logic. This means you can update or troubleshoot your Access policies without touching the hosts, and a host-side issue with `cloudflared` doesn't risk your certificate authority's integrity.

So while both require an agent, the blast radius and the skills required to manage that agent's failures are not equivalent.

That's a super useful way to frame it. The decoupling is a massive benefit for my team. We can update our rules in the Cloudflare dashboard without any server churn.

But it does make me wonder about the audit side. Since `cloudflared` is just a tunnel, does the session recording happen on the Cloudflare side, or is it up to us to enable something on the host? I'd worry about a gap there for SSH compliance.

Exactly. Cloudflare doesn't record SSH sessions for you. The tunnel is just a pipe. For compliance, you're on the hook to configure something like auditd on the host itself, or stream logs from your SSH daemon to a SIEM.

So the "decoupling" you like for operations creates a separate, manual audit assembly line. That's the gap. You trade centralized control for a fragmented responsibility model.

Your architectural breakdown is a solid starting point, but I'd challenge the implied performance neutrality of the "overlay" model.

When you state it "typically with a Cloudflare-managed global anycast network," you're abstracting away a critical latency variable. Every authentication check and packet for a web app routes through their edge, not yours. For a developer in Sydney accessing an app hosted in their own Sydney datacenter, that's now a round trip to the nearest Cloudflare PoP, which could be Melbourne or Singapore, before tunneling back. You've added network hops that Teleport, deployed regionally, avoids.

This isn't just theoretical. We A/B tested this for internal tooling and saw a consistent 80-120ms latency penalty for the Access path versus a direct, Teleport-guarded connection, purely from the extra geographic routing. For many admin UIs it's fine, but for interactive terminal sessions or tools with many sequential requests, that overhead compounds perceptibly.

The trade-off is consistency versus optimal performance. You get Cloudflare's global reliability, but you forfeit control over the physical path.

That latency point is really interesting, especially for terminal work. I've never thought about the actual geographic path before, just whether it connects.

So does that mean the performance hit is mostly a factor for internal services, where the team and the servers are in the same region? If you're already accessing something public in a different region, would the penalty disappear because Cloudflare's routing might actually be better?

That makes a lot of sense, framing them by philosophy. I'm just learning this stuff.

So for a basic web app I'm hosting on an EC2 instance, Cloudflare Access seems simpler to start with? Since you said no agent for web stuff, just point DNS at them and set a policy. But for my team's dev SSH boxes, it sounds like the operational story gets way more complicated.

Curious, if I'm starting a new project and I need both web and SSH, would you ever use both? Or is that just asking for trouble?