Skip to content
← Tools

n8n

Event glue between systems

A workflow automation tool. You wire nodes together on a canvas - a webhook, a request, a condition, a database write - and it runs the chain whenever the trigger fires.

n8n is where I put the work that has to react to something. Most of what I build runs on a schedule or on demand, and plain scripts are better at that. But when a platform can only tell me something by firing a webhook, n8n is the cheapest place to catch it and turn it into an action.

How I use it

Catch the event, hand it off quickly. The pattern I keep coming back to is webhook in, pull out the few fields that matter, call one model or one API, write the result somewhere durable. The workflow is a receptionist, not the office. Long chains of nodes doing real logic are where these things get hard to change.

The database is the interface, not the workflow. A reply assistant I built took a reply event, drafted a suggested response and stored it against the lead. The browser extension that showed the draft to a person read from that store and knew nothing about n8n. Either half could be rebuilt without touching the other.

Self hosted, because the thing it talks to is self hosted. Running my own instance means the webhook URLs, the credentials and the uptime are mine to manage. That is a real cost, and it buys the ability to talk to anything on the same network and to stop paying per execution for a workflow that fires all day.

Anything deterministic leaves. If a job runs on a schedule, needs no trigger and produces the same shape of output every time, it becomes a script in a repo with tests, and n8n keeps only the part that had to be event driven.

What I have learned the hard way

A workflow is JSON, but it does not review like code. Exporting it gives you a file you can commit, and that file is a node graph with coordinates in it. A diff of two versions tells you almost nothing about what changed in behaviour. So the canvas stops being reviewable at exactly the size where review starts to matter.

The exported workflow is not the whole system. Credentials live in the instance, not in the export. Import it somewhere else and you get a complete looking workflow that fails on the first authenticated node. It is worth writing down what a workflow needs alongside the file that describes what it does.

A failed run is silent unless you make it loud. The default outcome of a broken workflow is nothing happening, which is also the outcome of a quiet day. Every trigger I care about writes its raw payload down on arrival, so a missing result can be told apart from a missing event.

Self hosting means owning the upgrades. A version bump on your own instance is your outage if it goes wrong, and there is nobody to escalate to. That is a fair trade for control, but it is a trade, and it should be a decision rather than a default.

Resources

This is one part of a stack. The rest is on the tools page, and what I build with it is on work.

tools/n8n.md
---
tool: n8n
role: Event glue between systems
category: Automation
url: https://mihajlomaiga.com/tools/n8n
---

# n8n
A workflow automation tool. You wire nodes together on a canvas - a webhook, a request, a condition, a database write - and it runs the chain whenever the trigger fires.
n8n is where I put the work that has to react to something. Most of what I build
runs on a schedule or on demand, and plain scripts are better at that. But when a
platform can only tell me something by firing a webhook, n8n is the cheapest place
to catch it and turn it into an action.

## How I use it

**Catch the event, hand it off quickly.** The pattern I keep coming back to is
webhook in, pull out the few fields that matter, call one model or one API, write
the result somewhere durable. The workflow is a receptionist, not the office. Long
chains of nodes doing real logic are where these things get hard to change.

**The database is the interface, not the workflow.** A reply assistant I built
took a reply event, drafted a suggested response and stored it against the lead.
The browser extension that showed the draft to a person read from that store and
knew nothing about n8n. Either half could be rebuilt without touching the other.

**Self hosted, because the thing it talks to is self hosted.** Running my own
instance means the webhook URLs, the credentials and the uptime are mine to manage.
That is a real cost, and it buys the ability to talk to anything on the same
network and to stop paying per execution for a workflow that fires all day.

**Anything deterministic leaves.** If a job runs on a schedule, needs no trigger
and produces the same shape of output every time, it becomes a script in a repo
with tests, and n8n keeps only the part that had to be event driven.

## What I have learned the hard way

**A workflow is JSON, but it does not review like code.** Exporting it gives you a
file you can commit, and that file is a node graph with coordinates in it. A diff
of two versions tells you almost nothing about what changed in behaviour. So the
canvas stops being reviewable at exactly the size where review starts to matter.

**The exported workflow is not the whole system.** Credentials live in the
instance, not in the export. Import it somewhere else and you get a complete
looking workflow that fails on the first authenticated node. It is worth writing
down what a workflow needs alongside the file that describes what it does.

**A failed run is silent unless you make it loud.** The default outcome of a
broken workflow is nothing happening, which is also the outcome of a quiet day.
Every trigger I care about writes its raw payload down on arrival, so a missing
result can be told apart from a missing event.

**Self hosting means owning the upgrades.** A version bump on your own instance is
your outage if it goes wrong, and there is nobody to escalate to. That is a fair
trade for control, but it is a trade, and it should be a decision rather than a
default.
## Resources
- [n8n](https://n8n.io/)
- [Documentation](https://docs.n8n.io/)