What does HackerNews think of windmill?

One way to use raw python/javascript/bash on top of a postgres scheduler is to run a single container of https://github.com/windmill-labs/windmill. It only requires a PG connection and does not require a pg extension. It implements a scheduler that is implemented on top of PG and can run any of the aforementioned language in a very practical and observable interface.

Interesting post and would like to bring nuance as the founder of an open-source alternative to Retool and Airplane: https://github.com/windmill-labs/windmill

Our enterprise edition is clearly cheaper (between 2-5x cheaper based on customers migrating away from those) than our competitors but we bet on volume and lack of sales team to make it up for it in terms of margins.

There are pragmatic reasons for it, our community/oss edition is featureful and include SSO so there is a temptation for our customers to just roll with the CE and we cannot be too greedy.

One could argue that support should be sufficient since the jobs ran by windmill are critical, but the main strength of a product like this is reliability and since we achieve near 100% reliability, it isn't sufficient. We are not gonna intentionally make our product less reliable on CE.

The other reason in my opinion is deeply rooted with the nature of open-source: software cost nothing to replicate and it would be a shame to have users not benefit from the right tools just so the pricing can extract as much $$$ as possible.

So ultimately it comes down to the tension between being VC funded (and we are but to a much lesser extent that our prop alternative) and the pricing of open-source. I am deeply convinced that there is a compromise that satisfies everyone by having the different force in presence being kept-in-check. VCs want small seed companies to scale to become global companies; customers and users want to invest in a platform they know they won't have to regret later because of rent-seeking or lock-in practices. True OSS helps companies achieve global scale as long as their product is better (which make me agree with the substance of the post, being cheap is not enough) and also ensure that company can never or hardly employ dark patterns otherwise OSS fork of company's product will be too competitive against itself.

Before being a founder, I was among the most skeptical of OSS with VC backing and I really understand why someone would have a hard stance on it. But I came to realize that good software takes not only lots of hard work, but a focus and a dedicated team that is hard to find without a core team that has strong incentives to make something that people want. So I see the future being dominated by companies that fall somewhere in the following spectrum:

1. OSS products that are public utilities and there are enough needs or the project is interesting enough to have a strong core team that doesn't require VC backing

2. OSS products that are more commercially oriented and have values but wouldn't exist without VC backing

3. OSS products that were able to bootstrap themselves completely and are COSS but without VCs

And proprietary software to slowly become extinct as the world of software become more competitive everyday as the potential grow larger and the number of VCs that will fund open-source grow larger (and the ability to bootstrap those businesses also get easier).

This is amazing syntax. If you are looking for a self-hostable version of this, that can run deno but also python, go, and bash, with primitives similar to airflow and more (retries, cache, suspend, approval steps), check out windmill: https://github.com/windmill-labs/windmill

There's also https://github.com/windmill-labs/windmill and https://github.com/activepieces/activepieces depending on which parts of retool and tooljet you care about.

Have you checked out windmill by rubin ?

edit: link https://github.com/windmill-labs/windmill

That's super cool and this looks more like a POC than a product for now, but if this were to take off, it would complement really well what we do in our own OSS project windmill.dev [1] where users can deploy scripts in typescript/python/go/bash and more complex flows composed out of those same scripts, get a webhook and a UI to trigger them. Users currently have to either set a schedule to regularly poll or setup a webhook on the event source. This would be a consolidated way for them to have all their event sources in the same place.

[1]: https://github.com/windmill-labs/windmill

Windmill | Paris or Europe | Rust + Typescript Founding engineer | Full-time | Remote or hybrid | https://windmill.dev

Windmill is an open-source developer platform [1] to write and turn scripts into endpoints, workflows and UIs. It can be seen as an open-source alternative and cross between AWS lambda, n8n/temporal, Retool and Airplane.dev with an emphasis on performance. Deploy our helm charts on-prem and have a scalable infra and product to build all of your internal tools. We care a lot about correctness and performance at scale as our primary customer audience is enterprise (but many smaller startups and individuals use the fully free OSS version)

Hiring for one Rust + Typescript founding engineers to work on orchestration, workflows, and CLI.

Contact me at [email protected]

[1]: https://github.com/windmill-labs/windmill

