Launch HN: Windmill (YC S22) – Turn scripts into internal apps and workflows
To build internal apps for ops, integrations between services that cannot talk to each other directly, or to run background jobs that run your business logic and analytics, the two main options today are no-code solutions and old-fashioned, roll-your-own scripting. Both have problems, and our goal with Windmill is to find a new sweet spot between the two. No-code solutions are productive if your problem matches the tool exactly - but it not, they are rigid, hard to extend and quickly become tech debt, annihilating their initial time advantage. Indeed, no-code is just code but made by an opinionated someone else and hidden as a blackbox with an UI.
The alternative is to do it the old-fashioned way, writing everything from scratch, both backend and frontend, perhaps deploying it on the latest flavor of serverless, and pray to never have to touch it again because that took way too much time and it has now became a burden that the ops and business team might poke you about regularly.
Furthermore, the landscape of SaaS is specialized tools for everything—alerting, data analytics, administration panels, support management, integration between services—when it feels like a few scripts would have been as good or even better and spared you the need of depending on one yet another tool. This could be even further facilitated if there was a way to import the right bunch of scripts from a fellow community of engineers, tweak it and deploy it like you can do in communities where automation can be shared as simple JSON files, for instance in the node-red or home assistant community.. That’s the idea of Windmill: to bring back the power of scripting in an easy way.
With Windmill, you write normal scripts, or reuse ones made by others, and we make them production-grade and composable. You shouldn’t have to worry about things like http requests or scheduling jobs. We abstract much of that away, making your scripts be both more focused and more composable. You end up doing things the right way but much quicker.
We reduce the complexity of workflows, integrations and internal apps by uniting them all under one banner. At the heart, they mostly have the same needs: workflows with a UI or a schedule. One tool that does it all out-of-the-box offers greater consistency and allows you to grow the complexity of your toolset at your own pace.
I have an academic background in compilers and industry experience in distributed systems. My compiler work made me wary of solving every problem with a domain-specific-language (DSL) or complex frameworks. We can just do more with the well-crafted existing languages like Python or Typescript. Rolling up your own DSL is nice in theory, you can make it very ergonomic and focused on the task at hand, but then you start adding features and either reinvent existing – albeit worse – programming language or decide to stop there. In the very large majority of cases, a well crafted library is vastly superior to any DSL. By being able to use any library of Python and Typescript, we stand on the shoulders of giants.
I have also observed that the best distributed systems are often the most simple as they are more predictable and have invariants that are easier to reason with and scale horizontally. This is why for Windmill, we rely solely on Postgres + our native workers + our http REST api layer. Later on, we plan to build adapters to host the workers on AWS lambda or Cloudflare workers, and the queue on Kafka if your needs are exceptionally high.
At the heart of what we have built ...
83 comments
[ 3.4 ms ] story [ 160 ms ] threadI've seen too many companies with spaghetti integration built on Zapier / Make to orchestrate the user onboarding (CRM, database, Finance tool)
At the beginning it's a good idea and at one point everything start to crash and you wonder how to put everything in a got repository!
Windmill seems really cool
One thing that I misread and I believe others would too is on the main landing page where it has the list of features is one of them says "UI? Done (checkmark)" and the rest of the items don't have any Done or checkmark. It reads like the rest of the items listed aren't ready at all, which based on the docs they are at least available.
About lock-in I completely agree which is why you can just deploy from github and export a tarball of your entire workspace at any point. The scripts can be used outside of Windmill (except if you use our K/V store but you do not have to). The day you want to migrate out, you will just have to redeploy your scripts as lambdas somewhere else.
> do you want to risk with a startup or an established product that reasonably solves your problem
I think it depends greatly and I don't think this is a hard-and-fast rule. If you're adopting a product that is easy to replace and doesn't have huge vendor lock-in, and the startup offering solves your problem better than the established vendor, then a startup might be a better choice. Windmill is an open source product, so even if they went out of business, you'd still have access to the code which is a great way to avoid some amount of the risk surface area.
Whether it's YC-funded or not, each startup deserves to be the focus of its own launch thread. There will be plenty of other opportunities for you to make a case for your own startup.
I agree that it should be a core feature, but I sympathize with companies that need to charge extra for it.
Then again, Github also chargea you $20/month instead of $4/month if you want SSO in a small org, but it’s possible.
WorkOS makes adding SAML to your app incredibly easy and fast. We're powering Vercel, Planetscale, Webflow, Loom, and hundreds of others. Pricing is transparent and scales as you grow. And you don't need to talk to a sales rep. ;)
https://workos.com/single-sign-on
1. A company Acme wants to have SSO in the tools A, B and C that it uses.
2. Another company Balloon integrates with A, B, C to use the admin API for an admin account to modify or delete users in that account
3. Acme logs in to Balloon and connects its admin account of A, B, and C to these integrations.
4. Now Acme has access to employee's accounts in A, B, C through the Balloon's dashboard to modify or delete users etc.
It's pretty insane, so I'll state it again: To have a company connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege. Not counting the base enterprise tier pricing for the auth solution itself. So then I have to roll my own solution if I want to provide it for free, and I get the joy of supporting the long tail of broken SAML implementations on both the service and identity provider sides. For free. In a perfect world SSO wouldn't be a shitshow and everyone could have it for free, unfortunately that is not this world.
[1] Disclaimer, I’m a founder of PropelAuth
If pricing is a problem above that, I'm happy to chat about a discounted plan or higher free limit depending on your use case! Feel free to send me a note at ravi@airplane.dev
One thing you mentioned:
> You can think of it as a superset of both Pipedream and Airplane.dev
I don't think this is true that Windmill is a strict superset of Airplane. Airplane has a lot of functionality that Windmill doesn't seem to offer (based on my reading of your docs). A few things I noticed that are unique to Airplane:
* Ability to store everything in code that you control. In Airplane, we have a CLI that lets you deploy scripts from your own machine to Airplane. You can version control the script code as well as the metadata (name, parameters, validation rules, etc). In Windmill you have to create everything in their UI as far as I can tell. Airplane's approach is more developer-friendly and also allows you to reference other code in your codebase if you want.
* Many ways to create scripts/tasks outside of just Python and Typescript. We have a direct SQL integration, REST-based tasks without writing code, Shell, Docker, etc
* Third-party integrations (Sendgrid, Slack, etc). I only saw Slack in your docs.
There are of course things that Windmill does that Airplane doesn't (for example, Windmill is open source). Just wanted to point out that while our tools have some overlap, there are also many differences that might make one or the other a better fit.
https://github.com/windmill-labs/windmill-gh-action-deploy lets you sync from github, including metadata that are stored in a json file alongside the code with the same name. What this integration does is basically just sending a tar of your repo to Windmill to sync it so you do not have to centralize your code on Windmill if you do not want to. We will provide the same mechanism for local filesystems and CLI or any other source control providers very soon as the approach will stay similar.
It is not a strict superset and the approach are radically different in fundamental aspects, like operating at the source code-level versus container level, but what about the features you do not provide, like a fully-featured web editor with lsp in the backend for smart assistant. The ability to convert script parameters to UI directly and so on.
> * Third-party integrations (Sendgrid, Slack, etc). I only saw Slack in your docs.
This is disingenuous, we provide integrations for anything that has OAuth https://docs.windmill.dev/docs/contributors_guide#add-an-oau... by just needing to append the oauth informations to this file: https://github.com/windmill-labs/windmill/blob/main/backend/.... We have a hub for anyone to provide the no-code module part out of it. We will do it before the community reach a critical mass. I built this in 7 months, the product just got extremely stable and feature-complete so we can now focus on adding integrations. We expect this ways to have thousands of integrations by the end of this quarter when given your current needs for custom work on each module, it will be harder for you to grow your integrations at the same rate. We have much more than just slack already and it's comparable to your current integrations.
We have a public roadmap with all the features we intend to build over the next month if you are curious: https://github.com/orgs/windmill-labs/projects/2/views/1
You have an amazing product but being open-source is not our sole differentiator, we want to build an even better amazing product.
EDIT: The point holds that our docs need improvement and it's fair to assume that every integration that is not named explicitly does not exist. Our approach is very different as we believe less in custom integrations and more on relying on existing libraries in Deno and Python. In Windmill, it is sufficient to write a main function that call an existing library, and that we add the OAuth provider information to the library of integrated OAuth to have a very high quality integration experience so we did not feel the need to name all of them.
Thanks for the clarification. I do think there is a difference between a dedicated, bespoke integration to a tool as compared to your approach, and that different customers may have different needs. I previously worked on an analytics startup, and in that industry, many products took a similar approach to what you're mentioning. However, Segment's strategy was to build first-party, high-quality connectors that took into account the particular nuances of each tool, and they were massively successful as a result.
> We expect this ways to have thousands of integrations by the end of this quarter when you will only have a dozen.
Interesting, looking forward to seeing this!
> You have an amazing product but being open-source is not our sole differentiator, we want to build an even better amazing product.
I didn't mean to imply it was the only differentiator, I meant that it was an example of a differentiator - apologies if that was unclear.
-- Edit --
I just saw the Github repo. Does this section exist[1] in the docs anywhere? Might be good to include.
[1]: https://github.com/windmill-labs/windmill#how-to-self-host
You just need to docker-compose up https://github.com/windmill-labs/windmill/blob/main/docker-c... and you are all set :)
Many reasons why it's important to know that, the one that matters to me personnaly is because of data storage location requirements.
I'm personally from the EU AND in an industry with stricter data control than usual which is why I made that particular point. If that is a possibility for your product then I believe you should absolutely have it somewhere on your roadmap, and then make it extra clear in your "self host" description (things like "on premise", "your data never leaves your server", "retain control of your data", ...). It's usually a lot easier to do it early and stand by it than try to make it possible later.
Best of luck !
On the home page it has the phrase "Self-hostable AWS Lambda" which when clicked takes me to a page entitled "Benchmark" [0]. As someone who doesn't use AWS, and the linked page seemingly not giving me much clear indication of being able to host this outside of AWS, I'm left confused about options for self-hosting.
Often with these sorts of products, I won't necessarily self-host initially, but will almost always want to ensure up-front that the option is there if I want to in the future.
It's perhaps slightly counterintuitive that being clear about self-hosting being available is a big tick for me onboarding as a SaaS customer!
Meant as constructive feedback as Windmill looks very cool!
[0] https://docs.windmill.dev/docs/benchmark/
Edit: Ok I see I misunderstood... that page is showing how Windmill benchmarks against AWS Lambda. I had assumed that clicking on the prominent blue link that mentioned "self hosting" would tell me about self-hosting :-)
On the other hand, one model is to have low code/no code tools, or SaaS that want to add automation as a feature of their product, wrap us to run their backends as we have done a lot of effort on the engineering of the orchestrator/backend and we cannot compete on every vertical. If they all run deno/python code with the OpenFlow format, then everything is interchangeable everywhere!
503 Service Unavailable
No server is available to handle this request.
Here is the magic part to implement the queue in sql: https://github.com/windmill-labs/windmill/blob/main/backend/...
Would you mind talking to us about your problem?
What are examples of things people are building with these services? My context - I work at a 200ish person b2b saas - I don't know of anyone in my company using these, at least not in an official capacity I can see
hoping to learn and b informed
1. The biggest pain we solve is to turn scripts that you would run on your own laptop as internal apps that you can share. If your company make no use of script anywhere and does not need any automation then maybe it doesn't apply to you.
2. Avoid live sql queries in production and use templatized sql query made into apps instead (automatically!). Making live sql queries is common in DevOps, support and ops in general. It can be very error-prone, stressful and inconvenient.
3. Integrations between tools you already use but that are unable to talk to each other.
4. Workflows, code that runs very frequently to react to new events, transform data and run your business logic. Most companies are a frontend on a database that is updated in the background. We make it possible to build those workflows from simple scripts so that you can build it faster, more reliable and easier to maintain.
5. The last one only apply if you are a SaaS that want to provide automation as a feature of your product, or a no-code tools yourself. Because we focused very much on the hard-engineering of orchestration and specs for workflows, you might simply want to wrap Windmill to offer it to your own clients.
If you just want to compile backend and frontend separately: `cd backend && cargo build` `cd frontend && npm install && run build`
A bit of feedback for the website:
- I can't see anything linking to a pricing page / feature tiers. There should be a prominent "Pricing" link in the top menu like all other such services do, even if the paid Tier isn't enforced yet. - the docs should have a page for self-hosting / deplyoment. This is another big one I always look for in any tool. - when I go to https://app.windmill.dev I am redirected to the login, but I can also click the browser back button, which leads to the app page, but all broken because no data is available
Good catch for the back-button bug, we will fix it. Thanks!
Custom domain: not yet but for sure we will add it as an option for the teams plan
I'm sure lots of people are more interested in immediately checking out your cool thing and not necessarily having to read (or skim) a wall of text first :)
As a side note; I've noticed that Launch HN posts are typically very verbose as a rule. Maybe this reflects more on me, but I almost never read them, but still am often interested in the products/services themselves and will hunt down the link to just go and check it out.
It's great to have the backstory and detail there, but to those writing them, it's worth bearing in mind that a large % of people (possibly a majority?) will skim read at best. So link upfront and maybe a TLDR sentence would always be a good opener IMHO.
Edit: Also... congrats on the launch :-)
I'm not familiar with the Deno part of Typescript. Would it somehow be possible to use a C# library as a dependency?
For example https://github.com/OfficeDev/Open-XML-SDK I need for a way to edit (not create) the openXML content of Microsoft Office files