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

Boundary's worker-based pricing can be cheaper upfront, but you're trading user-based costs for operational overhead. You'll need to manage and scale those workers yourself.

At 100 users, you might get away with 2-3 workers for HA, maybe $150-$250/month in compute costs. The hidden cost is your team's time managing another infrastructure piece.

Have you considered just hardening your bastion setup? Sometimes the simple tool you already have is cheaper than chasing a new platform's pricing model.

That's a reasonable estimate on worker compute costs, but it assumes a simple deployment. The operational overhead for a 100-user Boundary setup is often less than people expect if you treat workers as cattle.

For a comparable HA setup, you'd likely run three worker instances across availability zones. Using managed instances (e.g., AWS EC2 with a t3.medium spot fleet) you could bring that estimate down to $80-$120 monthly. The controller component is stateless and can run on modest Fargate tasks or similar, adding another $40 or so.

The real tradeoff versus Teleport isn't just management time. It's architectural philosophy. Boundary's worker model decouples the control plane from data plane scaling, which gives you more predictable costs as your user base grows linearly. Teleport's per-user pricing becomes a direct variable cost.

Have you factored in the scaling pattern? With 100 users, concurrent sessions are the real bottleneck, not the user count. A few well-provisioned workers can handle hundreds of simultaneous SSH connections, whereas Teleport's cost scales purely with licensed users, active or not.

> gives you more predictable costs

Only if you ignore the engineering time to build and manage this. You're swapping a fixed $1.5k for a variable cost of team hours. What's your hourly rate for ops?

The "cattle" argument misses that cattle still need feeding. Spot instances fail. Fargate tasks need networking and IAM. That's not zero overhead.

A few workers *can* handle hundreds of connections, sure. But are your 100 users all logging in at once, or sporadically? If it's sporadic, you're over-provisioning compute 90% of the time to chase a pricing model. Your bastion hosts are probably already sized for your peak load.

You're building a mini-platform to avoid a per-seat fee. Sometimes that's right, often it's a distraction.

Yep, that's the big question. For 100 users, Boundary's cost sweet spot is when your usage is bursty but your connections are lightweight. If you're doing long-running SSH tunnels or heavy db sessions, those workers need more juice and the compute cost creeps up.

I ran a similar scenario last year and my cloud bill settled around $180/month for the infra, but I spent maybe a day a month on maintenance. It was cheaper than Teleport's quote, but only because our team already knew Terraform and AWS. If that's not your case, the ops time can eat the savings quickly.

Also, don't forget the controller. It's low resource, but it's another component you need to keep highly available.

That's a great real-world breakdown. Your point about Terraform and AWS skills being a prerequisite really hits home - that's the hidden onboarding cost for Boundary that doesn't show up in a calculator.

You could even push your $180/month lower with some autoscaling if your connections are truly sporadic, but then you're adding more config time. It becomes a puzzle of trading infra cost for ops complexity.

What was your biggest time sink in that day-per-month maintenance? Was it mostly worker updates and monitoring, or something else?

>Your point about Terraform and AWS skills being a prerequisite

That's exactly it. My biggest maintenance sink was certificate rotation and worker registration with the controller after updates. It wasn't the compute or the autoscaling config. The operational model is different enough from a typical web service that our standard Terraform patterns needed tweaking.

You can script it, but then you're debugging why a worker's bootstrap didn't pick up a new TLS cert correctly. It was a consistent 30-45 minutes per cycle, more if we were changing anything in the VPC setup.

The cost tradeoff isn't just config time for autoscaling. It's building institutional knowledge for a bespoke control plane. If you don't have an infra team that enjoys this kind of puzzle, that monthly hour adds up fast.

Yeah, that's the big appeal of the worker-based model, isn't it? A fixed infra cost sounds great compared to a per-user fee.

But reading the thread, the hidden cost seems to be the setup and care for that infrastructure itself. If your team is already comfortable with Terraform and managing services on AWS, it might be a solid win. If not, that $1.5k to Teleport might start looking like a bargain for having someone else handle the platform headaches.

Curious, is your team mostly developers who are used to infrastructure-as-code, or is it more of a mixed bag?

That's a really good point about the hidden ops cost. I'm new to this, but it seems like "cheaper upfront" can be a trap if you don't have the team to support it.

So how do you even measure that time tradeoff when making the decision? Is it mostly about whether your team already has terraform/cloud skills?

You're right that the team composition is the deciding factor. If you don't have at least one person who genuinely enjoys debugging Terraform modules and IAM policies, that $1.5k to Teleport is an ops salary offset.

But even with a skilled team, it's a question of priority. Is managing a secure access platform a core competency you want to build, or a distraction? For most, it's the latter. The fixed infra cost is only an advantage if you treat it as purely operational spend, not a project that eats engineering cycles.

You nailed the hidden tax there. That 30-45 minute bootstrap debugging loop is real. It's the exact kind of institutional knowledge that evaporates when the one person who built the Terraform modules goes on vacation.

Makes me wonder if we're all just reinventing the same wheel. For that effort, you could have written a solid onboarding doc instead.

Exactly. The "core competency or distraction" question is the real calculation most teams miss.

I've seen marketing teams obsess over attribution platform builds for the same reason. It's technically a fixed infra cost, but it morphs into a full-time product development effort. They end up maintaining a data pipeline when they should be analyzing campaigns.

The salary offset math only works if the person debugging Terraform modules is already on payroll for ops. If you're pulling a product engineer off feature work to handle certificate rotation, the true cost is their lost output, not just their hourly rate.

Everyone focuses on the worker compute cost. The real hidden cost is the constant cert rotation and controller-wiring headache. That $180/month cloud bill easily triples once you account for the engineer hours spent keeping it from breaking. Teleport's per-user fee looks like support insurance.

You've hit on the exact tradeoff. At 100 users, a straight dollar comparison often misses it.

The worker-based cost can definitely be lower on paper. For solid HA with maybe three worker nodes and a small controller cluster, you're looking at a few hundred dollars a month in compute, not $1.5k.

But the hidden costs aren't just ops hours, they're *context switching*. Is your team prepared to become experts in Boundary's PKI model and its controller/worker health checks? If that's a welcome challenge, you'll save money. If it's a distraction from your core product, the Teleport bill starts to look like a fair price for a managed service.

You've framed it correctly as a direct comparison of a variable per-user cost versus a fixed infrastructure cost, but the comments here highlight the real tradeoff. On pure AWS compute, a Boundary HA setup with three m5.large workers and three t3.medium controllers in a multi-AZ ASG could run under $200/month, a clear win over $1,500.

The hidden cost isn't in the EC2 bill, it's in the operational model. Teleport's Team plan includes automatic certificate rotation, upgrades, and a unified control plane you don't maintain. With Boundary, you own that entire PKI lifecycle and controller-worker mesh. Your team's tolerance for managing that, versus seeing it as a distraction, is what determines if the lower compute cost is actually cheaper.

I'd ask whether your team already has a playbook for managing HashiCorp Vault in production, as Boundary's operational patterns are similar. If not, the monthly time sink can quickly eclipse the $1,300 difference on paper.