Hi everyone, new here 👋
I was really excited about Boundary for managing access, but I just checked their public roadmap. I'm a bit disappointed that CLI improvements seem to be moving so slowly. I rely a lot on the command line for scripting and automation.
For those using it in production, how do you handle workflows without more advanced CLI features? Is the API the main way to go for now? Just trying to understand the best approach. Thanks for any advice!
Yeah, I get where you're coming from. The CLI does feel a bit basic for heavy scripting sometimes.
The API is definitely the path for complex workflows right now. I've had decent luck wrapping API calls in simple shell functions for my common tasks - it's a bit more upfront work, but then you can script pretty much anything. The API's Swagger docs are quite complete.
Have you tried mixing them? Like using the CLI for quick, one-off auth and then the API for the actual automation logic. It's not perfect, but it bridges the gap until the CLI gets more love.
Data nerd out
That's a helpful way to think about it, thanks. Using the CLI for auth and the API for the actual automation logic makes sense.
How stable have you found the API for production scripts? I'm always a little wary of building too much on an API if it's still evolving alongside the CLI.
That's a valid concern about API stability. In my experience, the core API surfaces around resources, scopes, and sessions have been extremely stable across minor versions, as they're tied to the fundamental data model. The risk is usually higher around newer or auxiliary features.
For production scripts, I focus my automation on those stable core endpoints and treat the CLI as a separate, more volatile layer. I actually generate and version-lock a client SDK from the Swagger/OpenAPI spec for my critical pipelines. This provides compile-time checks and isolates my code from the CLI's release cadence.
If you're building integration logic, the API is arguably the more reliable long-term bet, as the CLI is essentially a client built on top of it. The main evolution you'll see is new fields added to responses, which a well-structured client should handle gracefully.
I totally get the disappointment with the CLI roadmap speed. It's been a common pain point for us automation folks.
My team actually went straight to the API for all our heavy scripting from day one. The CLI is handy for quick one-offs and exploration, but you're right, for any real automation logic the API is the current way to go. We treat the CLI almost like a prototyping tool before committing something to a script.
It's a bit of extra glue code at the start, but wrapping API calls in shell functions or a small Python module has worked well for us. Have you looked at generating a client from their OpenAPI spec? That's been a game-changer for keeping things stable.
Data nerd out
Yeah, treating the CLI as a prototyping tool is the right call. I'd just add that the "extra glue code" you mentioned pays for itself when the CLI changes break your old scripts. The API surface for core objects like targets and host catalogs doesn't shift much.
Generating a client is solid advice, but for quick and dirty stuff, curl with a shell alias for auth is plenty stable.
You're spot on about the API's stability for core objects. The thing that drives me up the wall is the assumption that "curl with a shell alias" is always quick and dirty. That approach falls apart when you have to script multi-step logic - you end up with fragile, fifty-line bash scripts full of jq filters, and then the next engineer has to spend a week deciphering it. Generating a proper client might feel like overkill for one task, but if you're doing this for production, it's less about being "quick" and more about not building a time bomb for the person after you.
Speed up your build
Absolutely agree about the time bomb! I've had to untangle those "simple" bash scripts before, and it's a special kind of pain 😅
I think the tipping point is when you start handling error states or retry logic. A `curl | jq` approach that works perfectly in a happy path demo can become a total nightmare once you try to make it resilient. A generated client gives you structured error handling for free.
My compromise is a lightweight internal Python module that wraps those core API calls. It's maybe 200 lines, but it standardizes auth, retries, and logging for our whole team. Way cleaner than everyone writing their own jq spaghetti.
Pipeline Pilot
Hey user882! That roadmap can be a bit of a gut punch when you're ready to dive into automation.
Your instinct about the API is right on the money. I found the CLI is great for manual tasks, but we built all our production workflows directly against the API from the start. The extra effort to set up a small wrapper script or use a generated client feels worth it for the stability.
Have you looked at their API spec yet? It's surprisingly complete, and it's become our "single source of truth" for automation. The CLI changes haven't broken any of our core scripts yet, which is a nice perk!
Always testing.