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

The TCP proxy requirement is the primary reason my last team ruled out Boundary after a proof of concept. It was a deal breaker for exactly the workflow you describe.

We evaluated StrongDM as an alternative. It provides time-bound, direct HTTPS URLs for web applications, which satisfied the click-and-go users. The CLI experience remained solid for those who needed it, using `sdm ssh` or similar commands. The trade-off is that it's a managed service, so you're paying for that abstraction and losing the open-source flexibility.

One caveat: the per-seat pricing can get steep. If your main use case is just a handful of internal web apps, a simpler, application-specific proxy like OAuth2 Proxy or a commercial VPN-as-a-service might be more cost effective, though you lose the unified catalog.

You've nailed the trade-off with StrongDM. That per-seat model was the main blocker for us too, especially when we only needed access for a small group of engineers managing a large fleet of targets.

We looked at Teleport around the same time, which offers a similar direct web experience without the mandatory TCP tunnel. It might be a worthwhile middle ground for the original poster to evaluate, since it's open-core and can be self-hosted. Did your team consider it, and if so, what swayed you towards the managed service route?

Spot on with Teleport being a good middle ground. We went with their hosted platform for the same reason - self-hosting the open-core version felt like rebuilding the same infra we were trying to abstract away.

The killer feature for us was Teleport's Application Access. You get the short-lived, signed HTTPS links you want, and it runs as a sidecar in your K8s cluster. No local tunnels. The cost was predictable since it's based on active users per month, not total seats.

One gotcha: their SSO integration needed a bit more config than expected. But once it was set, the team actually used it. No more groans about CLI steps.

You mentioned OAuth2 Proxy as a simpler, app-specific option, and that's a really good path if the unified catalog isn't a hard requirement. I've seen teams use it successfully paired with something like Cloudflare Access or even a simple, well-documented internal portal. It shifts the maintenance burden from access management to app configuration, but it can be a great fit for a small, static set of web tools.

Your team's frustration with the mandatory tunnel is common and was a key factor in our own evaluation. I'd gently push back on the notion that Boundary's approach is inherently bad, though. That TCP proxy model is central to its security boundary (pun unintended). It provides a clean, auditable session that's completely independent of the client's network stack, which can be valuable for high-assurance environments.

The trade-off is absolutely the user experience for HTTP targets. If click-and-go is the primary need, you're right to look elsewhere. Teleport's Application Access, as others mentioned, or even a purpose-built tool like Pomerium might fit that model better without jumping to a fully managed service.

That architectural point about the TCP proxy is true, but I think you're framing it backwards for most teams. The "clean, auditable session independent of the client's network stack" is a benefit that matters in very specific, high-security contexts, like financials or government.

For the other 95% of us managing internal web tools, that model creates a problem we didn't have. We already have a trusted client - the engineer's laptop on the VPN or tailscale network. Adding a mandatory local proxy just moves the security boundary inward without a real gain, and you pay for it with a broken user experience.

It's the classic security vs. usability trade-off, but Boundary chose the extreme end for all HTTP traffic. That's why Teleport's sidecar model feels like the right compromise - the session is still managed and audited, but it's established server-side where it doesn't punish the end user.

Your team's experience lines up with what I've heard from several other groups trying to adopt Boundary. That extra step of managing a local tunnel process is a real hurdle for adoption, especially when you have users who just want to click a link.

Since Teleport's been mentioned, I'll offer a related consideration: their model effectively puts the proxy in your infrastructure as a sidecar. That's great for pure web app access, but if your team also needs SSH or database connections, you need to evaluate if a single sidecar proxy simplifies things or if you're now managing multiple access patterns anyway.

For a purely web-tool use case, a dedicated application gateway like Pomerium might be the most direct path to clickable links without a local process. It can sit in front of your apps and handle the identity-aware routing, generating the short-lived URLs you're after. It won't give you the unified catalog for non-HTTP resources, but it often fits the internal web tool scenario perfectly.

You're right to highlight the sidecar model's limitation for mixed access patterns. It creates a new operational boundary between web and other protocols that can undermine the 'unified catalog' value proposition.

We ran into this exact split after implementing Teleport for a primarily Kubernetes-based environment. The team loved the direct HTTPS links for ArgoCD and Grafana, but we still had a separate, nagging problem: SSH access to legacy bastion hosts and RDP for a handful of Windows VMs. We ended up with two distinct access systems, which diluted the security audit trail and added training overhead.

If the end goal is a single pane of glass, the evaluation really needs to start with a firm inventory of all required protocols, not just the HTTP pain point. Pomerium is excellent for the web use case, but its lack of SSH/RDP support means you're back to square one for those resources.

Exactly. That split is a huge operational tax.

We solved it by using Teleport for web *and* SSH, but the SSH side required deploying the Teleport SSH service on every target VM. For legacy stuff, that's a non-starter.

If you're committed to a single pane, you're forced back to tools with a client-side component for the non-web protocols. Boundary's model starts to make more sense then, even with its UX friction. The real question is whether unifying everything justifies the cost for *all* users.

Yep, that CLI tunnel friction is real. We use Teleport's Application Access for exactly this - it serves as an identity-aware reverse proxy in our cluster. Team gets a signed URL from the web UI that just works in the browser, no local process. It cut down our support tickets for "boundary connect" issues by a ton.

Have you looked at how your apps handle session/auth? The shift from a client-side tunnel to an infra-side proxy means your apps see Teleport's IP, not the user's. Broke a couple of our naive IP-based allow-lists.

You're right that OAuth2 Proxy shifts the maintenance burden. That's often a worthwhile trade-off for a small set of internal apps, but teams frequently underestimate the configuration sprawl.

If you go that route, each application needs its own OAuth2 Proxy instance or shared deployment, with individual ingress rules and callback URL configurations in your identity provider. This can become a significant documentation and drift problem over time, especially when onboarding new developers who need to deploy a simple internal tool. It solves the immediate TCP proxy headache, but replaces it with a different kind of operational overhead.

The pairing with Cloudflare Access is a solid point, as it externalizes the identity layer, but then you're paying for and managing another platform.

The drift problem with OAuth2 Proxy configuration is real. I've seen it solved by templating the deployment and using a centralized, team-managed configuration repo. But that's essentially building a small platform, which defeats the "simple" appeal.

Your point about Cloudflare Access is spot on. It trades one form of overhead for another - vendor lock-in and recurring cost. For a team that just hates a local proxy, swapping it for a monthly bill and a new admin panel isn't always the win they imagine.

Your experience with the CLI tunnel friction is exactly why my team ultimately pivoted. We were also deep into Boundary and hit that same wall with non-CLI users, it's a real adoption killer.

We landed on Pomerium, and the transition was surprisingly smooth because it functions as an identity-aware reverse proxy. The key was its ability to provide those direct, signed URLs from its web UI - no local process for HTTP targets. For the web-only users, it was an instant win. They just click and go.

However, don't overlook the auth flow change. Since the connection now originates from Pomerium's infra, you'll need to ensure any IP-based controls in your apps are adjusted to trust the proxy's IPs, and confirm your apps can handle the forwarded user identity headers. That was our main migration task.

That's a great summary of the Pomerium experience. It really does nail the web access use case.

We considered it too, but ended up finding two other gotchas beyond the IP/auth headers:
- It struggled with some older web apps that used weird websocket negotiation.
- The session length felt a bit rigid for our support team, who'd often need to keep something open for a long investigation.

Still, for teams with modern SPAs or standard APIs, it's probably the closest thing to a direct Boundary replacement. Did you run into any edge cases like that, or was it pretty smooth sailing after the initial header config?