We've been testing Boundary for a year to manage access to our internal web tools (like a few admin panels and a staging env). The team's main complaint is the mandatory TCP proxy for HTTP targets.
It adds complexity we didn't want. Instead of just getting a short-lived URL, we have to run `boundary connect` in a separate process or script to create a local proxy tunnel. It breaks the workflow for our less CLI-oriented team members who just want to click a link from the catalog and go.
We're looking at alternatives that offer a more direct, browser-native experience for HTTP(S) applications. Has anyone moved away from Boundary for similar reasons? What did you land on, and how did it handle the transition for both CLI and web-only users?
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.