Question 1

What do you watch for security-wise in n8n?

Accepted Answer

Open by explaining why n8n is a special case — that differentiates the answer immediately. "n8n differs from an ordinary application because credentials for many systems collect in one place. One leak means access to several systems, so the risk is concentrated. I look at it in layers: Credentials. A key must never sit in a node parameter — anything there is part of the workflow JSON and spreads through exports, sharing and support tickets. Plus least privilege: I do not ask for write access when reading is enough. The encryption key. The key protecting credentials is the most sensitive secret. In production I set it myself and manage it as an environment variable; n8n also documents a rotation procedure. In a larger organisation there is the option of keeping credentials in an external secret vault. Webhooks. An endpoint on the open internet must require authentication. A random URL is not a secret — it lands in logs and proxies. Incoming data. A webhook body is untrusted. I never put it straight into a SQL query — I use query parameters, because n8n sanitises those. Execution history. When personal data is involved, the stored execution data is itself a risk — I drop sensitive fields early and tune the retention settings."

Question 2

How would you manage 50+ workflows in a team?

Accepted Answer

This is an architecture and process question. Answer in four directions. 1. Conventions. Names carry the environment and purpose: [Prod] Daily CRM sync, [Sub] Enrich customer. I set up folders and tags. These look unnecessary at 5 workflows and become the only way to find anything at 50. 2. Reuse. When the same logic exists in three places I extract it into a sub-workflow. Copied logic drifts apart over time and a fix lands in only one copy — the most common technical debt here. 3. Change management. On Business and Enterprise plans there is Git-based source control: instances link to branches, a change is tried in dev and pulled into production, and review with a visual diff is possible. Without it, the closest alternative is export/import, change history and a separate test instance. 4. Visibility. A centralised error workflow is assigned to every workflow. I track the failed-execution rate — a rise is the first signal that something changed. One more: ownership. Every workflow needs a named owner. An unowned workflow eventually becomes a black box nobody dares to touch."

Question 3

How would you separate dev and production environments in n8n?

Accepted Answer

Separate two scenarios — the answer depends on the plan, and knowing that signals experience. "If the official mechanism is available: Business and Enterprise plans have Git-based source control. Separate n8n instances link to Git branches: the dev instance pushes to a dev branch and the production instance pulls from main. Before publishing you can compare with a visual diff and submit for review. That is the closest thing to classic CI/CD. If it is not — which is usually the case in small teams — I build something simpler but workable: 1. A separate instance, or at least separate workflows — prefixed [Dev] and [Prod] 2. Separate credentials — different credentials for test and production systems, so testing never touches real data 3. Promotion by export/import — the workflow proven in dev is exported as JSON and imported into production; there is a package format for moving whole folders or projects 4. Change history — to roll back when something goes wrong In both cases the most important rule is the same: never edit a production workflow directly in production. It is the most common and most expensive habit."

Risk	How it arises	How to prevent it
A key ending up in a workflow export	The token was typed into a node parameter	Always use a credential — its value is not included in an export
An unprotected webhook	Authentication was left as "None"	Basic, header or JWT auth; signature verification and IP restrictions where possible
SQL injection	Incoming data was concatenated into the query with an expression	`$1`, `$2` tokens and the Query Parameters field
Sensitive data lingering in the execution history	Personal data passes between nodes and is stored	Tune execution data saving in workflow settings; drop sensitive fields early
Excessive permission	The credential was granted more than it needs	Do not request write access when reading is enough; create a dedicated service user

Security, versioning and teamwork

📚 Sources and documentation