[HN Gopher] Launch HN: Onu (YC W23) - Turn scripts into internal...
___________________________________________________________________
Launch HN: Onu (YC W23) - Turn scripts into internal tools in
minutes
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!
Author : lredd
Score : 114 points
Date : 2023-05-31 17:19 UTC (5 hours ago)
| yamtaddle wrote:
| 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?
| shrimpx wrote:
| 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.
| the_reformation wrote:
| 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.
| yamtaddle wrote:
| 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.
| lredd wrote:
| 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!
| lredd wrote:
| 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
| codazoda wrote:
| Why require me to setup an organization that is public? I just
| want to try it out and that was a non-starter.
| lredd wrote:
| 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!
| codazoda wrote:
| Ah, thanks for the clarification. Adding "of your
| organization" would clear that up.
| lredd wrote:
| I agree! We'll work on that.
| mrwnmonm wrote:
| [flagged]
| antisthenes wrote:
| I can turn scripts into internal tools in seconds.
|
| pyinstaller my_script.py -F
| pkiv wrote:
| congrats on the launch!
| lredd wrote:
| thank you!
| MuffinFlavored wrote:
| > 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".
| nerdchum wrote:
| 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 wrote:
| 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 wrote:
| 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.
| lredd wrote:
| 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.
| Reebz wrote:
| 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.
| chine wrote:
| 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 wrote:
| Not GP, but without supporting bash scripts the tool isn't
| very useful to us
| hunter2_ wrote:
| 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?
| xeromal wrote:
| 100% but I assume they are requesting first-class
| support.
| PetahNZ wrote:
| Not to mention most of my bash scripts are just wrappers
| around calling some other binary executables
| mkoryak wrote:
| 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.
| sisve wrote:
| 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
| RektBoy wrote:
| Redteam approves. hehe
| achille-arouko wrote:
| Integrations \0/
| lredd wrote:
| We've got a Slack integration, and we're working on many more!
| Any in particular that would be most helpful to you?
| alexcnwy wrote:
| Very cool, congrats on your launch!
| lredd wrote:
| thank you!
| connorkinde wrote:
| 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!
| thunky wrote:
| > 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.
| chine wrote:
| 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.
| connorkinde wrote:
| Makes sense, good luck with the launch :)
| andresgaitan wrote:
| Sounds similar to Jenkins, rundeck, Ansible tower, awx etc
| RhodesianHunter wrote:
| I would not say these are friendly to non-technical users.
|
| Hell, I wouldn't call Jenkins friendly to technical users.
| lredd wrote:
| 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 wrote:
| So you are targeting non-technical people and then asking
| them to write code?
| lredd wrote:
| 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.
| verdverm wrote:
| 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?
| [deleted]
| spacebacon wrote:
| A y combinator surmounted by a twin jested hyperencabulator
| TBloom wrote:
| Thoughts on how you compare to airplane.dev?
| lredd wrote:
| 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.
| rubenfiszel wrote:
| 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?
| lredd wrote:
| 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).
| rubenfiszel wrote:
| 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.
| alexarena wrote:
| 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.
| peter_l_downs wrote:
| 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 wrote:
| 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
| revskill wrote:
| HN seems to partner with Discord now.
| dang wrote:
| 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.
| zerkten wrote:
| 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 wrote:
| 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?
| rdelpret wrote:
| 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 wrote:
| 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?
| kmod wrote:
| 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.
| codegeek wrote:
| 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
| shrimpx wrote:
| Also Pynecone.
| paulddraper wrote:
| And Retool.
|
| YC thinks that the space will grow, and it wants to have the
| winner.
| rubenfiszel wrote:
| airplane.dev itself is not YC backed, but one of the founder is
| a YC alumni
| theturtletalks wrote:
| Retool was the first-mover and one of these is trying to be
| "the" open-source alternative to it.
| bityard wrote:
| *open-core
| uoaei wrote:
| An investment firm is hedging its investments. Seems pretty
| straightforward to me.
| raviparikh wrote:
| (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 wrote:
| YC likes the idea.
|
| They're betting on multiple teams so they have a higher
| chance of picking the winners.
| raviparikh wrote:
| 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.
| [deleted]
| debarshri wrote:
| 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.
| ramraj07 wrote:
| I think this is closer to streamlit and pynecone. Retool is lo
| code and very different imo.
| nikunjk wrote:
| Congrats on the launch! Curious how is this different than
| interval or windmill?
___________________________________________________________________
(page generated 2023-05-31 23:00 UTC)