For the Windmill [1] project, we wrap deno to make it the backbone of a self-hostable infra to run scripts (like aws lambda), workflows (like temporal/n8n) and UIs (like retool). This release is amazing for a few reasons. We leverage enormously that you can define script with dependencies in the same file and provide a monaco editor backed by the deno lsp through websockets. So without deno, windmill would not be possible. We also support python too but it's a much slower as a language and make more sense for slow, long-running processes like ML.

> Improvements to npm and Node compatibility

Every little improvements to npm compatibility actually unblock a very wide range of npm packages to now 'just work'^tm. I would have been interested to get numbers of incompatible library but `npm:crypto` has been the biggest blocker for our users.

[1]: https://github.com/windmill-labs/windmill

Thank you for open-sourcing especially under MIT license. I am digging through the codebase and finding a lot of interesting things.

I am building another open-source project that is also a self-hosted deno runtime written in Rust, Windmill [1], where we enable to build all of your internal tool and infra (endpoints, workflows, apps) based on scripts (deno, but also python, go, bash). Instead of running one http server continuously for your function, we run it on demand which has its own set of challenges.

We are doing something pretty naive right now: we create a fork and call deno run [2]. It's decently efficient (25ms for a naive script e2e). We are familiar with deno_core and use it in other places to run javascript directly, but for typescript, deno didn't expose directly the root entrypoint as a lib so we had to fork it [3] and are now gonna be able to do the transpiling to js AOT and save the fork for sub 5ms script execution.

We also want to make some functions togglable as high-performance endpoints and for those we would want them to be spawned as http servers to save the cold start. I'm gonna investigate thoroughly the codebase, and thank you very much for having shared it.

[1]: https://github.com/windmill-labs/windmill

[2]: https://github.com/windmill-labs/windmill/blob/main/backend/...

[3]: https://crates.io/crates/deno_cli_lib_windmill

Wanted to shime in on this since we are big supporters/users of deno and building an OSS enterprise-grade platform for a self-hosted lambda that runs deno scripts among others [1].

I think this is unfair because npm has its own set of issues, most notably, if anyone were to sneak up a non obvious trojan horse into the dependency chain, it would take a few weeks to be detected and millions of servers would already be compromised. You can do this with deno too but the norm is to use pinned version and a deps.ts, it takes a bit more than just an innocent npm install to break things.

The real security for scripts is in the sandboxing, permissioning model and providing self-contained scripts that you can read and analyze in one go. So far, node doesn't offer that experience yet. Deno is the leader of innovation in that specific area. It was a bold move and that it is moving back to node compatibility has a lot more to do with network effect and first mover advantage than an inherently bad design.

Bun is likely to have made the correct move by focusing on performance and node compatibility from a business/adoption standpoints (and we will add bun to our supported env as a consequence), but from a security perspective, deno is still the cutting-edge.

[1]: https://github.com/windmill-labs/windmill

We've been very happy customer at https://github.com/windmill-labs/windmill, all of our docker builds are on depot and it replaced our fleet of github runners on hetzner :)

I love deno so much and all of its ideas highlighted in the article (dependency management, security, performance) so much that I've build an entire framework around making scripting enterprise grade that is centered around deno support. The project is open-source [1], we even expose a web monaco editor and made the lsp support available using websocket and json-rpc. The goal here is to build enterprise-grade one-off script and workflows in deno, that can benefit from permissioned credentials, autogenerated UI (by parsing the main function parameters), a workflow engine similar to airflow/temporal, etc ...

We have a hub [2], centered around deno, that serves as our library of integration. An integration for us, is just a script that uses the right dependency to do an atomic action like fetching data or doing a POST.

We are betting big on deno, and are hoping with windmill to be the framework to make it enterprise-ready for other things than webservers (which most of the deno framework currently focus on).

[1]: https://github.com/windmill-labs/windmill [2]: https://hub.windmill.dev

We support both typescript and python at windmill [1]. But our model is doing low-code for the workflows, and actual scripts/code for the steps themselves so it's quite different than trigger.dev. We handle OAuth, refresh tokens and secrets being managed by the platform. It's quite different from trigger.dev considering they are doing workflows entirely in code which has some pro and cons.

[1]: https://github.com/windmill-labs/windmill

Our open-source project [1] was built with nothing but Rust + Postgres on the backend side of things and it allows us to iterate quickly and have very simple deployments for self-hosting. The queue which is the core bottleneck of our stack will eventually get replaced by redis but for a scale of less than 10k/s jobs, it scale incredibly well.

