How it works underneath, for the curious

Who this appendix is for (most people can skip it)

If all you want is to build a few workflows in Woow n8n to automate your own work, you do not need this appendix. Chapter 1 already gives you the plain-language version of what n8n is; Chapter 13 covers credentials; Chapter 17 covers error handling. That is enough to get things done.

This appendix is written for a few kinds of reader:

• Anyone evaluating whether the company should move to n8n Cloud — you need to know where the line between self-hosting and Cloud sits.
• Decision-makers weighing the Enterprise edition — you need to know exactly which features the money buys.
• The IT / DevOps people called in to rescue n8n — n8n is down, the DB is full, an upgrade is due — you need to know what each process does, where the data sits, and how to back it up.
• Tinkerers who want to self-host an n8n at home to play with — you need to know what happens underneath once Docker is running.

The three editions: Community vs Cloud vs Enterprise

n8n currently ships three editions, and the feature differences are below — this table is what decides whether you spend money:

Which edition Woow n8n runs

WoowTech's internal n8n (n8n.woowtech.io) is a self-hosted Community edition — it sits on the company's own server, runs in Docker, and faces the outside world through a Cloudflare tunnel.

• Upside: free, all the data stays inside the company, any setting is ours to change, any experimental flag is ours to turn on.
• Price: no SSO (we use the built-in username and password today), no audit log, upgrades done by hand by IT, faults we debug ourselves.
• Whether there is an Enterprise license: it moves with WoowTech's current size and needs — ask IT directly if you need to know. With Enterprise you also get SSO / RBAC / environment switching.

The process architecture: main / worker / webhook

When n8n runs, what sits underneath is not "one big program" — it can be split into processes with different roles. That is what makes it scalable.

By default (Regular mode) there is only one main process and it does the whole job on its own — UI, API, scheduling, running workflows, receiving webhooks. For a small deployment (<50 workflows, <1000 executions a day) that is enough.

Once you have more workflows and one of them runs long enough to block the whole box, it is time to consider Queue mode (see §Queue mode below): the main process only handles the UI and scheduling, the actual workflow runs go to workers, and receiving webhooks is split off to a webhook process. All three roles scale horizontally on their own.

Choosing a database: SQLite / Postgres / MySQL

n8n needs a DB to store workflows, credentials and executions. All three are supported:

You configure the DB through environment variables:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres.internal
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n_user
DB_POSTGRESDB_PASSWORD=***

Where the important data lives

Knowing where the data sits is what gives you a starting point for backup, restore and debugging. Here is where n8n's main data lives:

Execution data growth: ignore it and it fills the database

Every workflow run creates one execution_entity row — add each node's input / output data and a single run can be a few hundred KB. Run that for a few months and your DB grows enough to give you a fright.

Chapter 17 mentioned EXECUTIONS_DATA_MAX_AGE; here is the whole set of pruning environment variables:

You can also override the global setting inside a single workflow's Settings — for example, a workflow that runs every minute can be set to "store no data on success" and keep records only for failures, which saves a great deal of space.

Queue mode: scaling further

When you have more and more workflows, one of them takes 5 minutes per run, and everything else is stuck behind it — that is when you need Queue mode.

What Queue mode does

1. The main process only handles the UI and scheduling

   It no longer runs workflows itself; instead it drops "what should run" onto a Redis queue.

2. Worker processes take jobs off the queue and run the workflows

   You can start N workers and the jobs are distributed automatically. One worker running long does not matter; the others keep picking up new jobs.

3. A webhook process (optional) receives webhooks and nothing else

   Splitting webhooks off from main stops a slow UI from making webhooks slow too.

What you need to turn Queue mode on

• Redis (as the queue broker) — run another box or use a managed one.
• Postgres — SQLite cannot be shared, so several workers cannot read the same data.
• Environment variables:

# main
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis.internal
QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb
# ... other DB settings

# worker (a separate container / process)
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis.internal
# ... the same DB and Redis settings
# start command: n8n worker

Backup and restore strategy

n8n backups have three layers, and only backing all of them up counts as complete:

The right order to restore in

1. Stop n8n first

   docker compose stop n8n — this keeps anything from writing during the restore.

2. Restore the DB

   Postgres: psql n8n < backup.sql. SQLite: copy database.sqlite back over the top.

3. Check that N8N_ENCRYPTION_KEY matches

   This is the most critical step in a restore — the new environment's encryption key has to be exactly the one in place when the backup was taken, or the credentials will not open. Change it and you are done for.

4. Start n8n and verify

   docker compose up -d n8n, then sign in, open a workflow and run it manually once to confirm the credentials work. When something fails it is usually the encryption key not matching.

Upgrade strategy: never upgrade on a Friday

n8n iterates fast (there is a small release almost every week). Upgrades mostly go smoothly, but there is the occasional breaking change. The steps:

1. Try it in a staging environment first

   Pull a copy of the production DB into staging, upgrade, and run each of your main workflows once. Do not upgrade production directly.

2. Read the changelog for breaking changes

   github.com/n8n-io/n8n/releases — watch major versions in particular (0.x → 1.x is a big deal) and anything marked BREAKING. A node going from v1 to v2 often renames fields too.

3. Take one backup (however confident you are)

   Run the whole §backup set above. It is the last safety net before an upgrade.

4. Stop the workflows → upgrade → bring it back up

   Docker users: docker compose pull && docker compose up -d (if the tag is latest). Manual installs: npm install -g n8n@latest.

5. Check the UI and run a test workflow

   Sign in, open a workflow, and Execute it manually once. If something fails, read the log first (docker logs n8n).

Monitoring: how you know n8n is still alive

A production n8n needs basic monitoring — otherwise it dies in the middle of the night and nobody knows. A few approaches, from simple to complex:

Common architecture pitfalls

When the problem is not your workflow logic but n8n itself, these are the ones you meet most:

FAQ