zlacker

>>InitEn+(OP)
Hello, founder here. Thank you for submitting Windmill. We're really close from hitting v2 (adding multiplayer with yjs is our last milestone) and would have waited a bit before submitting but here we go.

We are fully open-source (AGPLv3) with just one ee plugin for syncing the cache of the workers at large scale (more on that below). You can deploy it on a small ec2 instance with our docker-compose or on very large clusters with our helm charts: https://docs.windmill.dev/docs/advanced/self_host

We are an onion of 3 layers, which are usually separated verticals and the closest services we replace in each vertical are: Lambda + n8n/temporal + Retool:

- Workers implemented in Rust that can run any scripts from source in python/typescript(deno)/go/bash. They are extremely efficient, with most typescript scripts being able to run in 40ms e2e. This can be seen as a self-hosted lambda except it works very differently. Lambdas spawn microvms using firecracker and launch http servers within those micro-vms. We run the scripts bare (with isolation using nsjail on our multi-tenant instance) but cache very aggressively the dependencies. For instance, in python we analyze the dependencies using the AST: https://github.com/windmill-labs/windmill/blob/main/backend/..., infer the dependencies from there, have them go through pip-compile to generate a lockfile (and cache the result), then create a pathset similar to how virtualenv behave with the version of each dependency locked. For typescript, we leverage the very well made immutable deno cache. The cache works well but if you scale your cluster to more than 10 workers, the likelihood of having your worker see dependencies for the first time increase, which is why we reimplemented a pip scheme backed by s3 that is extremely fast (we do not compress, just tar individual wheels and s3 is very fast on local networks). For all the supported languages, we parse the signatures of the main function to infer the corresponding json schema of the payload to trigger them, and from that jsonschema we can then generate automatically the UI and infer the input shape required in the flows for that particular step.

- A workflow engine re-implemented from scratch which can be seen as a distributed FSM and whose state is stored in postgresql and every transition done through postgres transactions. Every worker is picking a job and progressing the fsm at completion. The full spec is at: https://docs.windmill.dev/docs/openflow. We support branches, for loop, suspend/sleep, approval steps, sharing the same folder between steps and everything you would expect from a temporal like engine (retries, error handlers).

- A dashboard/app builder that is very similar to Retool but much faster because it's implemented in Svelte and which can also run python scripts directly leveraging the 1st layer. We also support full react apps: https://github.com/windmill-labs/windmill-react-template

We have a CLI that allows you to sync from github directly: https://github.com/windmill-labs/windmill-sync-example or your local filesystem. Our scripts are absolutely normal scripts so there is no lock-in, and they are executable locally https://docs.windmill.dev/docs/advanced/local_development so you do not have to use our webeditor if you do not want to but our editor supports pyright and deno lsp through our dedicated backend communicating to monaco using websockets.

We also support worker groups to run some jobs on hardware accelerated machines (GPU) and a lot of other features (oauth syncing of the resources, schedules, granular permissioning, groups and folders).

Every script/flow deployed has a dedicated webhook endpoint to run synchronously and asynchronously. Scripts are never overwritten, they keep a lineage of hash for each version and have per-hash dedicated webhook to ensure their behavior never change.

We also have a hub for sharing re-usable scripts https://hub.windmill.dev to be used in flows to have some of the same convenience you can find in Pipedream or Zapier.

Our closest alternative would be Airplane.dev, but they're not open-source, not self-hostable air-gapped, less performant, less-featured and much more expensive. You can self-host us fully free.

We are used in production at scale in clusters of 50 nodes+ and thanks to the reliability of Rust and Postgresql have had no downtime to report.

I'm a solo founder, YC S22. The MVP got some attention at the very beginning: https://news.ycombinator.com/item?id=31272793 but was very bare. Now we're ready to bring this to the next level and enable all engineers to spend more time building and less time reinventing the wheel thanks to it :)

>>rubenf+YB
Your product sounds extremely great! I'm hooked!

One nitpick: In my humble opinon, you should switch from Discord chat to Zulip.

It's completely open-source (Apache 2, self-hostable, free full cloud plan for open-source projects) and has an excellent threads-first (called "topics" model): https://zulip.com/why-zulip/

It can run fully in the browser, but it has desktop and mobile clients as well.

It also supports public channels which AFAIK discord doesn't. So you can link to specific messages inside a GitHub issue and anyone who doesn't even have an account can see the relevant messages and context.

Interestingly it's what the Rust language team (and community) uses for comms: https://rust-lang.zulipchat.com

(I'm not affiliated in any way with Zulip btw, I just love the product)

>>EMIREL+BP
I'm very tempted and agree that Zulip sounds much better than Discord. The only thing I'm a little bit worried about is that I have noticed that most people hate having multiple chat clients open and that discord seem to be the de factor standards for open source projects. I apologize to be contributing to the network effect and will strongly consider switching to Zulip.

>>rubenf+KQ
I would suggest against it, Discord is the de facto standard, especially with the younger crowd, millennials and Gen Z. Everyone already has it installed and everyone knows exactly how it works, and it also "just works". I've never even heard of Zulip and I hang out on HN almost every day.

>>enlyth+GD1
Just because everyone knows how it works doesn't mean alternatives shouldn't be tried, especially when they're superior in the aspects that matter for the audience you're interested in.

Besides, how do you think a competing product should rise then?

>>EMIREL+yF1
I'm not trying to start an argument here, but I consider less friction and more familiarity to be superior for this use case.

I was trying to provide a contrary opinion because I often see the HN hivemind hate on Discord heavily for no reason, while it's become a ubiquitous piece of software used by younger people that the older generations have been completely sleeping on and still think it's some niche version of IRC for gamers. Discord has hundreds of millions of users, it's a behemoth rivaling the big social networks.

As a random user, if I were trying to ask a question about this piece of software, I want to open the Discord server and ask it, I don't want to start researching whatever Zulip is and how to use it and figuring out how a new interface works

>>enlyth+QH1
It it against the Discord Terms of Service to extend the accessibility of the client past what is available in web standards (and what of that they implement). The regularly ban accounts of people who try to make it more accessible (and often of the users too).

These might be good qualities for a gamer guild or YouTuber community, but it's a real barrier to participating in open source software communities.

Zulip is open, and doesn't have these restrictions (and already had many bridges and accessibility integrations). I participated in the Oil Zulip, and it was less of a hassle tHan to join a new Discord guild and navigating their adhoc rules bots.