n8n-io/n8n: self-hosted AI agent and workflow automation, reviewed for engineers

What problem n8n solves, and who actually needs it

Most integration work sits between two bad options. You either write glue code that calls an API, retries on failure, and stores state somewhere, and then maintain that code forever, or you hand the job to a SaaS automation tool and accept that the credentials, the execution logs and the data all live on someone else's infrastructure. n8n targets the second half of that trade-off. The README describes it as a "fair-code workflow automation platform with native AI capabilities" and states that it can be run self-hosted or in the cloud, which means the same engine is available under your own control.

The audience is fairly specific. It is engineers and technical operators who are comfortable reading a Docker command and a JavaScript snippet, and who have a reason to keep workflow data in-house: regulated data, internal systems with no public API gateway, or a policy that forbids sending payloads to a third-party orchestrator. The README also points at 9,000+ workflow templates and 1500+ integrations, so the practical entry point is usually an existing template rather than a blank canvas.

The execution model: nodes, a canvas, and code where the canvas stops

n8n is a node-based system. A workflow is a graph of nodes, each node performs one step (an HTTP call, a database query, a model invocation, a branch, a wait for human approval), and data moves between nodes as items. The README frames the same idea as combining "a visual canvas with custom code".

The repository layout confirms this is a monorepo rather than a single service. Top-level entries include packages/, docker/, scripts/ and a pnpm-workspace.yaml, and package.json defines the root as n8n-monorepo at version 2.39.0. The scripts show how the pieces are separated: dev:be runs the n8n package, dev:fe:editor runs n8n-editor-ui, dev:design-system runs @n8n/design-system, and dev:ai runs @n8n/n8n-nodes-langchain alongside n8n and n8n-core. So the LangChain-based AI nodes are a separate workspace package, not a hard dependency of the core engine.

That separation matters for how you reason about upgrades. The AI node package can move independently of the editor UI, which is why the release list shows both a stable tag and versioned tags such as [email protected] and [email protected] on the same day. If your workflows lean on the AI nodes, pinning the versioned tag is more predictable than tracking stable.

Installing n8n with Docker and running a first workflow

The README gives two install paths. The fast one pipes a script from get.n8n.io into a shell and requires Docker. The manual one is more transparent and is the better starting point if you want to know what is on your machine.

Create a named volume first so that workflows and credentials survive container restarts:

docker volume create n8n_data

Then start the container. The README maps port 5678 and mounts the volume at /home/node/.n8n:

docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Open http://localhost:5678 and the editor loads. From there the first real use is a two-node workflow: a trigger node, then a node that does something with the payload. The README points to n8n.io/workflows for examples and docs.n8n.io for the node reference, and it explicitly mentions combining visual building with "JavaScript, Python, and npm packages", so a Code node is where you go when no integration matches.

One caveat on the command above: it uses --rm, so the container is deleted when it stops. The volume keeps your data, but any environment variables you passed are gone. For anything beyond a first look, drop --rm and manage the container explicitly.

If you plan to build from source rather than run the image, package.json requires Node.js >=24.0.0 and pnpm >=12.3.4, and the preinstall script runs scripts/block-npm-install.js, so npm install is blocked by design. Use pnpm.

The licence is the real adoption decision

The README states that n8n is fair-code, distributed under the Sustainable Use License and the n8n Enterprise License, with source always visible, self-hosting allowed, and enterprise licences available by email. That is not the same as an open source licence, and the repository does not present it as one.

For an internal automation platform, the practical effect is usually small: you run it, you connect your systems, you keep the source. The line is drawn around redistributing n8n itself or building a product whose value is the automation engine. If you are embedding n8n inside something you sell, the Sustainable Use License is not the document you want to be relying on, and the README points at the n8n Enterprise License instead. Because the licence text lives in LICENSE.md and LICENSE_EE.md at the repository root, and the README does not summarise the terms, the only honest step is to read those two files against your actual deployment plan. This is a description of what the project says about itself, not legal advice.

