Launch HN: Onu (YC W23) – Turn scripts into internal tools in minutes

I consult in Enterprise and these tools are technologically great, but their company strategies make them impossible to scale. Their pricing model usually makes them too expensive since they normally are a small part of a bigger solution which has a lot of components to it (including labor…). They also have a very small ecosystem compared to open source frameworks in python, javascript and so on, this means talent will be harder to hire and consulting and outsourcing will be more expensive. Finally, they have a tendency to play with pricing, so you never know what you will pay in 1-2-3 years.

> After signing up, you will have a hosted platform for deploying new internal tools – we call them tasks

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

Yeah almost every company on earth has a VPN and allowing an outside Internet site access to prod servers is not great practice.

Is there a self hostable version of this?

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

Agreed, self-hosting is a must, and for most security-minded/regulated companies it needs to be source available for audits. Deploying a proprietary app at the level this will need to be is a no-go unless you have a big (and trusted) corp behind it.

More modern day SaaS first tools do not have on-prem option instead they have an on-prem agent model that executes tasks and responds back to the main SaaS platform.

N+1 here, I'd like to add that we have a bunch of VPN tunnels and collectively they are a massive PITA. Adding one more is an uphill request.

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.

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?

Not GP, but without supporting bash scripts the tool isn't very useful to us

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?

Not to mention most of my bash scripts are just wrappers around calling some other binary executables

100% but I assume they are requesting first-class support.

If that’s all you want you might as well use Jenkins or a myriad of other similar tools. It’s free and self hosted.

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.

So retool, windmill.dev, airplane.dev and now this one. All YC backed. Very interesting. I wonder what YC thinks when they fund similar companies in such a short span of time.

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

(Airplane founder here) Airplane isn't YC backed. Though interestingly my prior startup, Heap, went through YC and has tons of YC-backed competitors (Amplitude, Mixpanel, Posthog, etc).

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.

YC likes the idea.

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

Not sure if this is what you're implying, but I think it's a mistake to think of YC as a monolithic organization that makes decisions by saying, "idea X is good, we should fund teams doing it."

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.

I dont work for YC but let me share my two cents. It might look similar, but all companies have their own journey, their own insights. In the end out stick to their conviction, pivot to another thing or execute really well or not so well and die. I think YC understands this so they are backing the founders.

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.

I think this is closer to streamlit and pynecone. Retool is lo code and very different imo.

They think the same as someone buying SPX that has many similar companies in the index.

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

Retool was the first-mover and one of these is trying to be "the" open-source alternative to it.

airplane.dev itself is not YC backed, but one of the founder is a YC alumni

And Retool.

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

An investment firm is hedging its investments. Seems pretty straightforward to me.

Sorry that this is a bit of a pet peeve of mine, but I think it'd be helpful if you described what your product is: I agree it's a good idea to list its features and targeted use cases, but those are descriptive properties that don't say what this is.

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.

similar for local/individual usage:

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

and then probably even simple dashboarding like streamlit.

Congratulations on the launch, certainly looks pretty. I think most ex-stripes end up writing something similar, nice to not have to.

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?

cto @ onu here. We currently support adding secrets through our web interface, but if you're self-hosting your Onu tasks you can use your existing secret management service (AWS/GCP Secret Manager, etc) the same way you would throughout your codebase.

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

It's marketed with the ability to create 'production-ready' automation, but (AFAIK) neither your website nor five-minute video demonstrates a task that is not a 'success' and how an end-user might deal with that.

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?

Not related to anything but does the name Onu have some meaning? For me I am always curious why names of companies have no connection to their product (unless this is in a language other than english and means internal tool)

Congrats on the launch! Curious how is this different than interval or windmill?

I haven't looked beyond your example page, but analytics (justifying internal tooling) and compliance (mitigating bad actors) features are required to gain entry in companies who would pay a lot for your product. You can get far without these features, but a lot of companies willing to pay money to automate away human involvement need to meet compliance levels you likely haven't experienced based on the description above.

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.

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?

Sounds similar to Jenkins, rundeck, Ansible tower, awx etc

I would not say these are friendly to non-technical users.

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

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.

Why require me to setup an organization that is public? I just want to try it out and that was a non-starter.

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.

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?

Congrats on the launch - the website is stunning. Have passed it on to the rest of our eng team.

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!

cto @ onu here! we chose propelauth because they handled all of the organization logic for us (creating & joining orgs, managing roles, etc), which saved us a ton of time when we were building our MVP during YC. They're also a YC company and the team has been fantastic and really responsive to all of our questions and requests.

> the website is stunning

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.

Looked at the homepage. Looked at the docs (only way to find out more about WTF I'm looking at, without signing up?).

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?

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

There are similar tools to this but this is nothing like Lambda or CF Workers. Lambda doesn't do anything remotely close to generating frontend UX for a script.

Ah. I wasn't able to figure that out from the homepage, the first docs page, or the "getting started" link in the docs. Homepage has nothing, and the first two docs pages I looked at made it seem like some MVP lambda-alike.

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!

Looks like you define a form declaratively, and write the handler function, and the platform generates a UI from your form description and calls your handler when the user submits the form. Super similar to how airplane.dev got started.

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

Seems like the value proposition is quite similar to windmill.dev

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

Thoughts on how you compare to airplane.dev?

Hi! Thanks for asking -- the main difference is that devs build tools on Onu completely in backend code. Airplane requires some react code to build more robust frontends.

founder of windmill.dev here, a fully open-source alternative to airplane.dev

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?

Hi! Yes, thanks for the clarification! And by "robust frontends" I meant "advanced views," so you're totally right! The goal with Onu is for you to be able to build those advanced views completely in backend code instead of using React. We made this choice so that pure backend engineers wouldn't have to learn React to build internal tools. In fact, I didn't know any react while being an infra eng at lyft! We've heard this from a lot of other backend engineers as well -- they don't want to deal with react components.

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

Agreed, backend engineers do not like writing frontend code. From there, for advanced views, I believe interval.com chose the route of having the frontend being defined in the task itself with an SDK (which I think is what you seem to hint towards?), and for windmill we have a drag-n-drop/retool-like UI builder if react is too much.

interval.com founder here, this is correct! Everything w/ us is defined in our SDK.

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.

audio quality on the demo video is meh - even at highest quality available on youtube.

real microphone usually fixes that.

I can turn scripts into internal tools in seconds.

pyinstaller my_script.py -F

A y combinator surmounted by a twin jested hyperencabulator

HN seems to partner with Discord now.

No, and I've taken out the reference to Discord in the text above. There's nothing wrong with Discord but I always tell founders when launching that it's not in their interest to draw attention away from the HN comments when launching on HN.