The Plumbing Layer: n8n and the Quiet Maturity of Workflow Automation

There is a kind of software that almost no one volunteers to write but every company eventually accumulates: the cron-scheduled Python script that pushes refunds into the data warehouse, the Lambda that listens for a Slack reaction and opens a Linear ticket, the queue worker that retries a webhook delivery against a vendor whose status page has never been green. Together this body of work is the connective tissue of an engineering organisation, and the moment someone tries to count it, the number is always larger than expected.

What used to be called iPaaS has matured around this fact. The first generation of products in the space optimised for non-technical users and treated APIs as something to be hidden. The current generation, n8n included, treats engineers as the primary audience — surfacing real HTTP payloads, exposing structured data between steps, and tolerating, even encouraging, the moment when a visual workflow needs to drop into actual code.

This report is a working notebook on n8n: how teams set it up, what holds up in production, and where it sits relative to the older glue-script habits it is steadily replacing.

n8n models an automation as a directed graph of nodes. Each node falls into one of three roles: it produces data (a trigger — a webhook, a schedule, a polling check against a third-party API), it transforms data (an HTTP call, a database query, a filter, a merge, a split), or it consumes data (an outbound write into another system). Edges between nodes carry structured items, and the editor renders the actual payload flowing along each edge at execution time, which collapses the debug loop into something close to a REPL.

The node library is wide and only widening. Core nodes handle the universal verbs: HTTP, FTP and SFTP, SQL against Postgres and MySQL, S3-compatible object storage, Git operations, queue dispatch. Integration nodes wrap the common SaaS surface — CRMs, helpdesks, calendars, chat platforms, spreadsheets, document stores — and the AI-oriented node set has become the most visibly active part of the catalogue, with agents, chat models, embedding generators, and vector store clients arriving at a rate that makes any specific list out of date almost immediately.

Triggers, transforms, sinks

A useful mental model is to draw any workflow as three bands. The left band is triggers: how the workflow wakes up. The middle band is transforms: filters, conditionals, retries, mergers, and any computation that lives between input and output. The right band is sinks: the systems that receive the result. Most production workflows we examined had two or three triggers, an unexpectedly fat middle, and a small number of sinks. The middle is where engineering taste shows up.

The clearest difference between n8n and the closed-source platforms that share its category is the presence of escape hatches — places in the platform where the abstractions step aside and the user is given back a programming environment.

The first is the Code node, which runs JavaScript or Python against the items in flight. Any transformation the native nodes cannot express — a peculiar pagination scheme, a signature header, a small piece of business logic that does not justify a microservice — is usually a dozen lines inside a Code node. We saw this used most often for response normalisation: taking the wildly heterogeneous JSON returned by an API and shaping it into the consistent items shape the rest of the workflow expects.

The second is the custom node. n8n nodes are TypeScript modules and, on a self-hosted instance, a private node package can be installed alongside the official catalogue. Teams use this to wrap internal APIs once and then expose them to non-engineers as a first-class building block — effectively turning institutional knowledge into clickable nodes.

The third is the HTTP Request node, which sounds prosaic but functions as a universal escape hatch into the rest of the internet. Any API without a dedicated integration is reachable through it, with credentials and retry behaviour handled the same way as the first-class connectors.

n8n is distributed in two shapes. The managed offering, n8n Cloud, removes the operational tax for teams that do not want to run another stateful service. The self-hosted distribution is a Docker image backed by either SQLite (fine for evaluation, not for anything beyond) or Postgres (the only reasonable production choice). Past a modest scale, production deployments enable queue mode, which splits the platform into a coordination process and a fleet of workers that execute jobs out of Redis — the same horizontal-scale shape as most modern task systems.

Container

Official Docker image; Helm chart available for Kubernetes-native installs.

State store

Postgres in production. SQLite is supported but not recommended past a single-engineer evaluation.

Workers

Queue mode with Redis as the broker; workers are stateless and can be scaled per workflow class.

Identity

SSO (SAML, OIDC) and role-based access live in the enterprise tier alongside environment separation and external secret managers.

Observability

Native execution history. Prometheus metrics endpoint available; most teams ship logs to whatever they already use.

The portability story is genuinely portable. Workflows export as JSON, credentials are referenced symbolically rather than embedded, and the same file boots cleanly on Cloud and self-hosted instances. The strongest argument for self-hosting is not cost — it is data residency and the ability to keep an automation entirely inside an existing private network when it touches sensitive systems.

Rather than a comparison matrix, the map below frames the platform by capability area — what each surface covers in production, in the language teams used when describing it to us.

Across the deployments examined for this report, n8n occupied two recognisably different roles — sometimes inside the same organisation, often run by different teams.

1. The replacement for the glue drawer

   The first role is consolidation. The cron-scheduled Python script, the Lambda triggered by a Slack reaction, the shell file that hasn’t been opened in two years — these collapse into workflows with centralised execution history, retries, and a single observability surface. None of them are individually clever. The payoff is collective.

2. The orchestration layer for AI-shaped work

   The second, more recent role is as the substrate for language-model-driven automation. Because the platform already handles connectivity, retries, and structured data flow, wiring an agent or a retrieval pipeline into an existing workflow is often the shortest path to something usable. For a growing share of users, n8n is the default place new integrations land first.

3. The shared surface between engineering and ops

   A third pattern we saw less often, but which is worth noting: engineering teams shipping internal node packages that operations or revenue teams then assemble into workflows themselves. The visual editor is the medium; the custom nodes are the boundary between “safe to compose” and “wraps something fragile.”

Two notes worth attaching to any evaluation.

The first is operational. Workflow platforms are stateful, and treating an n8n install as a stateless web service is the most common cause of weekend incidents we heard about. Back up Postgres, treat the workflow JSON as source code, version the credential definitions separately from their secrets, and add execution-volume alerts before a runaway loop adds them for you.

The second is the licence. n8n is distributed under the Sustainable Use Licence, a source-available model that permits internal business use and modification but restricts repackaging the product for commercial distribution. For teams using n8n to automate their own operations the licence is functionally inert. For anyone considering offering n8n-as-a-service to third parties, the licence text should be the first artefact read — not the marketing site.

Past those two notes, the platform is one of the rare cases where the practical defaults and the long-term posture appear to be aligned: the open core remains genuinely useful, the escape hatches remain genuinely open, and the export format remains genuinely portable. None of those qualities are guaranteed forever, but as of this writing they are intact.