[1]: https://github.com/windmill-labs/windmill

I am working on something adjacent to this problem. We focus much less on data pipelines but on automation, but in the end also have an abstraction for flows that one can use to build data pipeline. The locking-in issue was something I thought a lot about and ended up deciding that our generic steps should just be plain code in typescript/python/go/bash, the only requirement is that those snippets code have a main function and return a result. We built the https://hub.windmill.dev where users can share their scripts directly and we have a team of moderators to approve the one to integrate directly into the main product. The goal with those snippets is that they are generic enough to be reusable outside of Windmill and they might be able to work straight out of the box for orchest for the python ones.

nb: author of https://github.com/windmill-labs/windmill

Correct URL to windmill on GitHub

https://github.com/windmill-labs/windmill

(Or @rubenfiszel could edit their post)

I'm an ex-palantir (left 3y ago, things might have changed) that worked on Foundry and building Windmill [1] which is an open-source framework that would actually be closer to Foundry except we do workflows and not data pipelines.

I do not think the comparison stands between Retool, or this tool and Foundry. There is indeed a sub-product in Foundry called 'Slate' which is an UI builder but it's a small part of Foundry. Foundry is mostly about data pipelines, to do spark transforms on large ETL, and then having lots of product on top of it to make it easy to make Spark work in an enterprise environment such as a UI builder (the slate mentioned above), a graph viewer of the ETL (monocle), a report builder, RBAC, a timeseries processor, data lineage, versioning of the code, a webeditor and so on.

[1]: https://github.com/windmill-labs/windmill

We bet big on deno with Windmill (OSS platform to turn scripts into internal UI and workflows) [1][2] and are extremely pleased. The language design choices and the performances/caching strategies are a perfect match for building a distributed workflow runtime at scale. However, the compatibility with npm was the most requested feature. Before the compatibility mode with npm was released, we were about to build a completely separate mode of execution based on node. This solves it very elegantly.

Also super excited about the lsp improvements. I believe we are the only project to have a webeditor that features lsp integration with deno in the web (to test, go on [3], New Script -> Next, it works really well). It's very pleasant to work with and make the webeditor experience match closely a local dev setup. We are super excited about the improvements and I am about to try tonight if we can have the inline hints work with monaco. As we are fully open-source, one can see how we are able to pull it off [4][5].

[1]: https://windmill.dev

[2]: https://github.com/windmill-labs/windmill

[3]: https://app.windmill.dev

[4]: https://github.com/windmill-labs/windmill/blob/main/frontend...

[5]: https://github.com/windmill-labs/windmill/blob/main/lsp/pyls...

Congrats on the series B and very interesting approach with the Views.

Developer tools, especially ones around code should be open-source. If you like the idea of productionizing one-off scripts, building flows, and managing secrets and schedules in an integrated platform, we have made the same observation as the Airplane team but in a fully open-source manner: [1]. Being open-source in this space offers a lot of synergies, you can for instance build a community around sharing the modules that compose your flows: [2]

In addition, if your primary languages are Typescript, Python or Go, we offer a more integrated experience by parsing the script parameters directly to generate the input spec and the frontend. We are developing our own UI builder as well, more to be announced in the next month. We just released our helm-charts for easier self-hosted deployments: [4]

You can also try it for free at [5]

[1]: https://github.com/windmill-labs/windmill

[2]: https://hub.windmill.dev

[3]: https://windmill.dev

[4]: https://github.com/windmill-labs/windmill-helm-charts

[5]: https://app.windmill.dev

This is great, thank you for open-sourcing. One limitation is see with this model which is clearly stated in the post is that it is javascript/wasm and HTTP servers only. The deployable workers model is a great one and I had hoped to provide an adapter for the open-source windmill[1] project by transforming the normal scripts that are our units of execution into http servers runnable in workderd.

We support typescript (deno), go and python. Short of those languages becoming 100% transpilable to wasm, we will have to fallback to use firecracker or keep our current system implemented from scratch using nsjail for sandboxing and a fork for each process.

[1]: https://github.com/windmill-labs/windmill

