n8n in Practice

n8n is a workflow automation tool. A workflow starts from a trigger such as “when a webhook arrives” or “every day at 9:00”, and continues through nodes that call APIs, transform data, branch on conditions or post to chat, all wired together on a canvas.

The name shortens “nodemation” (node plus automation): eight letters between the two n's. Zapier and Make are in the same category, but n8n stands out in a few ways.

• You can run it on your own server (self-hosting) — it starts with Docker, so data never has to leave the company. A cloud version exists too
• You can write code — besides wiring nodes, you can drop JavaScript or Python in as a node. Developers feel at home
• Lots of integrations — nodes for Slack, GitHub, GitLab, Jira, Google Sheets, PostgreSQL and more ship built in. The integrations list on the official site runs past 2,000 entries
• AI fits in easily — there is an AI Agent node for LLMs, and MCP (the protocol that connects AI to outside tools) is supported

n8n started in 2019 as a project by Jan Oberhauser, a developer in Berlin. It has grown from a personal tool into an automation platform for the AI era.

Version 2.0 brought many safer defaults: Code nodes run in a separate process (task runners), and the Execute Command node, which runs shell commands on the server, is disabled by default. Also, saving a workflow no longer changes production; it switches only when you “Publish”, so a half-edited workflow cannot run live by accident.

An n8n workflow is one trigger plus the nodes connected to it. What flows between nodes is an array of JSON items.

When a step fails, each node can either stop or pass the error on and continue. Failures of the whole workflow can be caught and reported by a separate error workflow (Error Trigger).

Cloud or self-hosted

To try it locally, start it with Docker as in the official guide and open http://localhost:5678 in a browser. Create the owner account and you are ready.

# Create a volume for the data (workflows, encryption key) and start
docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 \
  -e GENERIC_TIMEZONE="Asia/Tokyo" -e TZ="Asia/Tokyo" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n:2.42.6

For production, switch storage from SQLite (the default) to PostgreSQL, pin the version (2.42.6 rather than latest) and back up the encryption key (N8N_ENCRYPTION_KEY). Docker itself is covered in Dev Guide No. 5.

Self-hosted editions

What to watch in the licence (Sustainable Use License)

n8n's licence is “source available, but not open source in the usual sense”. The official FAQ boils down to the table below. Agencies and system integrators in particular should check how they will hand work over to clients.

The test is who decides what the workflow does. For unclear cases the official guidance is to ask n8n ([email protected]). This post is not legal advice.

