Open Source Automation Tools
You notice automation only when it breaks. Left alone, these tools run unattended, quietly accumulate credentials to half your other systems, and fail somewhere downstream where the cause is hard to trace. That makes two things matter more than any feature list: where the automation runs, and whether you can read its logic when something goes wrong. Self-hosting the engine keeps those credentials and the data they touch on infrastructure you control instead of a vendor's servers. And when flow definitions live as files or database records you can version, diff, and restore, a process that stops working at 3 a.m. is something you can inspect and roll back, not a black box you reopen and hope.
Dify
Open-source LLM app development platform for workflows, RAG pipelines, and agent apps
Playwright
Cross-browser end-to-end testing and automation for Chromium, Firefox, and WebKit
Coolify
Self-hostable PaaS for deploying apps, databases, and 280+ services to your own servers
Flowise
Open source visual platform for building AI agents and LLM workflows
Cypress
JavaScript testing framework for end-to-end and component testing in the browser
Huginn
Self-hosted automation for building agents that watch events and act on your behalf
Apache Airflow
Programmatically author, schedule, and monitor workflows as code
EasySpider
No-code visual web crawler and browser automation tool with command-line execution
Appsmith
Open-source low-code platform for building internal tools, dashboards, and admin panels
Our picks
Which fits depends on the kind of automation you are doing, so here is a representative pick for each of the main jobs.
App-to-app workflows: Activepieces For connecting the SaaS apps a team already uses without writing code, Activepieces is the place to start. It offers a type-safe TypeScript pieces framework with loops, branches, auto retries, and HTTP steps, plus human-in-the-loop approvals and delays. It can run fully network-gapped so credentials stay on your infrastructure, and contributed pieces double as MCP servers for LLM tools.
Data pipeline orchestration: Apache Airflow When automation means scheduled, dependency-aware data pipelines rather than app glue, Apache Airflow is the long-standing standard. You author, schedule, and monitor workflows as code, which keeps pipeline logic reviewable and version-controlled instead of buried in a UI, and it self-hosts with Docker.
Browser and UI automation: Playwright For automation that has to drive a real website or app, Playwright controls Chromium, Firefox, and WebKit through a single API for end-to-end testing and scripted browser work. It runs offline on machines you own, so form-filling, scraping, and UI checks never route through a third-party service.
Self-hosted app deployment: Coolify Coolify automates the deploy side of the house, connecting to your own VPS or bare metal over SSH to ship apps, databases, and 280+ services with one click. Because it writes configuration straight to your server, deployed resources keep running even without Coolify, so there is no lock-in.
Which kind of automation do you actually need?
The first fork in the road is not which tool you pick but which kind of automation you are actually doing, because this category quietly holds several. If you are connecting the SaaS apps a team already uses, low-code workflow builders like Activepieces, Automatisch, and Node-RED are the right aisle. If you are moving and transforming data on a schedule, that is orchestration territory, handled by Apache Airflow, Prefect, Dagster, and Kestra. Driving a real browser or desktop is a third job entirely, covered by Playwright, Selenium, and vision-based tools like Skyvern. Deploying your own apps is a fourth, where a self-hosted PaaS such as Coolify or Dokploy fits.
Once you know the family, judge the execution model, because most automation failures come from timing and state rather than logic. A plain scheduler is fine for a nightly script, but event-driven work needs queues, retries, and idempotency so a duplicated event does not run twice. Long-running processes need durable state and the ability to resume from the step that failed rather than replaying everything. Windmill, Inngest, and Trigger.dev are built around exactly this durability, and orchestrators like Dagster add lineage and observability so you can see which step broke.
Finally, weigh where the runner lives and how you get out. Self-hosting keeps secrets and data on your own network, but it hands you backups, upgrades, and uptime. Confirm that workflow definitions are exportable and reviewable rather than trapped in click-built UI state, since that file is your migration and disaster-recovery path. Deployment tools like Coolify write their configuration straight to your server, so apps keep running even without the tool, which is a useful test of how much any option really locks you in.
Related categories
Frequently asked questions
What is the difference between a workflow automation tool and a data orchestrator?+
They solve different problems. Workflow tools like Activepieces or Automatisch connect apps and react to events: a form submission opens a ticket, a webhook posts a message. Data orchestrators like Apache Airflow, Prefect, and Dagster schedule and manage dependency-heavy pipelines that move and transform large volumes of data, with retries and lineage built in. Using an app connector for a heavy ETL job, or an orchestrator for simple glue, is a common mismatch.
Do I need a queue, or is a scheduler enough?+
A scheduler runs jobs at set times and is fine for predictable, recurring scripts. The moment work is triggered by events or must survive restarts, you want durable execution: queues, automatic retries, and resume-from-failure. Windmill, Inngest, and Trigger.dev are designed for that, holding state so a long task can pick up where it stopped instead of re-running from the top and duplicating side effects.
Which of these can control a real website or browser?+
That is browser automation and RPA, a separate group from the workflow builders. Playwright and Selenium drive Chromium, Firefox, and other browsers for testing and scripted actions. Skyvern adds a vision-based, AI-driven layer for sites that change often, while TagUI, Robot Framework, and OpenRPA target broader robotic process automation across web, desktop, and command-line tasks.
Are the self-hosted deployment platforms here really automation tools?+
They automate a specific job: shipping and running your own apps. Coolify, Dokploy, and CapRover connect to a server you own and deploy applications, databases, and services with one click, replacing manual setup and scripts. Coolify also writes its configuration directly to your server, so deployed resources keep running even if you stop using it, which limits lock-in.
How do these tools handle the credentials they need?+
This matters because an automation platform ends up holding tokens for many other systems, which makes it a high-value target. Check that credentials are encrypted at rest, scoped per workflow or environment, and kept out of logs, and prefer role-based access over letting every flow read every secret. Running an option like Activepieces network-gapped keeps those tokens entirely on your own infrastructure.
How do I keep a self-hosted automation from failing silently?+
Silent failures are the real risk, since automations run unattended and break downstream. Favor tools with durable state, automatic retries, and real observability into which step failed. Dagster and Prefect provide lineage and run visibility for data pipelines, and Trigger.dev surfaces retries and queues for background jobs. Then test the ugly cases directly: network outages, duplicate events, and expired credentials.
What happens to my workflows if a self-hosted automation project stops being maintained?+
Your exposure depends on how portable the logic is. If definitions are exportable files or readable scripts and credentials are documented, moving to another runtime is manageable. If your business rules live only as opaque state in a click-built editor, an abandoned project becomes painful. Keep backups of flow definitions outside the app, and favor tools that store logic as code or standard formats you can read without them.