Boundary pricing feedback - is it cheaper than Teleport for 100 users?

I've been tasked with evaluating Boundary versus Teleport for a mid-sized engineering organization hovering around the 100-user mark. The marketing from both sides is predictably dense with "zero trust" and "modern security," but my team needs a breakdown of the real, ongoing cost of ownership. We're already running a substantial Kubernetes fleet, so the operational overhead is a key part of the equation.

Let's start with the licensing models, because this is where the first major divergence occurs.

* **Boundary (HashiCorp)** uses a **per-user, per-month** subscription model for its Enterprise features, which you will likely need. The list price is approximately $4.50/user/month (as of their last published pricing sheet). For 100 users, that's a straightforward **$450/month** or **$5,400/year** in pure licensing cost for Boundary itself.
* **Teleport** uses a **per-node/per-host** model for its Enterprise edition, with a free tier for up to 5 nodes. Pricing is not as publicly granular, but based on recent quotes, you can expect roughly **$150-$200 per node per year**. This is where your architecture dictates cost.

The critical variable is your "node" count. If you have a monolithic infrastructure with a handful of critical database and SSH bastion hosts, Teleport can be cheaper. If you operate a microservices environment with hundreds of distinct SSH endpoints, Kubernetes clusters, and database instances, Teleport's cost scales linearly with that count, while Boundary's remains user-focused.

Here's a simplified cost comparison table for two scenarios:

| Scenario | User Count | Target Host/Node Count | Boundary (Annual) | Teleport (Annual Est.) |
| :--- | :--- | :--- | :--- | :--- |
| Consolidated | 100 | 20 critical servers | ~$5,400 | ~$3,000 - $4,000 |
| Distributed | 100 | 200+ services & nodes | ~$5,400 | ~$30,000 - $40,000 |

The operational overhead is the second cost layer. Boundary is primarily a session broker and credential injector. It delegates the actual authentication and secret management to your existing identity provider (e.g., Okta, Azure AD) and Vault cluster. Your cost there is independent. Teleport bundles its own CA, audit logging, and identity-aware proxy. This can reduce the complexity of your stack but also centralizes more operational burden into one system.

From an architectural standpoint, deploying Boundary into an existing K8s cluster is straightforward. A minimal Helm values setup for the controller and workers might look like this:

```yaml
# boundary-controller-values.yaml
controller:
replicas: 3
config:
listener:
tcp:
address: ":9200"
purpose: "api"
database:
url: "postgresql://:@boundary-db:5432/boundary"
# KMS configuration for root key is CRITICAL (omitted for brevity)

# boundary-worker-values.yaml
worker:
replicas: 2
config:
listener:
tcp:
address: ":9202"
purpose: "proxy"
controller_addresses: ["boundary-controller.boundary.svc.cluster.local:9200"]
initial_upstreams: ["boundary-controller.boundary.svc.cluster.local:9201"]
```

You'll need to manage the PostgreSQL database, the KMS for root key encryption, and the integration glue with your IdP and Vault. These are additional operational pieces that aren't in the license cost.

**Final Analysis:** For 100 users, Boundary's pricing is predictable and often lower if your target infrastructure is large and dynamic. Teleport can be more cost-effective if your environment is consolidated and you value an all-in-one solution. However, the true "cheaper" verdict depends on your existing stack. If you already have Vault and a robust IdP running, Boundary integrates as a lego piece. If you're starting from scratch, Teleport's bundled approach might reduce initial SRE toil, albeit at a potentially higher licensing cost for node-dense environments.

I'm interested in hearing from teams who have made this switch, particularly around unexpected operational costs or latency introduced by the proxy layer. My own latency charts from a POC showed a consistent 12-18ms added by Boundary's worker proxy under load, which was acceptable for our use case.

-- k8s