Launch HN: Onu (YC W23) – Turn scripts into internal tools in minutes
We’ve put up a few sample screenshots at https://joinonu.com/examples, and a demo video here: https://www.youtube.com/watch?v=4XMnBRsktsw.
Many engineers lose hours a week fielding requests from other teams. While most companies have a home-grown internal dashboard (or are using a third party tool builder for this such as Retool), there is still a long tail of scripts that engineers have to run regularly for their ops and CX teammates, either locally or by SSHing into prod. Maybe a user’s account got stuck in a weird state, or you have a script to manually onboard new customers to your B2B product, or you have to run a custom provisioning script each time you add a bike to your e-bike fleet (something we experienced at Lyft).
We experienced these problems while working on engineering teams at Lyft and Stripe. Our teams needed internal tooling, but we didn’t have time to build feature-rich dashboards. Stripe had a homegrown tool that allowed engineers to quickly spin up simple internal tools without writing any frontend code. When we started working on Onu with a different idea we immediately felt the pain of not having a similar tool. We pivoted to working on our current product instead because we already knew how powerful it can be for speeding up engineering teams.
Internal tool builders mostly take a no code/low code approach that requires engineers to duplicate a lot of business logic in the browser. This leads to brittle internal apps that are hard to keep in sync with the business logic in your codebase, and difficult to maintain as you scale. In addition, such tools subject you to point-and-click / drag-and-drop workflows that just aren’t the sweet spot for programmers. We don’t like working that way ourselves, so we focus on a code-first approach, allowing you to hand scripts to non-technical teammates to own and run without engineering oversight.
Onu works with your existing dev workflow. You write scripts in your editor of choice—not the browser—and deploy tasks the same way you deploy any other code. We can host your scripts if you prefer, but you can also add Onu to your existing Express server and our frontend will handle routing requests to the correct script. We currently have a Node SDK and are rolling out Python next.
You can try Onu now by heading to https://auth.joinonu.com/signup and signing up for an account. It’s free for personal use cases and for teams of up to 5 people.
We’re looking forward to your thoughts and feedback!
98 comments
[ 3.1 ms ] story [ 132 ms ] threadCongrats 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.
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.
EDIT/correction: airplane is not YC backed but one of the founders is YC Alumni
YC thinks that the space will grow, and it wants to have the winner.
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.
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.
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
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".
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
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?
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
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?
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.
pyinstaller my_script.py -F
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?
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?
Could you explain a bit more about the differences and similarities between you and windmill
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.
real microphone usually fixes 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?