Get the top HN stories in your inbox every day.
MuffinFlavored
> 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".
chine
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?
freedomben
Not GP, but without supporting bash scripts the tool isn't very useful to us
hunter2_
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?
mkoryak
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.
Too
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.
MuffinFlavored
https://github.com/windmill-labs/windmill
You're kind of competing with this, though?
nerdchum
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.
freedomben
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.
jjoonathan
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.
debarshri
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.
pankajdoharey
At this point i just use ChatGPT to build the UI's for my script. What else does this offer?
codegeek
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
raviparikh
(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.
echelon
YC likes the idea.
They're betting on multiple teams so they have a higher chance of picking the winners.
raviparikh
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.
debarshri
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.
theturtletalks
Retool was the first-mover and one of these is trying to be "the" open-source alternative to it.
bityard
*open-core
ramraj07
I think this is closer to streamlit and pynecone. Retool is lo code and very different imo.
rubenfiszel
airplane.dev itself is not YC backed, but one of the founder is a YC alumni
quickthrower2
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
uoaei
An investment firm is hedging its investments. Seems pretty straightforward to me.
undefined
kmod
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.
RadiozRadioz
So, it's Rundeck with a nicer user interface?
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?
peter_l_downs
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?
chine
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
zerkten
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.
lredd
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?
kfk
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.
andresgaitan
Sounds similar to Jenkins, rundeck, Ansible tower, awx etc
RhodesianHunter
I would not say these are friendly to non-technical users.
Hell, I wouldn't call Jenkins friendly to technical users.
lredd
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.
verdverm
So you are targeting non-technical people and then asking them to write code?
nikunjk
Congrats on the launch! Curious how is this different than interval or windmill?
rdelpret
How do you compare this to [lyft/clutch](https://github.com/lyft/clutch) and would you ever consider integrating with [backstage](https://github.com/backstage/backstage)
lredd
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?
mindvirus
Congrats on launching! This looks great; everywhere I've worked has had a bad version of this built up ad hoc, so I can see this being really useful. I could see it working well with Retool and other low code tools effectively giving the operations and customer support teams better tooling to work with.
codazoda
Why require me to setup an organization that is public? I just want to try it out and that was a non-starter.
lredd
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!
Get the top HN stories in your inbox every day.
Hey HN! Chine and Lindsey here from Onu (https://joinonu.com). Onu lets you write scripts and turn them into internal tools suitable for use by non-technical teammates. We built Onu to help you spend more time coding and less time running scripts for ops or customer support. Unlike no-code/low-code products, we’re code-first and let you use your preferred tools. We take care of the annoying parts for you: most importantly the frontend, but also auditing, permissions, and 3rd party integrations (e.g. Slack, email, Jira, Pagerduty).
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!