The repository also carries a CONTRIBUTOR_LICENSE_AGREEMENT.md and a SECURITY.md, which is normal for a project that accepts outside contributions while keeping a commercial licence model.

Where n8n stops being the right tool

The first limitation is operational weight. n8n is a Node.js application with an editor UI, a database, and a queue of executions. Self-hosting it means you own the container, the volume, the upgrades and the backup of n8n_data. If your automation need is a cron job that posts to a webhook once an hour, a 30-line script and a systemd timer will be cheaper to run and easier to debug than a platform.

The second limitation is that the visual canvas is a coordination layer, not an abstraction over your systems. When a node fails because an upstream API changed its response shape, you still debug the API. The canvas shows you which node failed; it does not tell you why the payload was wrong.

The third is version drift. The repository shows a stable tag plus versioned tags published close together, and the monorepo separates the core, the editor UI and the AI node package. Upgrading the container image moves all of them at once. There is nothing in the README about rollback behaviour or database migration reversal, so the safe assumption is that you test an upgrade on a copy of the volume before touching production. The README is silent on that point, which is itself worth knowing.

Finally, maintenance status: the last push to the repository was on 2026-08-28. That is recent enough that the project is clearly being worked on, but the README does not publish a support window or a long-term release policy, so you cannot derive an upgrade cadence from the documentation alone.

How n8n differs from Zapier and from writing your own glue

The closest comparison is Zapier. Both give you triggers, actions and a catalogue of integrations. The difference is where the engine runs and what you can put inside a step. Zapier is a hosted product: your workflows execute on their infrastructure, and the extension point is their app directory. n8n runs in a container you control, and the extension point is a Code node plus npm packages, which the README lists as a first-class capability. If your workflow needs to call an internal service that is not reachable from the public internet, that difference decides the choice on its own.

Against hand-written glue code, the trade is reversed. A script gives you total control and no UI to learn, but you rebuild retries, credential storage, execution history and a way for a non-engineer to see what ran. n8n's value is that those pieces already exist. The cost is that you now operate a platform, and the platform has its own release cycle, its own licence, and its own database.

There is also a middle option worth naming: if you only need the AI agent part, the repository shows the LangChain nodes as a separate workspace package, @n8n/n8n-nodes-langchain. That does not make them usable without the n8n runtime, but it does mean the AI layer is versioned separately from the editor, which is useful when you are deciding what to pin.

Upgrade cost and what the repository tells you about it

Upgrading the Docker image is one command, but the data lives in the n8n_data volume and the README does not describe a migration or rollback procedure. The repository does carry a CHANGELOG.md at the root, and releases are tagged both as stable and as explicit versions such as [email protected]. Pinning to a versioned tag rather than stable gives you a known target and a changelog entry to read before you move.

If you build from source, the constraints are concrete: Node.js >=24.0.0, pnpm >=12.3.4, and npm install is blocked by a preinstall script. The build scripts are split (build:n8n, build:docker, build:docker:clean with DOCKER_BUILD_NO_CACHE and DOCKER_BUILD_BASE_IMAGE), which suggests the maintainers expect a full rebuild to be a deliberate, occasionally necessary operation rather than a routine one.

The licence implication for upgrades is the one people miss. LICENSE.md and LICENSE_EE.md sit at the repository root and are separate documents. If your usage changes from internal automation to something customer-facing, the licence question changes with it, and that is a review to do before the deployment, not after.

Editorial conclusion

Adopt n8n if you need a self-hosted automation engine that mixes a visual canvas with real JavaScript and Python, and if your internal-only use fits the Sustainable Use License. Do not adopt it if you intend to resell the automation as a hosted feature to customers, or if you need a licence that a legal team can classify as OSI-approved without reading LICENSE.md and LICENSE_EE.md first. Verify three things before you commit: which of your planned use cases fall under the Sustainable Use License rather than the n8n Enterprise License, whether the Node.js 24 and pnpm 12.3.4 requirements in package.json match your build images, and whether the version you pin still receives releases after the last push on 2026-08-28.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes