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?