Use case
Open Source Workflow Automation Tools
Check the category before the feature list, and the licence before either. Several of the best-known tools here are not open source in the way you would assume.
Searching for open source workflow automation tools returns several categories of software that are often compared directly despite solving different problems. A team can spend time evaluating or installing a tool before discovering that its execution model does not fit the process they need to run.
"Workflow automation" can refer to three distinct categories of software. Some well-known tools in those categories use source-available or split licences rather than a fully open-source licence. Clarifying both terms makes the feature comparison more useful.
Most of this page covers third-party tools that you can evaluate without Hype Stack. The final section is for readers building a workflow product rather than installing one. Hype Stack provides source code that you clone and run yourself, but it does not provide a hosted workflow service or execution engine.
The three things that share this name
Integration platforms. Connect app A to app B, on a trigger, with a bit of logic in between. Node-RED, Activepieces, n8n. The unit of work is a step that calls an API. This is often what readers mean by a workflow builder.
Process engines. Run a defined business process with state, human tasks, and approvals. Camunda and jBPM live here, usually speaking BPMN. The unit of work is a process instance that can sit waiting for a person for three weeks.
Orchestrators. Run pipelines of your own code, on schedules or events, with retries, dependencies, and backfills. Airflow, Prefect, Temporal. The unit of work is a task in a graph, and the hard problems are failure and time.
Windmill spans parts of this taxonomy. It is code-first by design, written in Rust, runs scripts in twenty-odd languages, and expects a CLI and local development, all of which puts it with the orchestrators. It also ships a flow canvas, so it is often included in integration-platform comparisons. Teams should evaluate it as a code-first orchestrator with a visual editor, particularly when developers will maintain the workflows.
The differences become clear when you compare the unit of work, failure handling, and intended editor:
An orchestrator may be a poor fit for human approval screens, while an integration platform may not support the backfill behavior a data pipeline needs. Start with the row that describes your problem, then compare tools within that category.
Check the licence before you check the features
The term "open source" needs care here because several well-known tools use licences with restrictions beyond those in OSI-approved open-source licences.
n8n is the clearest example, and to their credit they say so themselves.
The source is public and running it costs nothing, so it is open source.
n8n's own documentation explains that because licences approved by the Open Source Initiative cannot restrict how you use the software, they do not call themselves open source. Their Sustainable Use License limits you to internal business purposes.
One repository, one licence.
Source files marked .ee require a separate enterprise licence entirely, sitting in the same tree you just cloned.
We read the licence when we chose the tool.
n8n moved to the Sustainable Use License in 2022, from Apache 2.0 with Commons Clause. A licence you checked once can change under you.
n8n is one clear case. Other tools also separate community and enterprise code, so a repository badge may not describe the licence of every file or published artifact:
- Node-RED is Apache 2.0 throughout, which makes its licensing straightforward for the uses discussed here.
- Activepieces has an MIT core, and everything under
packages/ee/is under its own Enterprise License, which requires a subscription for production use and forbids selling or sublicensing. The repository therefore contains code under different terms despite the MIT licence on the core. - Windmill is AGPLv3 for the source, except the parts behind an
enterprisecompile flag, which are proprietary. The catch is the artifact rather than the source: the published Community Edition images and binaries include that non-public code, and the grant on them lets you distribute the community edition as is but not sell it, run it as a managed service, or wrap it. To hold an actual AGPLv3 artifact you compile it yourself without that flag.
So the practical rule is narrower than "check the licence". Check the licence of the specific artifact you intend to ship, which is usually a container image rather than a git tree, and check whether the feature you are about to depend on lives in the enterprise directory. Source-available and open source are different things, and on these three repositories both live behind the same clone.
Decide whether you need an engine
Before choosing a tool, check whether the process needs a workflow engine at all.
Who needs to change the process without a deploy?
A status column may be simpler than an engine.
- A process your code already knows the shape of is an enum, a queue, and a table recording what happened
- No additional engine to learn, host, upgrade, or secure
- The rules of your business change through code review and ship with everything else
A process engine may justify its operational cost.
- A process engine lets someone who cannot deploy code change an approved process
- A named editor and a real editing workflow justify maintaining the canvas
- Their edits are what needs designing: which steps they may add, what a step is allowed to touch, and who signs off on a change
Process complexity alone does not require a visual engine. Consider who changes the process, whether changes need a deploy, and whether durable execution is required.
If developers are the only people changing the process, code and a smaller state model may be easier to maintain.
Durability is a separate reason to use an engine even when only developers edit the process. A process that must survive a restart halfway through, retry a payment for three days, and prevent duplicate side effects is difficult to implement correctly against a plain database. An execution engine can address those requirements without requiring a visual canvas.
Building the product rather than installing it
Some readers are building a workflow product rather than choosing a tool to self-host. That product still needs several separate layers:
What a workflow product is made of
Temporal, which you run alongside this rather than get from us. It handles process restarts, retries with backoff, and durable step execution.
React Flow, which is xyflow's rather than ours, handles nodes, edges, panning, and connection validation. It is the library behind most node editors you have used. Not in Vault: the wired-up example lives in a different template, Aether, so treat this as a recommendation with reference code elsewhere rather than something you install here.
The definition the canvas edits and the definition the backend executes should use the same type. Otherwise, the frontend can produce a graph the backend cannot execute as expected.
Postgres stores definitions, runs, and the audit data needed to explain workflow behavior. The tables are yours to design: there is no workflow, run, or audit schema in the template because the shape of a run depends on your steps.
Accounts, organizations, roles, billing, a dashboard shell, and a marketing site. The Vault template provides this product layer, which many workflow products need regardless of their execution model.
Vault does not ship an execution engine. It provides the account, billing, and application structure around an engine.
Temporal remains a separate service. The canvas comes from xyflow and is not in the template. You design the run and audit tables. Hype Stack provides the product shell and a typed client-server boundary that can keep the canvas and backend aligned on the graph shape.
That covers part of the system rather than the workflow-specific implementation. You still need to choose an engine, design the graph and persistence model, and connect those pieces to the product shell.
The order to do this in
Start with the category because an integration platform and an orchestrator solve different problems. Then check the licence before building on the tool, including the terms for the artifact and features you plan to run. Finally, ask whether the process needs an engine, since a status column and a queue may be enough for a process that changes only through code.
These checks may leave a short list or show that the existing application can handle the process without another service.
The Vault screens and pack list follow. They show the product layer Hype Stack provides and the workflow-specific pieces you would still need to build or integrate.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.