Clutch is super cool! I'd say our main differences are that we offer a hosted product and we're not focused on infra management. While it's clear from this thread that self-hosting is critical for some companies, many others prefer a hosted product so that they don't have to manage any additional infra. They're also specifically aimed at helping devs manage their infra, while Onu's focus is helping devs share scripts with their non-technical teammates. We're seeing that most of our early customers are product engineers who have to interface with ops or CX often. Do you use Clutch?

Regarding Backstage, I've actually never heard of it! I'm skimming through it now and on first glance I'm not sure how we would integrate with them. Do you use Backstage? What would a helpful integration with Onu look like for you?

Hey! Thanks for this perspective! You're definitely right that we don't yet have some of the enterprise level features that we need. This is definitely something we're thinking deeply about and are prioritizing these features on our roadmap!

Re: companies letting engineers SSH into prod environments -- this probably happens at very established companies more than we'd like to admit ;) Chine and I have unfortunately had to do this on numerous occasions at a previous companies. It was super stressful and not great! This is part of the reason why we're building Onu -- to provide a safe and audited way to run business critical scripts.

I'm curious about your internal tools API suggestion. Can you say more about that? What would the API be hitting?

thank you!

This is great feedback! Thanks y'all! We're starting with our hosted product so that folks can sign up and get started immediately. This has helped us get initial feedback and iterate super quickly. That said, releasing a self-serve, self-hosted version of Onu is a big item on our roadmap. We've heard lots of conflicting opinions on the necessity for a self-hosted version of the app, but this feedback definitely helps validate how necessary it will be.

I would expect any company over 500 staff with a functioning InfoSec team will want a more secure option to deploy. Just an idea, but if you must run the service on your end, another option could be single tenants/pods that you provision and the customer holds encryption keys in their KMS and can manage RBAC. Your staff would have only lower level admin ability to start/stop/delete the pod.

Thanks for this feedback! We know our website is pretty barebones right now, but working on putting more info there. We'll also work on making this clearer on our docs!

The main difference is that Onu generates a frontend UI for your scripts! This means that the non-technical folks on your team have access to the scripts that typically only engineers can run. In our experience, non-technical teams typically don't know how to use AWS lambdas or CF works

Hi! Thanks for bringing this up! To clarify, the organizations are not public. On the org creation page it does say "What's the name of your organization? This will be visible to other members." But this means other members of your organization, not anyone outside of it. I hope that helps!

Ah, thanks for the clarification. Adding “of your organization” would clear that up.

I agree! We'll work on that.

Agree! The end users of the tools created on Onu are typically non-technical, while jenkins, rundeck, etc seem to prioritize very technical users. Our goal is to make running the scripts from the Onu platform as approachable and friendly as possible for the non-technical folks on your team.

So you are targeting non-technical people and then asking them to write code?

No, sorry that was unclear! Developers write the code that creates the tools on Onu and then non-technical teams use the tools that the devs create.

Yet this is in your original post?

> Many engineers lose hours a week fielding requests from other teams.

So what exactly are you solving for?

>> Many engineers lose hours a week fielding requests from other teams.

>So what exactly are you solving for?

Not who you are asking, but "fielding requests" needn't only be writing the script but could also be running it because the end user isn't comfortable with the command line. With a more friendly UI around the script, the end user can be provided the link to a webpage and they can run it themselves.

thank you!

We've got a Slack integration, and we're working on many more! Any in particular that would be most helpful to you?