My team hates Boundary's required TCP proxy for HTTP targets. Alternatives?

That's an accurate breakdown of Teleport's operational trade-off. Their hosted platform does remove the self-hosting burden, but the active user pricing model you mentioned can become a significant variable if your definition of "active" includes automated service accounts or contractors with sporadic access. We saw our bill fluctuate by 30% month-to-month based on login patterns, which required a new layer of usage monitoring we hadn't anticipated.

The pricing volatility for service accounts is a critical, often overlooked, detail. We faced a similar issue during a PoC, where our CI/CD pipelines that used Teleport for database migrations were counted as "active users." The monthly bill became tied to our deployment frequency, which was an unpredictable and unacceptable cost vector.

Teleport's support suggested using their machine ID feature for these automated workflows, which does change the cost structure, but it introduced its own configuration and security considerations. It felt like we were trading one form of complexity for another - operational for financial.

Totally feel you on the machine ID pivot. We had a similar realization - it's not just a config change, it's a whole new paradigm for managing machine auth. It felt like we were building a separate, smaller identity system just to avoid a bill spike.

Have you looked at how Okta or Entra handle their "non-human" user pricing? It's a night and day difference that makes Teleport's model feel a bit clunky for modern infra.

You've hit on the core architectural trade-off: Boundary's model treats all resources, including HTTP, as network endpoints requiring a client-side session. This is excellent for raw database or SSH sessions, but creates the exact friction you describe for web apps. The alternatives discussed here (Teleport, Pomerium) flip this by placing the proxy server-side, which solves the browser experience but introduces a different set of considerations around trust and app modifications.

Since you've been testing for a year, your cost-benefit analysis should be concrete. Quantify the support burden: hours spent on "boundary connect" issues, adoption rates among non-CLI teams. Compare that against the migration cost of adjusting app authentication to trust a reverse proxy's IPs and consume forwarded identity headers. For a small set of stable internal apps, the migration might be straightforward and worth the improved UX. If you're constantly adding new tools with inconsistent auth models, the TCP proxy's consistency, while clunky, might still be the lesser evil.

You're right that Boundary's model is overkill for most internal tools, but calling Teleport a "right compromise" misses its own significant trade-off. That server-side session means you're now trusting a Teleport node's network egress as if it were the user's own machine, which shifts your security model from authenticating the endpoint to authenticating the proxy infrastructure. You've traded a local TCP proxy for a permanent, highly-privileged network bridge inside your environment.

If the client is already trusted via VPN, you're just moving the goalposts. The real question is whether you want the security boundary at the laptop or at a proxy cluster. Teleport's choice isn't inherently more usable - it's just different, and introduces its own operational complexity around that proxy's availability and access controls.

That initial friction is a really common turning point for Boundary evaluations. Your point about workflows breaking for less CLI-oriented users is spot on, and it's often the deciding factor for teams that are more web-focused.

Pomerium, which a few folks have mentioned, really does solve that specific click-and-go problem you're having. The biggest shift for us was adjusting how the apps themselves received auth - moving from a client-side tunnel to trusting the proxy's forwarded headers. If your admin panels can read standard headers like `X-Forwarded-User`, the transition is pretty straightforward for the web users.

For your CLI users, it's a different story though. They'll miss the direct `boundary connect` to a database, unless those targets are also routed through the proxy. Did your team rely on Boundary for non-HTTP targets like SSH or databases, or was it purely for web apps?

Exactly. The header shift isn't just config, it's a cost and compliance pit.

Now your internal apps need robust header parsing, which might mean refactoring or middleware. Miss one, and you've got an auth bypass. Also, you're now paying for Pomerium to proxy *all* traffic, even for users who just needed CLI access. That's wasted spend.

> They'll miss the direct boundary connect to a database

This is the real kicker. So you end up with two access systems: Pomerium for web, and maybe Boundary or something else for DB/SSH. Now you're paying for and managing two tools. Did that dual-system overhead actually save money versus fixing the Boundary adoption problem?

We saw the same cost spike pattern. Teleport's per-active-user model is fundamentally hostile to modern infra where machines talk more than people.

We stopped testing after month three when the projected annual cost exceeded a full-time engineer's salary, just for user logins. The machine ID workaround is a tacit admission their pricing doesn't fit hybrid environments.

You either pay them, or you pay in ops to build a parallel system to avoid their fees.

That exact friction is why we swapped Boundary for a combination of Cloudflare Tunnel and Tailscale last year. For the web tool users, Cloudflare's browser-based access via their dashboard was a game changer. No CLI, just a secure link they could bookmark.

But the trade-off, like others have mentioned, is fragmentation. Our CLI power users doing database work now use Tailscale's subnet routers or `tailscale ssh`. It's technically two systems, but both are so low-touch that the operational overhead is less than the constant support tickets for `boundary connect` failures.

It's not a perfect single-pane-of-glass, but sometimes solving the user complaint directly is better than chasing a unified tool that fights your workflow.

That mandatory proxy is the whole point, though. Boundary's model is that nothing trusts your browser session, which is why it's secure. Every alternative you're looking at will be trading that security for convenience.

The moment you get that "direct, browser-native experience," you've moved the trust boundary into your network perimeter. Now your internal apps have to implicitly trust a proxy's headers, and good luck auditing that correctly across all your different admin panels.

Maybe that's a trade-off you're willing to make, but don't kid yourself that it's just a usability improvement. You're fundamentally changing your security model because your team finds a CLI command annoying.