Automation
n8n
n8n is the fair-code workflow automation tool we self-host: a visual node editor, code nodes, scheduled runs and a searchable execution history.
n8n is a workflow automation tool that its own documentation describes as fair-code licensed. Most of the work is visual: nodes are placed on a canvas and connected, and a workflow starts when a trigger condition fires. The same tool runs in the cloud or on our own infrastructure; we use the self-hosted variant, so data and credentials stay with us.
It gives us an integration layer toward external APIs, scheduled data processing, and steps where custom code is required.
How a workflow is built
- Nodes. A node can be a trigger, a data fetch, a transformation or a branch. Every production workflow needs at least one trigger node to define when it runs.
- Canvas and panels. The canvas is where nodes are connected; credentials, variables and the execution list live in the side and top panels.
- Credentials. API keys and OAuth secrets are stored as credentials, and app nodes use them to reach services.
- Expressions and code. Node parameters accept JavaScript expressions, and the Code node runs custom JavaScript or Python for logic the built-in nodes do not cover.
- Execution history. Every run is recorded, so a failure can be inspected afterwards, and node output can be pinned while building a workflow.
Running it on our own servers
In our stack n8n runs under Docker Compose. The default database is SQLite, but in production we put PostgreSQL underneath, because workflows, credentials and execution data all live there.
Under load, queue mode is the documented way to scale: one main instance receives triggers, worker processes perform the executions, and Redis holds the pending queue in between. Workers need the same database, and the encryption key of the main instance has to be shared with them, otherwise stored credentials stay out of reach. Worker concurrency is configurable.
The documentation points to Docker Compose or the one-line setup for installation; npm installation is deprecated from n8n 3.0.
What to watch
- Memory. n8n does not limit how much data a node fetches or processes. Memory use grows with the amount of JSON data, the size of binary data, the number of nodes, the Code node and manual executions. Out of memory situations appear as allocation errors in the logs; the V8 heap can be raised through NODE_OPTIONS and max-old-space-size, and smaller batches lower the peak.
- Execution data. Pruning is enabled by default: finished executions are removed by age (336 hours, 14 days by default) or by count. Annotated executions are never pruned. On SQLite the freed disk space is not returned automatically, that needs a VACUUM.
- License. The source is available under the Sustainable Use License, which allows internal business or non-commercial use; .ee files fall under a separate enterprise license.
- Backups. The database and the encryption key belong together in a backup; without the key the stored credentials cannot be read.
Where it fits in our stack
n8n is our layer for deterministic automation: where steps can be written down in advance, we build them as nodes, which keeps them readable and traceable. Docker provides the runtime, PostgreSQL the database, and n8n exposes its own MCP server, so external agents can reach workflows too. Work that needs judgement rather than a fixed path goes to Hermes Agent, and the workflow keeps only the stable, repeating steps.
Further reading
In our stack n8n is part of the Docker Compose deployment: it runs scheduled data jobs and recurring content pipelines, and it handles the steps that can be described precisely.