Fast self-hostable open-source workflow engine
windmill.dev
windmill.dev
We are doing a developer platform for enterprise to build internal software, including apis, workflows, background jobs, and UIs using code, but only where it matters. We happen to be quite decent in all aspects, with a focus on performance, and we have an active community of users and customers that are mostly developers and hence have plethora of feedback and feature requests, so we're happy to oblige.
By being at the right level and trying to expose the code as much as possible, we can be great generalists without sacrificing on the quality. Python, Typescripts, Go, Bash and all the query languages are where all the complexity is and capabilities come from. They are well developed languages with great ecosystem. We merely provide a way to run those language in a system fit for production at enterprise scale.
> for enterprise
I mentioned this product to my enterprise boss and his enterprise answer was "we can't easily get this approved by tech-selection committee for no good reason" (and that would have just been to have an off-to-the-side proof-of-concept instance or two running in our sandbox k8s cluster let alone actually bringing it onboard as a paid service)
How do enterprise users not already have the functionality you are offering covered one way or another and why would they migrate off of what they have to what you are offering? What kind of business today doesn't have something like ActiveBatch, AWS/Azure functionality with massive cloud support contracts, etc. already?
But the argument is true for any enterprise software, you cannot be small and sell to enterprise (or you must have amazing product market fit), that's where open-source comes in.
We have overlap with many existing products, but we are the only one to provide such product, with emphasis on DX and excellent performance and scalability, and to be open-source. We do currently have a few big enterprise customers and many enterprise open-source users. It's a lot easier to get approval since they get it for free and it's fully self-hostable and air-grappable. Once they have tried it on a few non-essential workflow and see the benefits, then they are more motivated to make a case internally. Wide net, some catches until it becomes ubiquitous.
I happen to be a really strong believer in open-source so it's not just an adoption strategy but I think it happens to be also fortunately the best strategy for such infra level software.
Your comments make it a bit more clear, but the big question (as an Airflow user) I have is: why would I want to migrate?
A big question for an enterprise customer is typically: will I save money with this? In developer productivity, in resource costs, or something else? Can you unlock new things that were previously not possible?
I wish you guys the best.
The target would most likely be automating HR, Finance and IT workflows and tearing down the shadow IT web of crazy integrations taking place at every larger organization I’ve ever experienced.
We’re talking “new hire” workflow for example, which at my current employer is about 25 activities in a workflow.
All assets have to be lifecycle managed in an enterprise and automated workflows will help you scale that. Far too many enterprises have a lot of people shuffle excel files and emails around to fulfill processes and workflows.
Airflow is a beast imho and usually not used in the same niche IME.
You'll be up against incumbent software that populates teams of workers at the company who have a vested interest in their livelihoods not being taken away, who have the support of whatever commercial organization wants to keep their business. All to provide that +1 value-add you can't even focus on as much as you should due to your efforts being split to compete with multiple other products.
Do one thing well, FIRST. Make it easy to integrate with and build integrations from. THEN expand into the supporting ecosystem.
I’ve also been the person on the other side of that relationship, helping potential customers make a case that my product is worthy of their software/services gatekeeper’s consideration.
There is often high motivation to bring in a smaller/newer tool, because the existing solutions are not scalable, or are missing a critical feature, or require a team of specialized people to make it work, or has onerous licensing costs, etc.
“Shadow IT” is also a very real thing. Someone’s boss is frustrated with the bureaucracy and timeframe for bringing something in and so they just throw it on a corp card or install it themselves and ask for forgiveness later. This happens everywhere and is often the precursor to forcing the product to become officially blessed because by now it’s supporting production workloads and has proven its worth.
This particular space is still ripe for innovation. Very few of the products that target this kind of tool building approach are close to finished and each has its quirks.
I must be misunderstanding the definition of "enterprise" here. I can't picture any of the 3 enterprise companies I've ever worked for adapting any sort of product like this.
I’d be willing to bet money that this was happening where you were, but you may not have been exposed to it. It often shocks IT management what they find when turning on software auto-discovery and inventory tools.
These tools are often employed in operations and other non-core-to-the-business departments to simplify/automate busy work happening there.
My most fond memory was introducing a workflow platform to an enterprise with a fully outsourced IT-ops department - it was ruining everyone else in terms of cost, speed and quality.
The security dept (this was a large bank) was gridlocked in this setup and wanted the ability to automate their way out of the sourcing mess.
I spent roughly three months building a few “hot path” workflows important to them which enabled them to take the ownership back of the processes and save an incredible amount of time and money.
Encapsulating these integrations as workflows makes them observable and measurable. The customer had in the first quarter after deployment 10’s of thousands runs and avg time to completion went from 2 weeks to 2 days. It also cut out an rather expensive middle man.
And this is not the worst enterprise customer I’ve worked with. One hade 4000 Windows servers manually provisioned and managed. There’s low hanging fruit out there!
You basically trade agility and quality for competence, unfortunately a lot of enterprise IT shops are not willing or capable to do so.
We’re talking backoffice/cost-center workflows in IT, finance and HR - absolutely not business profit processes mind you.
A tool such as this can help an IT department take ownership of integrations and workflows, building them in a framework that can improve speed and quality. It will help with organizational scalability.
The alternative is in my experience a giant mess of integrations lacking ownership and observability.
Every large enterprise needs “something” like windmill, they might just not know it.
>Enterprise resource planning (ERP) is the integrated management of main business processes, often in real-time and mediated by software and technology. ERP is usually referred to as a category of business management software—typically a suite of integrated applications—that an organization can use to collect, store, manage and interpret data from many business activities.
What is the difference between a workflow engine and an ERP system?
Why not call it an ERP system if you're targeting the broader enterprise market? As someone who is far from SV, the business people I know probably don't know what a workflow engine is, but they definitely know what an ERP system is.
What does this mean?
We bring that vision in a fully open-source and consistent platform that you can host wherever you please.
For investors:
> We are a developer platform for enterprise, offering a performance-focused solution for building internal software using code. Our open-source platform allows businesses to focus on their unique business logic while we handle the boilerplate tasks, resulting in high-velocity development and the ability to scale at enterprise levels.
For devs:
> We are a developer platform for enterprise, providing a system for running code written in Python, Typescript, Go, Bash, and query languages at scale. Our platform focuses on performance and offers extensive capabilities to build internal software, including APIs, workflows, background jobs, and UIs. With a fully open-source and flexible architecture, developers can concentrate on their business logic while leveraging our robust ecosystem for efficient development and hosting options.
Generic:
> Windmill is a developer platform designed for enterprises to build internal software efficiently. It combines the speed of low-code solutions with the flexibility of coding, allowing developers to focus on unique business logic rather than boilerplate tasks like permissioning, queuing, and front-end development. Our platform is fully open-source, offering high performance and hosting versatility.
> Our active community of developer users provides constant feedback, driving our platform's growth. By emphasizing commonly used languages such as Python, TypeScript, Go, and Bash, Windmill serves as a generalist tool without compromising quality, enabling complex functionalities within a production-ready, enterprise-scale environment.
Like GitHub Actions is a workflow, but it's a convoluted YAML wrapper around shell scripts.
Is a workflow shell scripts? I'm going to guess no. I'm going to guess it's "code". So... why is a workflow code but code isn't a workflow?
Windmill is a "workflow (code?)" orchestrator?
But i do agree that windmill is doing so many things that the elevator pitch need some work. But a lot of companies are trying to do the same. So i do not think people will think of workflow engine + online ide + app builder as a natural grouping in 5 years
If it makes you feel any better, I'm pretty sure I personally couldn't tell you specifically what any of those specifically do in terms of "the one thing they do well" / why anybody would ever use one instead of the other / not need to use all 3 to accomplish the same thing slightly different ways
In that way as people want an easily grokable description, windmill seems to be a super-platform that leverages enough of the important bits that come up.
I am going to try it out!
However, there is one big benefit to being performant which is that you can use the same stack for performance sensitive jobs such as event-streaming use cases. That remove the duplication of infrastructure. The other benefit is that it improve the developer experience overall with fast previews.
LMAX Disruptor can send a message between threads in 53 nanoseconds on average.
So you can essentially fork control flow in 53 nanoseconds and do 2 things in parallel.
Eyeballing my barrier I can synchronize in 42 nanoseconds and up.
Ideally a workflow engine being fast means it can be just the platform you write everything in. The artificial separation between "normal" code and "workflow engines" is completely unnecessary. Our platforms are extremely fragmented, pointlessly so. Remote vs local, statically vs dynamically typed, async vs sync, short running vs long running...
If an engine is written without these arbitrary limitations, it can be more.
1. Sell service to client
2. Email client with scheduling info
3. Agree to scheduling date with client
4. Send client email with documentation and request their data
5. Remind client to send data
6. Alert admins data hasn't been received
7. Beat data out of client
8. Prepare data
9. QA and checkoff service
10. Email client to review and approve
11. Publish/run service
12. Send client stats/results
And I want to move that from spreadsheets, personal emails and admins keeping in their head where everything is at, to web forms and uploads, automated emails and dashboards. I looked at airtable, smartsheet, budibase and many others but they seem to be very project-based, where you are inventing a unique workflow for each project and using it to keep managers on top of where their team is at with the various steps. Project Management vs process management. None of them seem to have decent calendar integration. Few of them seem to be great about emails or scheduled scripts.
I have APIs for my data, or I can code them if needed. I'd prefer a low-code to a no-code approach, where managers have a spreadsheet view and can do some of of the UI work and programmers can make it do stuff and handle integrations.
For instance, we do not have a calendar integration per se but can manage your oauth tokens towards any service (including gcalendar) and allow you to write code using their official sdks.
For spreadsheets, you can build a similar interface in windmill using aggrid.
It seems you also need approval steps and have your workflows wait for events, and that's built-in in our workflows.
The first bash script simply tells a person what to do and hit enter when they've done it.
Then the easiest to automate parts are automated, as and when it's valuable to do so.
Windmill appears to have manual approval steps - so you could try modelling things just with those. Then automate the most annoying/costly/easy to automate steps one by one.
This should be easier to create, and actually solves an initial problem of knowing where everything is up to. If it doesn't help, or the process is too inflexible when reality hits it, you won't have spent too long automating things.
I would suggest looking at workflow systems within the VFX space, which they call "pipelines". They are human-driven and maintained, but support very high levels of process automation.
VFX pipelines are written in Python, but the key thing is, they're very good at a few things simultaneously:
(1) Highly irregular work…
(2) That nevertheless requires lots of process, including of the ad hoc variety…
(3) With high human touch (human in the loop), so calendars, task assignments, timelines, approvals, producer dashboards, etc.
(4) That's repeatable on the next project/opportunity, with as much customization as needed.
As a bonus, pipelines handle billions of dollars of work annually under high pressure, with tens of thousands of users, so there's a lot of hard won experience built into them.
I personally have found that there are three levels of VFX pipeline tech that need to be combined and customized to do everything. This is the most recent stack I've set up:
* Kitsu for the producer/manager level, human task assignments. Mainly for managers, has the calendar functionality.
* Prism Pipeline for software integration (i.e. keeping the humans following the process). This is what people actually do.
* Kabaret for compute work. People usually kick off these jobs, but they're handled by the farm. You'll be responsible for everything that happens here. [0]
Don't try to get by with just one or two of the three, even though feature-wise it looks like you might be able to. Incorporating computer-driven workflows is tricky and requires purpose-built libraries in my experience. Just use the right library for the job, and accept that they all have somewhat overlapping functionality.
For most non-VFX work, you'll need to script access to the browser, since that's where people do stuff today (i.e. with the Prism Pipeline library). Launch Chrome, Firefox, or Edge with a debug port and use Playwright as your "plugin" mechanism, with Prism/Python as the driver. You can make your pages do whatever you want and script literally any web-based process, filling in fields from your database as needed, adding data to the page, etc.
For the last six years, I've run a business that does around $5M of annual revenue using this approach, with 4 FTE people (including me). We handle around 40 million compute tasks a day, but also have all of the "daily work" where humans are in the loop. We do all of the tasks of the type you've listed.
HTH!
[0] If you need fully automated task generation (so, no human in the loop), write "pump" scripts in plain Python that push jobs into Kitsu or Kabaret at a particular interval. I personally run them under a god monitor, and have them exit after, say, 15 minutes (or whatever interval makes sense) to get cron-like functionality. This is useful because you can pause execution of any pump process easily, change the interval, restart them, etc. plus you get easy access to the logs for debugging. The scripts themselves are usually less than 100 LOC. I have around 60 of these that run the automatic parts of our business.
Whenever I need custom, temporary behavior in this part of the business, I copy the pump script, edit the original to avoid the special case, and have the new script only handle the special case (with whatever new behavior I need). Done, takes very little time, and is easy to run temporarily (e.g. for the next week, a common occurrence because some downstream vendor has caused a problem we need to work around).
Another approach to trigger tasks/workflows is to have a server that gets pinged by 3rd parties (e.g. Webhooks) and does the same whenever the endpoint is invoked. We have that too, but it's literally just a few scripts. (Most workflow systems seem to believe this is damn near 100% of the stuff that needs to be "automated.")
I think windmill could have helped with several of the task and automated some. Its very easy to create dashboard and table with statuses. But its def not a process tool, if that was what he was after.
A sibling already gave links to Kabaret and Prism.
Here's the link to Kitsu: https://www.cg-wire.com/
Github here: https://github.com/cgwire/kitsu
All of these projects are targeted at VFX/animation, but there's nothing about them that ties them to those things, it's just why they were developed. You can use them to run any kind of business IMO.
I posted about it because (a) they handle the commenter's use case, and (b) most HN people are probably unaware they exist and would be discouraged into thinking they are only useful for VFX/animation when in fact they are general approaches to running a business that requires high interaction between humans, processes, and background jobs in a very dynamic environment.
Only because you said "sell service to client", schedule date with client, etc.
Something that comes to mind: In Jira my administrators have locked it down so I can't move certain tickets to certain statuses
https://www.atlassian.com/software/jira/guides/workflows/ove...
It also amazes me that people still use text editors that by default doesn't spellcheck. Anyone know what editors that could be? Seems pretty crazy in 2023!
Probably not best for the last line of defence for public articles, but probably good enough.
https://marketplace.visualstudio.com/items?itemName=streetsi...
Actually, that sounds rude, excuse the ‘tism, I’m sorry. I’m just not super familiar with the license stuff, I generally only touch MIT licensed code when it’s work related, but I thought open source generally allows modification to code. So how do you enforce a limit of 10? I just skimmed the code a bit because of this confusion and I see stuff about enforcing a license in there. So couldn’t anyone just remove that license check code if it’s open-source?
If that can’t be modified, then it’s just “source available”, isn’t it? Which to me is also fine, I just feel like I’m being either misled, if you get what I’m saying?
Basically I think this project is pretty cool, so I wanted to bring it up to my boss because I think we have a need for this, and I had previously brought up Airflow, but I don’t know how to explain this to her.
Sorry for the stream of consciousness. Typing on mobile while answering Teams messages and tickets.
The reason that we didn't split them out of the codebase is that it's harder to maintain and would require to load the plugins. We didn't want to waste time on that when we had so much to build.
So I guess I can just self-host for our team of 7 without SSO and we can finally organize these messy cron jobs we’ve accumulated. We would not be reselling at all. Just organizing some annoying aspects of our day to day.
Thanks for the clarification. Much appreciated. If we end up expanding our usage down the road, I’ll see if I can convince her to consider shelling out funds for the SSO stuff too. I’d love to be able to support this project. Seems pretty cool!
You will never have to pay if you do not want to.
We believe there are many reasons to start using Windmill and most of them are not worth monetizing by themselves but we strive to build a software so great that you will move more and more stuff on there and at that point, you will want our enterprise plugins.
We also mostly monetize bigger companies.
Edit: sniped by someone in-the-know
Windmill solved all that for me. I write a short little Python script, paste it into the web UI and boom it's running with good answers for all the above issues. That's great DX.
If workflow engines try to solve every problem they can devolve into plugin and complexity hell. Jenkins issues have caused a lot of headache at my day job lately. I don't want Windmill to fall into the same trap.
In particular, the line "[...] to build a feature on top of Windmill, to comply with AGPLv3 your product must be AGPLv3 [...]" seems to imply the company aligns with the stance taken by Google and other companies: that even calling the application via API is enough to trigger copyleft [1].
This implies that if I were to build a sign-up form that triggers a Windmill workflow in the backend, my entire application would either need to be AGPLv3 or I would need a commercial license.
That's perfectly reasonable, as it means any non-AGPL use will have to contribute back to Windmill via a commercial license. However, it does mean positioning this as an "Fully Open-source" alternative to Airflow is only technically correct. This is much closer in practice to "source available" than how most developers would think as "open source".
If this isn't how Windmill wants their license interpreted, I highly encourage clarifying things.
[0] https://github.com/windmill-labs/windmill#commercial-license
[1] https://opensource.google/documentation/reference/using/agpl...
Out of curiosity: Have you considered alternative licenses like SSPL or the Elastic license, which make a clear(er) delineation between whitelabelling/hosting vs simply using the application? I'm sure I'm not the first person to have written off Windmill because of the AGPL.
If you are using windmill as a whole, you're free to use it however you please with the AGPL but for customers with doubts, we do sell an enterprise/commercial license.
https://github.com/windmill-labs/windmill/blob/main/LICENSE
I'm a bit confused.
It's really made for developers or at least people that want code as a "first class citizen" of the platform. So i has a cli to sync to/from a VCS, VS code extention. But at the same time I have gotten a tech savvy person on the customer success team to create a workflow where they connect to our API and actually create meaningful services way faster then the enterprise developer team would have done.
The script and flows get automatically endpoints to connect to, but all request is saved to db, and picked up by a worker that has to save the result to disk, before the server again pick up the result and send it to a client. So I would not use it to customer. I have used it for a lot of internal tools to employees. Meaning they can wait 1-2 sec, because you can teach them that it works and you provide a lot of value.
Power Automate doesn't have this (unless you hack it into custom connectors) and it's a really puzzling decision.
I guess they want you to use Azure Functions but those need a PhD to understand and the deal with the security surface.
I would like to try windmill instead. Can it cover all those cases, particularly the part where scripts are on the file system? Can I use automatic GUI creation for PowerShell scripts of windmill in such case? Rundeck transmits environment variables with GUI values when starting script.
The binary itself doesn't sandbox your processes unless you're in the nsjail mode. Hence, if you either use the binary raw (without docker) or mount the filesystem to be available to your container, it can run anything that is available on the filesystem.
I didn't succeed to return all output from the powershell, just last value. The only way I got it is by using control "job log". This one however has some custom header of windmill (job guid etc.), so is there any way to show a raw log ?
I generally do not like no-code tools, but first impression of this mix of no-code and code looks intriguing and app feels very nice overall, with great UI and easy to understand features. Good job.
However, we had that feedback a few time so there is a trick. If you write your result in ./result.json, we will process it as the result of your powershell script.
Am I able to install it on Windows? I need windows specific things, such as powershell remoting. One of the good things about Rundeck is that server acts as worker, and it runs on Windows without problems (Installing it is as simple as choco install rundeck). I can then use all windows tools, run applications (including GUI ones) etc. just the same as if I run them outside rundeck, using OTB powershell.
Regarding "Connection to the main database" as far as my use case is, all the settings could live in the file system json files or sqlite if that makes installation trivial for the use case of being very good job scheduler with options to create great jobs UI, logs and management of small number of users (which is a fairly common scenario).
It seems you need a full-blown install of Windmill on each host where actions are to be run.
It's likely that in time I will evaluate Windmill to get a more detailed understanding of this - there's definitely aspects of it that are very substantial improvements on what can be done in Rundeck.
But inevitably, the question of whether to learn & install & maintain two separate systems side by side, with some degree of overlap in their functionality, vs. just picking one system to do the whole job and living with the shortcomings of whatever it doesn't do so well - it's always going to be a difficult one to weigh up.
On a personal note, I write a lot of rust (and love it) but using rust for writing non-backend type of stuff is not something I would do myself. I'm more of a believer of hybrid like polars that optimize the compute in Rust but provide a compatible sdk in python.
We made them as easy as possible to be reproduced
It looks like Workflow is primarily the former (code-in-database), but provides an API to sync things from a git repo. Is there a mechanism to enforce the rule that certain scripts/functionality/secrets are locked behind workflows sourced from a provided repository?
I have chosen another part where i deploy and then it's automatically push to git. Buy windmill proves you with 3-4 really good ways of deploying from 1 cowboy just doing what he wants to the normal EE way of doing software meaning code-in-git and people only have read access to production and can not modify things. You can have separate instance running or just separate workspaces and promote.
I did not realize at first glance you can write a script and then trigger it (with an API key, not sure if you can make a public one or if that's a security nightmare) through HTTP to basically have your own self-hosted AWS Lambda / the whole "serverless HTTP triggers/functions" craze
We require api key because every request is permissioned and hence we need to know who the script is executed on behalf of. For instance, scripts can fetch secrets/variables but those calls will be permissioned with the permissions of the caller which in this case we get from the webhook specific token.
I agree we were not a good fit prior. I think we would now compare favorably as we will offer excellent ergonomics for data processing, leveraging polars, duckdb, and other OLAP libraries to their full extent.
yaml is not real code and so the part that I consider to be real code is that each step is its separate file in python, typescript, that you can edit in your code editor and have your plugins working, testing frameworks. It's normal functions that you can run locally.
It would be possible for us to do like dagster/prefect/airflow which is to use a macro-processing step/decorators to build dynamically the graph which is what our yaml is in the end, a 1:1 encoding of our dag spec called openflow: https://docs.windmill.dev/docs/openflow/
We didn't do it yet because in most cases, the decorators are a lot like yaml, they are a very rigid way of declaring that some functions are nodes that you can chain in limited ways. On the other hand, not providing that mode allow us to put more efforts in the low-code graph builder for now.
But, as someone that love compilers and built a few, I'm very eager for us to provide such a mode so it's probably a few months away :)
We'd love to have your input on the DX for data/ETL once we present it Friday so feel free to join our discord or shoot me an email at ruben@windmill.dev
Our openflow spec is both open-source and has a full openapi definition: https://github.com/windmill-labs/windmill/blob/main/openflow...
you can use that to generate client sdks in any languages and build your own dag with it. That's what one of our customer did building a reactflow to openflow library: https://github.com/Devessier/reactflow-to-windmill
It's not as good as the decorator way but we move fast and if you still have interest for it we could prioritize it (and ask for feedbacks :))
Does this mean that Windmill installation pings back home with info about clients?
I do not believe the EE version pings back either as of now. But I think the plan is to report back with usage. Or i need to report it manually.
The reasons being db migrations are a pain in the relational strongly typed schema world vs the more forgiving paradigm of documents.
"The SSO is free up to 10ppl."
It's weird that "Content Search" is such a pro feature.
But it's a complex software that require software engineers with salaries and we do not want to rely on donations so we do have to give reasons for people to pay. SSO and audit logs are good ways to segment enterprises to support the project.
I thought that multiple features were enterprise-only (like multiplayer, the content search...).
In our world where we don't take security seriously enough, I do think that SSO is essential.
Agreed we just created yet one more standard but the bit about the input transforms being full javascript expressions or the way we encoded suspend steps was impossible to retrofit.
The rest will be a matter of taste
> Off topic: blog posts
> The queue is implemented in Postgresql itself
Tell me you don't understand system design without telling me you don't understand system design
If you know more than others, that's great, but in that case please share some of what you know—without putdowns or snark—so the rest of us can learn.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
Can you "work around" all that? Sure, it's technically possible (well actually it's not possible to solve all of the above, but most of it). Just like it's also possible to take a mini-van and convert it into a hot rod, so it can pick up groceries after it's entered in a drag race. It will just cost you a lot of extra time and money, and do both jobs poorly.
It's NIH syndrome plain and simple. Hipster nerds who want to invent something for fun, rather than using something off the shelf. People decrying "complexity", who then poorly implement complexity themselves, in the form of functionality shoved into a system not built for it. Software architecture by HN meme.
You could store that in a text file, there aren't really any serious requirements.