Thinking about running your own automation server instead of renting one? Self-hosted workflow automation gives you control over data and cost structure, but you take on the servers, updates and backups. It suits teams with some operations skill.
| Item | Value |
|---|---|
| Supported production OS for Airflow (2.8.3 docs) | Linux-based distributions only |
| Windows use of Airflow (2.8.3 docs) | Via WSL2 or Linux containers |
| n8n queue-mode message broker | Redis |
| Default Redis port in n8n | 6379 |
| Binary data in n8n queue mode | Filesystem storage unsupported; S3 external storage possible |
These figures come from the n8n queue mode documentation and the Airflow 2.8.3 prerequisites page. Documentation changes between releases, so check the source before you rely on them.
What self-hosted workflow automation means
With self-hosting, the automation engine runs on infrastructure you control: a server in your office, a virtual machine at a cloud provider, or a container cluster. You install the software, connect it to a database, and decide when to upgrade it.
The alternative is a hosted service, where the vendor runs everything and you only build workflows. Self-hosting does not automatically mean open source, although many popular self-hostable tools are. If you are comparing categories first, our overview of open source software for process automation is a good starting point.
The tools differ a lot in what they automate:
- Integration and task automation tools, which connect apps through triggers and actions.
- Data pipeline schedulers, which run code-defined jobs on a timetable.
- Business process engines, which model human tasks, approvals and long-running cases.
Benefits of running it yourself
The main draw is control. Your data stays inside systems you choose, which can simplify conversations about where personal or regulated information lives. You also decide how far to scale, rather than fitting a vendor’s plan limits.
Other advantages tend to come up again and again:
- Data location: workflow payloads and credentials remain on your own network.
- Customisation: you can add custom nodes, plugins or code that a hosted plan might not allow.
- Cost shape: you pay for infrastructure and people time rather than per-run or per-seat fees, which can favour heavy usage.
- Integration with internal systems: reaching databases and services behind a firewall is simpler when the engine sits inside it.
- No forced upgrades: you pick the moment to move to a new version.
Whether the cost shape actually favours you depends on your volume and on how much staff time maintenance consumes, so count that time honestly.
Drawbacks and hidden costs
The flip side is that you are the operator. Patching, monitoring, backups and restoring after a failure all become your job. A missed security update is now your risk, not a vendor’s.
Scaling is another place where effort appears. A simple single-server install is quick, but busy workloads usually need extra components, which adds moving parts to look after.
- Uptime is on you: if the server is down, automations stop.
- Upgrades can break custom code or integrations, so they need testing.
- Secrets and credentials need careful handling, including a key that must be backed up.
- Support is usually community-based unless you buy a commercial plan.
- Licences vary; check whether a feature you need sits behind a paid tier.
Requirements to plan for
Requirements depend on the tool, so read the documentation of the one you choose. Two well-known examples show the range.
The n8n documentation describes a queue mode in which the main instance passes execution IDs to Redis, a message broker that keeps the queue of pending executions so the next available worker can pick them up. Its docs say that running queue mode with an SQLite database is not recommended, so a server database such as PostgreSQL is the normal choice. They also note that Redis runs on localhost on port 6379 by default, and that the main instance’s encryption key must be shared with all workers so they can read stored credentials.
Airflow’s prerequisites page for version 2.8.3 says you should only use Linux-based distributions as the production environment, since that is the only supported one. On Windows, it says you can run it via WSL2 or Linux containers.
A practical checklist before you commit:
- Pick a supported operating system and runtime for production, not just for a laptop trial.
- Choose a real database from the start rather than a file-based one you must migrate later.
- Decide whether you need a queue and workers, and plan for the broker that implies.
- Plan where files and binary data live; n8n’s docs say filesystem binary storage is not supported in queue mode, and name S3 external storage as an option.
- Set up backups for the database and for encryption keys, and test a restore.
- Put the service behind HTTPS and restrict who can reach it.
- Name the person responsible for updates and monitoring.
How to decide if self-hosting fits you
Ask three questions. Do you have a strong reason to keep data or execution in-house? Does someone on the team have time and skill to run services? And is your workload steady enough that fixed infrastructure beats usage-based pricing?
If you answer yes to most, self-hosting is worth a pilot. If the answer is mostly no, a hosted plan may cost less once you count maintenance hours.
Start small: run one non-critical workflow for a few weeks, watch how much time upkeep takes, and then decide. Comparing categories helps too; our notes on open source workflow engines cover engines built for long-running processes, while open source bpm tools are covered for process modelling and management.
Write down what a failure would cost you. If a stopped automation only delays a report, a single server with nightly backups may be enough. If it halts orders or customer replies, you will want monitoring, alerts and a rehearsed recovery plan before going live.
Also check who else will touch the system. Shared access needs sensible roles, an audit trail where the tool offers one, and a habit of documenting each workflow so that a colleague can maintain it when the original author is away.
Keep an exit path in mind as well, because tools and needs change over the years. Favour tools that let you export workflow definitions in a readable format, so moving later does not mean rebuilding everything by hand.
Frequently asked questions
Is self-hosted workflow automation the same as open source?
No. Self-hosted means you run the software; open source describes its licence. Some self-hostable products have restrictive or mixed licences, so read the terms.
Can I run it on Windows?
It depends on the tool. Airflow’s 2.8.3 prerequisites page says production should use Linux-based distributions, and that Windows users can run it via WSL2 or Linux containers.
Do I need a database server?
For anything beyond a trial, usually yes. The n8n docs say running queue mode with SQLite is not recommended, and point to supported PostgreSQL versions.
What is the biggest risk?
Neglected maintenance. Missing backups, skipped updates and lost encryption keys cause more trouble than the initial install does.
