cofounder/cto @ Onu here! Thanks for this feedback. We're working on a fully self-hosted version of Onu for this use case. Currently users can opt into self-hosting their scripts within their own cloud, but these scripts are still triggered by our hosted frontend (with some auth). Allowing users to self-host the Onu frontend is on our roadmap.
Re: bash scripts - we chose to focus on backend scripts so that engineers can utilize existing business logic since these tend to be helper functions & classes written in the backend language of their application. We're open to supporting bash scripts in the future - would this be something that would be helpful in your org?
At the risk of an extreme facepalm moment given the {obvious danger, code smell, worst practice, etc.} I still feel compelled to ask: don't the languages already supported offer an execution gateway (like the backtick operator or shell_exec() in php) such that an extremely lightweight wrapper would allow this to run your bash scripts?
Well, from the description I gathered the service was going to “TURN (existing) scripts INTO internal tools”. Not “provide a front-end to a framework where you write brand new code to integrate with your business logic”… The first mode seems to add a relatively large amount of value for relatively low effort given the management scripts that already exist. The second seems more like a framework only useful for processes you spend the effort to migrate. Was hoping to see a Rundeck competitor but got an Internal competitor instead?
People who write bash scripts well and people who write nodejs scripts are likely different groups that will want very different things from this service.
Re: bash scripts - we chose to focus on backend scripts so that engineers can utilize existing business logic since these tend to be helper functions & classes written in the backend language of their application. We're open to supporting bash scripts in the future - would this be something that would be helpful in your org?