• A good fit — work that APIs or databases can reach, event-driven work, repetitive jobs with clear steps, teams with engineers nearby
• A poor fit — operating systems that only have a screen (RPA's territory), work that needs millisecond speed or bulk processing of huge data (use a proper batch or streaming system), and core business logic that needs strict transactions (keep it in the application)

Now for one real example from web development, built and run. The subject is the customer management system from Dev Guide No. 5 (Spring Boot, Vue and PostgreSQL).

A familiar pain

Every time a new version lands on staging, someone works through a checklist in Excel, checking pages and APIs by hand, pastes screenshots, writes the result in chat and opens a ticket if something is wrong. Each round is short, but it happens on every deployment, and things get missed or go unrecorded.

The flow, built in n8n

1. After deploying to staging, CI (GitLab CI, GitHub Actions) calls an n8n webhook
2. n8n reads the test cases (URL, expected status, text that must appear), calls each page and API and judges the result
3. It also connects to the database with a read-only user to confirm no migration failed and the master data is there
4. It posts a summary to chat and, on failure, opens a ticket automatically
5. It answers CI with an HTTP status (200 or 422), so a failure stops the pipeline

1. Put the test cases in a data table

2. Call the webhook from CI

Set the Webhook node to authenticate with a header token, and choose to respond with a Respond to Webhook node. On the CI side, GitLab CI could look like this (an example).

# .gitlab-ci.yml (excerpt)
acceptance:
  stage: verify
  needs: [deploy_staging]
  script:
    - >
      curl --fail-with-body -sS -X POST "$N8N_URL/webhook/acceptance"
      -H "X-Api-Key: $N8N_TOKEN" -H "Content-Type: application/json"
      -d "{\"env\":\"staging\",\"version\":\"$CI_COMMIT_TAG\",
           \"commit\":\"$CI_COMMIT_SHORT_SHA\",\"pipeline\":\"$CI_PIPELINE_URL\"}"

3. Call with an HTTP Request node

• Set Method to {{ $json.method }} and URL to {{ $json.url }}, taking values from the test case. Four items come in, so it calls four times
• Turn on Include Response Headers and Status and Never Error under Options. A 404 or 500 no longer stops the run, and the next node can judge the status
• Set On Error under Settings to continue, so even a connection failure reaches the judging step

4. Judge in a Code node

// Match each test case with its HTTP result (excerpt)
const cases = $('受入テストケースを読む').all();
return $input.all().map((res, i) => {
  const c = cases[i].json;
  const status = res.json.statusCode;
  const body = String(res.json.data ?? '');
  const okStatus = status === c.expect_status;
  const okText = !c.expect_text || body.includes(c.expect_text);
  let detail = 'OK';
  if (status === undefined) detail = '接続できない';
  else if (!okStatus) detail = `ステータス ${status}（期待値 ${c.expect_status}）`;
  else if (!okText) detail = `期待した文字列がない：${c.expect_text}`;
  return { json: { case_no: c.case_no, title: c.title, ok: okStatus && okText, status, detail } };
});

Node names and messages are in Japanese because the example was made for a Japanese team.

5. Check the database

The Postgres node queries with a user that can only SELECT, looking at the migration (Flyway) history and the number of master records.

SELECT
  (SELECT count(*) FROM flyway_schema_history WHERE NOT success) AS failed_migrations,
  (SELECT max(version) FROM flyway_schema_history WHERE success) AS schema_version,
  (SELECT count(*) FROM customer) AS customers;

6. Sum up, branch, answer

A second Code node merges the API and database results and writes the chat message and ticket text. An IF node checks whether everything passed: on a pass it posts to chat and answers CI with 200; on a failure it opens a ticket, posts to chat and answers 422. Tickets can go through the GitLab, GitHub or Jira nodes, or an HTTP Request to any tracker's API.

In 2.x, always Publish after editing. If you only save, the webhook keeps running the last published version (the author once ran an old version believing it was fixed).

With version 1.0.1 on staging, all six checks passed. Then version 1.0.2, whose configuration error shifted the API path (an error added on purpose for this test), failed three checks: a ticket was opened and CI received 422.

# Response to the CI call (1.0.2)
{"result":"failed","passed":3,"total":6,"issue":"https://gitlab.example.com/crm/-/issues/102"}
HTTP 422

# Message that arrived in chat (Japanese original)
【受入チェック NG】staging v1.0.2（9d81e0c）3/6 件 合格
[OK] AC-01 画面のトップが表示される：OK
[NG] AC-02 アプリが起動している（ヘルスチェック）：ステータス 404（期待値 200）
[NG] AC-03 顧客一覧を取得できる：ステータス 404（期待値 200）
[NG] AC-04 顧客を登録できる：ステータス 404（期待値 200）
[OK] DB-01 マイグレーションの失敗がない：失敗 0 件（適用済み V1）
[OK] DB-02 顧客マスタにデータがある：3 件
課題：https://gitlab.example.com/crm/-/issues/102

Chat and the issue tracker were stand-in receivers (mocks) set up for this test. In real use, swap in the Slack, Teams or GitLab nodes or their APIs.

What changes

Things to watch

• Test data piles up — the create test adds a record each run. Give test data an obvious name and add a cleanup workflow
• Least privilege — a read-only database user and a token on the webhook. Point it at staging only, never production
• Not a replacement for tests — unit and E2E tests stay; this only confirms the deployment went right. Detailed behaviour belongs in the application's tests
• n8n needs operating too — pin and upgrade versions, back up, keep the encryption key safe. With releases almost weekly, decide your upgrade routine
• For teams — the free Community edition cannot share workflows or credentials with other members. If several people maintain it, consider a paid edition

RPA (robotic process automation) means software robots doing work by operating screens the way people do: reading fields, clicking, typing, pasting into another application. Its defining strength is that even when a system has no API, anything a person can operate on screen can be automated.

Still, RPA is not the only kind of automation tool. Roughly, they divide like this.

What UiPath is

UiPath was founded in 2005 in Bucharest, Romania, as DeskOver, renamed UiPath in 2015 and listed on the New York Stock Exchange in 2021. It is the best-known RPA company: Gartner named it a Leader in the Magic Quadrant for RPA seven years in a row up to 2025. Today it presents itself not just as RPA but as an “agentic automation platform” that includes AI agents.

On price, there is a free Community plan for individuals and eligible organisations, Basic from $25 a month (up to two robots, data in the European region only), and Standard and Enterprise on quote; costs add up by users and robots (official site, October 2026).

The short answer: if the target system has an API or a database connection, and the builders are developers (or a team developers support), n8n can take over in many places.

On the other hand, in the situations below, replacing UiPath (or an enterprise RPA product) with n8n is hard or not worth it.

Put the other way round: if none of “screen only”, “on a person's PC” or “hundreds of robots governed company-wide” applies, n8n deserves to be a serious candidate.

You do not have to pick one. A practical split is n8n wherever an API reaches, RPA where there is only a screen, joined through APIs.

What to check when choosing

If you already run UiPath, the quickest win is usually to review your existing robots and move the ones an API could handle to n8n. If your development team is just starting with automation, start small with n8n on development and operations work, and look at RPA when a screen-only system turns up.