Self-hosted n8n automation you own and can afford to run

We deploy it the way a production service deserves. Containers on infrastructure in your cloud account, PostgreSQL as the database rather than the default file based store, and queue mode with separate worker processes once volume justifies it, so a long running workflow does not block everything behind it. Execution data pruning is configured deliberately, because unbounded history is the most common cause of a database growing until it stops. The encryption key that protects stored credentials is backed up separately and treated as a secret, since losing it means re entering every credential in the system.

Upgrades are the other discipline. New versions ship often, occasionally with breaking changes to nodes. We pin a version rather than tracking latest, test upgrades in a staging instance with a copy of your workflows, and schedule them rather than doing them reactively. Workflows are exported to a Git repository so you have a history you can diff and roll back to, which the interface alone does not give you.

If you have no appetite for any of that, the hosted n8n cloud service exists and it is a legitimate choice. We will say so rather than selling you infrastructure you do not want to own.

• Containerised deployment in your own cloud account, Australian region by default
• PostgreSQL database with backups tested by restoring them
• Queue mode with workers once concurrency demands it
• Execution history pruning configured so the database stays bounded
• Encryption key backed up and stored as a managed secret
• Pinned versions with upgrades tested in staging first
• Workflow definitions exported to Git for history and rollback

Above that sits the error workflow. Every production workflow we build points at a dedicated error handler that receives the failed execution, logs it with the workflow name and the failing node, and raises an alert somewhere a human looks. Without one, failures sit in the execution list and are noticed when somebody eventually asks why the invoices stopped.

The subtler work is idempotency. Automation that retries will occasionally repeat a step that already succeeded, so a workflow that blindly creates records will produce duplicates under exactly the conditions you designed the retry for. We build with a stable external identifier on each item, check before create, and use upsert operations where the target system supports them. Where it does not, we keep a processed record store so a second attempt is recognised and skipped. This is unglamorous and it is the single biggest difference between an automation you can trust and one somebody has to babysit.

If you need five simple connections between mainstream software as a service products and you need them this week, the setup effort will not pay for itself. Zapier is the more honest recommendation and we make it regularly. If your organisation lives in Microsoft 365, much of what you want may be covered by licensing you already hold, which is the case for Power Automate.

And there is still a point where visual workflows stop being the right medium. When logic gets deep enough that you are managing state across many steps, need transactional guarantees, or find yourself writing most of the workflow inside code nodes anyway, write the service properly. A small piece of custom software behind a clean API is easier to test, review and hand to another developer than a canvas with ninety nodes on it. We would rather scope that than defend a diagram. If you are still deciding which processes deserve automation at all, start with process mapping.