Feedback: I work for a corporation/organization where everything "useful/meaningful" is behind a tight VPN/firewall. Having scripts run against them hosted in your cloud where it's next to impossible to access our stuff probably makes this useless (aka, we'd need to self host this in "our cloud" or build bridges, etc).

> We currently support Node/Express. We’re rolling out Python SDKs for Flask & Django soon.

I would've thought it was a wrapper around PowerShell/bash "scripts".

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?

You're kind of competing with this, though?

Is there a self hostable version of this?

Otherwise this will be a tough sell to security minded companies I think.

[1] https://airplane.dev

[2] https://wiz.io

[3] https://adaptive.live

EDIT/correction: airplane is not YC backed but one of the founders is YC Alumni

Personally I like that YC remains agnostic to the ideas and is willing to back competitors because it ultimately means more great startups get funded. Later-stage investors care more about conflicts because being involved at the level of taking a board seat matters a lot more for conflicts.

At this point they've backed 1000s of companies; if they had to vet that entire list for conflicts to back their next batch it would be incredibly difficult. Also, given the stage they're investing at, tons of companies pivot and end up competing even if they didn't start out that way.

They're betting on multiple teams so they have a higher chance of picking the winners.

More likely, each of the teams doing each of these startups interviewed with completely different partners who had no idea of the other startups even existing, and in that interview, they thought the founders seemed solid and had thought through their idea well, and chose to fund it. It's even possible some of the people doing these ideas came up with the idea after they got into YC (i.e. they pivoted) - some of the most successful YC startups were companies that pivoted mid-batch (e.g. Brex).

In general YC doesn't want multiple shots on goal in a specific market area. They want as many shots on goal as possible among great founders in general.

Whether you like it or not, you as an org need a tool like this. Concept like these exist since the dawn of enterprise software. Why not bet on all the companies in the space. There will be one winner that covers all the losses.

Only critic I have for onu, is that their tagline is exactly same as the other tools in the space.

Edit: I just checked out their docs. They are basically doing what airplane's first iteration was. I think it is a hard sale. I guess founder of airplane could shed more light.

The less snarky answer is that each companies is run by creative people who will see different opportunities and pivot differently: they are not all the same company copying each other

YC thinks that the space will grow, and it wants to have the winner.

Sure at the end of the day the only thing that matters is if my use case is handled, but after decent effort I was unable to determine that for myself. The problem is that there are a lot of different things that have the properties you've described, and several of my key requirements are not entailed by your description.

As an example, I remember seeing a product that takes a command line tool, inspects the available flags, and produces a UI that lets you fill them in visually. I believe this has all the properties that you have used to describe your product (turns backend code into a tool anyone can use), but I suspect that Onu is different in some essential ways.

Though fwiw for my personal use case I'm hoping for something lighter-weight. It's great you offer a self-hosted option (exposing this stuff to a third party is a non starter for me and I suspect many others) but "self-hosting" connotes mental burden to me, vs other options in the space which are not exactly "hosted" in any sense. I think maybe I'm not really your target customer.

Anyway, I wish you luck! I'm happy to see more competition in the space.

Rundeck is Open Source and self-hostable, whereas this appears to be a proprietary hosted solution, which is prickly given that this tool will theoretically have administrator privileges on lots of stuff it automates.

I've successfully trained non-technical users to do simple tasks on Rundeck, I don't think that's a big issue.

Edit: And less functionality, it seems. No bash scripting or Ansible? Rundeck has a wealth of plugins[1] already, Onu will have to do some serious catchup. As it stands, I'll need to write more custom application code & glue for these Onu tasks than I would otherwise.

The UI does look friendly though, and I've found that it's harder to get businesspeople to use something that doesn't look "modern" like this does. Perhaps Rundeck needs a CSS pack?

[1]: https://docs.rundeck.com/docs/plugins/

How does secret management work? Do you make it easy to access secrets stored in AWS/GCP/Vault, or do I need to manually add secrets to the Oni web interface?

When self-hosting, is the frontend also self-hosted, or am I always using the oni website?

Say I want to write a task for removing a customer and all of their data, for handling account deactivations. I only want the CTO to be able to run this action. And the implementation is going to involve using my app's ORM and performing a bunch of deletions, so I'll need a way to write and test the code for that. How do I write an Oni task that connects to my application as an integration? And how do I check permissions?

The Onu frontend can't be self-hosted yet, but it's on our roadmap.

Your Onu tasks live in a directory in your codebase, so you should be able to write and test them the same way you do with other code in your codebase, and use existing business logic by importing it. Our CLI has a local dev studio for testing out scripts locally before deploying. We're also actively working on user groups & permissions - this isn't live yet, but we're planning to add this directly to our SDK so you can define permissions in code

There is zero chance these customers would let an engineer SSH into a production environment either when they have compliance requirements. Either it'll be some just-in-time access via a jumphost, or production changes need to be scripted separately. I would think about some kind of internal tools API offering. You deploy that onsite and all of these tools work through it. You then start more lock-in. If your current tools just hit internal APIs that exist anyway then your tool is easily replaced.

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?

Hell, I wouldn't call Jenkins friendly to technical users.

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

So what exactly are you solving for?

>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.

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?

Is the 'sweeping it under the rug' regarding errors intentional to persuade viewers Onu is a stable & reliable tool and auto-magically handles it somehow, just an oversight, or am I overlooking where this is documented?

Random question - why did you go for PropelAuth? We're an auth/billing provider and all teams we speak to usually have different reasons for their choices. Would be interested to know!

I"m assuming you're talking about the website you see after you sign up? Because I don't see much on the linked website.

And the examples page is just a few images with text that is too small (for me) to even read.

Doesn't... look meaningfully different from AWS lambdas or CF workers or other things along those lines. Just with way fewer features. What am I missing?

https://github.com/chriskiehl/Gooey - take a python-CLI, make a tk-frontend

and then probably even simple dashboarding like streamlit.

Could you explain a bit more about the differences and similarities between you and windmill

Congrats on the launch.

I am not sure that is accurate. Both airplane and windmill supports defining your task as plain backend code and deploying them from CI/CD using our respective CLIs. The react part that we both support is if you want to build more advanced views that goes past the need of a single form. One difference between airplane and windmill is that airplane require a yaml configuration to define the inputs while windmill automatically infer them from the main function signature. What mechanism do you use yourself?

To define inputs in Onu, devs use our SDK! This is actually what Airplane does as well (I think they deprecated their yaml config).

So instead of writing React code or using a drag-and-drop builder, you define everything ranging from simple forms to more complex views in Node.js or Python code using our SDK.

pyinstaller my_script.py -F

real microphone usually fixes that.