At windmill (https://github.com/windmill-labs/windmill), our whole frontend is in svelte, we love it, the performance are second to none and the dev experience is great. But finding svelte dev is proving itself harder than I thought. So there is that issue as well.

Windmill (YC S22) https://windmill.dev | Founding SWE/DevOps | Rust/Svelte, K8S | Full-Time | Remote/Paris | $90-130k + $100k stock-options

Windmill is the sweet-spot between Retool and Temporal, it is fully open-source (https://github.com/windmill-labs/windmill) and has a hub (https://hub.windmill.dev) for sharing scripts and flows.

Apply here: https://www.ycombinator.com/companies/windmill/jobs

Congrats on the project and company, looks really cool! Funnily enough I wanted to write the same post this week. I got lucky enough to get into this current batch of YC, but in the end you ended up in a great spot if you were able to raise directly 1.6M. Our tools have so many similarities, Windmill is also AGPLv3 (https://github.com/windmill-labs/windmill) and also self-hostable, and also about building custom internal tools. We focus a lot less on UI but on the run custom logic part as flows of Deno or Python (and we actually just released an open spec about it we call OpenFlow: https://github.com/windmill-labs/windmill/blob/main/openflow...). So in that sense we could be greatly complementary. If you would be interested to chat: [email protected].

This is absolutely brilliant.

In windmill, https://github.com/windmill-labs/windmill (self-hostable AWS Lambda, OSS AGPLv3) we infer the jsonschema of your script by doing static analysis but so far we were not doing validation of the payload itself, if your script failed because of incorrect payload that was your problem. Now without any additional effort I will be able to add validation and great error reporting "for free".

Windmill Labs (YC S22) | Founding Rust backend engineer/DevOps/Full-stack | Paris or Remote | Full time | 70-110k + 1-3% | https://windmill.dev

OSS developer platform for multiple steps automation (flows) with minimal python or typescript (deno) scripts. It is an OSS and self-hostable alternative to airplane.dev or pipedream: https://github.com/windmill-labs/windmill

Send an email at [email protected] or apply at: https://www.ycombinator.com/companies/windmill/jobs/WlSHAed-...

Pipedream is listed as an OSS alternative to Integromat ... except it is just the automation that are open-sourced: https://www.opensourcealternative.to/project/Pipedream https://github.com/PipedreamHQ/pipedream

The platform itself is not even source available. I think it's a bit disingenuous in that case. At Windmill (https://github.com/windmill-labs/windmill), we are actually building the OSS platform that you can self-host and that is an actual OSS alternative to ... pipedream.

Windmill Labs (YC S22) | Founding Rust backend engineer/DevOps | Paris or Remote | Full time | 70-110k + 1-3% | https://windmill.dev

OSS developer platform for multiple steps automation (flows) with minimal python or typescript (deno) scripts. It is an OSS and self-hostable alternative to airplane.dev or pipedream: https://github.com/windmill-labs/windmill

Send an email at [email protected]

If your flow is more linear looking than a complex DAG and you want to get a full featured webeditor (with lsp), automatic dependency handling, typescript(deno) and python support, I am building an OSS, self-hostable airflow/airplane alternative at: https://github.com/windmill-labs/windmill

You write the modules as normal python/deno scripts, we infer the inputs by statically analyzing your script parameters and we take care of the rest. You can also reuse modules made by the community (building the script hub atm).

Windmill (YC S22) | Founding Engineer (Rust/Svelte/Distributed Systems) or Internship | Remote or Paris | https://docs.windmill.dev/hiring

Windmill is an OSS developer platform (https://github.com/windmill-labs/windmill) to quickly build production-grade multi-steps automations and internal apps from minimal Python and Typescript scripts.

We are looking for our first founding engineers, stock options grant is generous.

Hello, author here. I did not plan to have a wide announcement today tbh. This is the repo: https://github.com/windmill-labs/windmill

I have my YC interview in 10 minutes and wanted to OSS it before. Agree it lacks a lot of polishing, but that will be done in about 2 weeks :)

JS/TS through Deno is coming in a week, I am currently working on a draft pull request for it.

Really happy to answer all the questions after my interview :)

(I host the demo on a small hetzner node, please be gentle to it, I will scale it up asap :))

PS: Since it's HN: The backend is all in Rust and the feature I am most proud of is automatic parameters and dependency inference for locking the dependency versions and generating the frontend of your app by analyzing the scripts using simple but surprisingly good heuristics :)